11:21:56 #startmeeting virt_test_day_f22 11:21:56 Meeting started Thu Apr 16 11:21:56 2015 UTC. The chair is crobinso. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:21:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 11:22:19 morning all 11:23:33 * kashyap waves 11:34:34 I'd love to participate today, but we're having Beta Go/NoGo in 6 hours :/ I might add some test case results tomorrow instead 11:37:04 * satellit I am testing f22 RC3 cannot help today either 11:56:09 kparal: satellit: no worries, adding test results later is still appreciated 11:58:20 davidgiluk: did you just hit that virt-manager spice socket crasher? 11:58:35 crobinso: Yes, and I'm just pulling in your update 11:59:06 * davidgiluk should have done an update before he started 11:59:16 davidgiluk: ah so you aren't running latest virt-manager? 11:59:20 * crobinso is relieved 12:00:11 crobinso: No 12:11:18 * davidgiluk is finding that if he boots a VM with NAT then the IP address of the VM is different each time; it seems surprising to me, I'd have thought that libvirt would allocate it the same IP each time given it's the same guest mac 12:12:24 davidgiluk: that's interesting, haven't noticed that but I don't use VM IP that much. f22 VM ? 12:12:46 crobinso: yeh, f22 on f22 12:12:53 (installing an f22 into that :-) 12:13:40 crobinso: The usermode stuff is quite fun, it could do with the ability to add port redirects so you can get to ports in the guest 12:13:53 It is me, or virt-install don't have --os_variant=fedora22? 12:14:52 quintela: yeah it's missing: https://bugzilla.redhat.com/show_bug.cgi?id=1211797 12:15:11 crobinso: thanks 12:16:47 <||> GSpice-WARNING **: Warning no automount-inhibiting implementation available 12:17:00 * quintela tries to evaluate how scary that sounds :p 12:17:27 davidgiluk: usermode == nat? or do you mean qemu slirp? 12:17:51 crobinso: I think I mean slirp - for when you run with your own libvirt instance 12:18:36 * quintela just removes davidgiluk from Christmas dinner list. 12:18:44 Using slirp at this age O:-) 12:19:05 davidgiluk: there is a way to do port forwarding with slirp, but I don't recall if libvirt supports it 12:19:45 davidgiluk: -redir something 12:19:55 davidgiluk: I stand that you want to use proper bridge support. 12:19:59 davidgiluk: but also with the qemu bridge setuid helper, default libvirt config allows unprivileged users to use virbr0/nat. but virt-manager/virt-install won't attempt that default if using qemu:///session 12:20:20 quintela: You can run your own libvirt instance as an unpriveliged user, and for desktop stuff that's a good thing, but then you can't use fun network stuff 12:20:38 qemu-system-i386 -net user,hostfwd=tcp::5555-:23 [...] 12:20:38 telnet localhost 5555 12:20:46 quintela: Right, that's what I wanted 12:21:10 davidgiluk: that is the new syntax 12:22:02 quintela: Yep, just no way of doing it via the GUIs 12:23:15 crobinso: You say that libvirt will allow an unprivilged user to do that - how? 12:23:49 davidgiluk: 12:24:24 crobinso: ah, but not via the network details gui ? 12:24:28 davidgiluk: you can allow unprivileged access to other host bridges by extending /etc/qemu/bridge.conf 12:24:50 davidgiluk: should be possibly via virt-manager, let me look 12:25:44 davidgiluk: hmm. actually virt-manager is too restrictive there, only showing usermode. it should allow manually entering a bridge name at least. can you file a bug? 12:25:58 sure 12:30:05 https://bugzilla.redhat.com/show_bug.cgi?id=1212443 12:36:12 hmm, just managed to get a spice crash; 12:37:22 davidgiluk: when I was playing with migration yesterday, spice crashed on me too, but I didn't file a bug since I wanted to try and reproduce 12:37:35 davidgiluk: backtrace mentioned the spice migration channel 12:38:15 crobinso: I'm just waiting for abrt to download ~750MB of debuginfo packages and then we'll see 12:38:23 :) 12:39:19 crobinso: This one is my current favorite test of booting an Ubuntu VM and taking firefox to one of the UK TV channels 'catch up' services which uses a heavy amount of flash (heck I've never had it work on a real system) 12:41:48 davidgiluk: yeah that will definitely stress things :) 12:48:23 crobinso: Still, it's better than last time I tripped that one (on my home machine); that took out qemu and virt-manager, this one just killed the qemu 12:49:06 davidgiluk: the crash took out qemu? would be interesting to see if there's an assertion in /var/log/libvirt/qemu/$vmname.log 12:52:54 crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1212454 any idea which spice package that should be against? 12:54:43 spice-server? 12:54:45 davidgiluk: component=spice 12:54:48 ok 12:55:13 humm, what is the "civilized way" of convincing f22 that I want to use systemd-networkd? 12:55:21 If I can do that on the kickstart, the better. 12:56:28 quintela: hmm no idea, I haven't used it 12:57:11 crobinso: I know to do it by hand, but that means removing NetworkManager, creating a file in /etc/ praying during 5 mins and reboot. 12:57:21 not sure if only 5 mins of praying is enoug ... 12:57:23 bugzilla spinny as I make the mistake of trying to change the component 12:57:58 * davidgiluk hands quintela the wooden-stake 13:03:41 * quintela notices that "dnf remove NetworkManager" is not one option anymore :p 13:05:02 kashyap: I'm seeing that kernel trace in my L2 as well - but as I say it doesn't look like a normal trace 13:07:37 * satellit FYI f22 RC3 lives are working in VirtualBox (off topic?) 13:08:29 * satellit gnome-boxes a valid test? 13:10:55 satellit: gnome-boxes testing is definitely useful 13:12:03 k will reboot from centos7 mate.... 13:12:42 rebooting... 13:15:55 crobinso: do you mean previously that I should be able to run virt-install as a normal user? 13:17:23 I am clearly doing something wrong. I just did s|qemu:///system/|qemu:///session| 13:17:29 and make sure that I can write into the file 13:17:34 quintela: you can do it and get a working VM, but it gives subtle different results since it runs libvirtd as unprivileged user. VM autostart doesn't work, PCI passthrough and traditional USB passthrough doesn't work 13:18:27 <||> (master *)$ time virt-install --connect=qemu:///session --virt-type kvm --name=test2 --ram=2048 --vcpus=2 --disk path=/mnt/images/test2.img,format=qcow2,size=18 --network bridge:vbr0,mac=52:54:00:87:02:32 --graphics spice --os-variant=fedora21 --pxe 13:18:27 <||> ERROR Error: --disk path=/mnt/images/test2.img,format=qcow2,size=18: Could not start storage pool: cannot open volume '/mnt/images/lost+found': Permission denied 13:18:27 <||> real 0m0.274s 13:18:27 <||> user 0m0.145s 13:18:29 <||> sys 0m0.026s 13:18:33 (master *)$ ll /mnt/images/test2.img -rw-r--r--. 1 quintela quintela 11G Mar 8 13:27 /mnt/images/test2.img 13:18:36 (master *)$ 13:25:05 davidgiluk: Was afk, reading the trace 13:25:19 Err, s/trace/backlog 13:28:57 davidgiluk: Hmm, I haven't tested an L2 of Fedora 22 yet, but I don't see any similar trace in a CirrOS L2. 13:29:49 crobinso: things like Minimal install for server, and select XFce as desktop enviroment for Workstation are not allowed anymore, right? 13:30:09 the otehr thing I seem to have in my nest is; [drm:qxl_send_monitors_config [qxl]] *ERROR* head 5 wrong: 12781344x12584736+12584736+12584736 13:30:18 actually, Workstation allowed me if I wanted to install libreofficce or not, that is it. 13:30:35 * davidgiluk isn't too sure what side to file that against 13:30:47 spice somewhere, but kernel, qemu or what 13:31:03 davidgiluk: in doubt, all of them! 13:31:09 #alwayshelping O:-) 13:31:16 quintela: that virt-install issue is kind of a known problem, there's bugs about it. trying to make a storage pool out of folders with volumes we can't read causes issues 13:31:17 and why it only does it in my L2 I don't know 13:31:39 quintela: about installing xfce on server, not too sure. my install testing is limited to selecting defaults :) 13:32:33 davidgiluk: if you file against spice or xorg-x11-drv-qxl, the same guys look at both and they can help triage further 13:32:51 crobinso: Thanks, yes 13:41:26 https://bugzilla.redhat.com/show_bug.cgi?id=1212484 13:41:34 that's the weird qxl messages 13:46:06 * satellit adding gnome-boes to f22 Mate RC-3 with yumex 13:46:14 boxes* 13:48:17 * satellit had to add launcher to main menu 14:05:20 boxes 3.16.0 worked installed f22 betaRc2 workstation x86_64 sucessfully root but no user pswd in anaconda. G-I-S worked and set up user and logged in fine 14:05:58 gnome 3.16.0 llvm 3.5, 128 bits 14:06:51 * satellit in f22 RC3 MAte live install to USB ext HD 14:07:56 satellit: cool. you testing rc2 or rc3 ? 14:08:51 rc2 in HD and wks.iso no time to reinstall all 14:09:21 (going through scrollback) crobinso: libvirt *doesn't* support the usermode networking port forwarding. One of the boxes guys sent a patch for it a long time ago, but it needed work to be more general (so it could potentially work with a NAT connection) and nobody had time for a followup. 14:09:53 laine: Hmm, pity; for a desktop use it would be quite nice 14:10:36 well, actually usermode networking should die in a fire :-P 14:11:21 davidgiluk: gnome-boxes used slirp for a while, and have been trying to get away from it for the past year 14:11:32 crobinso: What does it use instead? 14:11:45 davidgiluk: the virbr0-from-usermode thing I mentioned 14:11:50 crobinso: Ah OK 14:12:07 davidgiluk: slirp is nice that it 'just works'... but for some very limited definition of 'works'. can't even ping for example 14:12:10 the qemu bridge helper (which, ironically, should *also* die in a fire. Unfortunately there is no alternative for unprivileged libvirt :-( ) 14:12:46 crobinso: Actually I think it can ping now - certainly when I was trying it before it triggered an SELinux warning that I had to switch on a bool 14:13:11 * satellit I understand only difference in RC2-3 is backgroud updates of gnome... 14:13:20 laine: and that's why we still have slirp 14:14:26 I still have a hard time understanding why people want to use unprivileged libvirtd. Is it because they don't have admin access to their machine? Or is it because there are multiple users and they want to have the guests of each invisible to the others? Or? 14:15:50 laine: I don't understand your confusion - why would you want to give people root access by default all the time 14:16:29 satellit: oh cool, I haven't been following the blocker bugs much 14:16:41 laine: It's also not that unusual to have setups where the users aren't allowed root on their install 14:17:09 You aren't giving them full root access. via libvirt's policy stuff you give them access just to the parts of libvirtd they need access to. And the qemu process that is started has *even less* privilege/access to the system than one started by an unprivileged libvirtd. 14:17:40 laine: I was told that as soon as you give users access to libvirt's socket you're effectively giving them root 14:17:58 laine: it does simplify a lot of management headaches that virt-manager has had to deal with: like the runaround it takes to get 'qemu' to access an iso in $HOME, and then the permissions are left wonky after the VM shuts down. it's all kinda awkward 14:18:41 davidgluk: I haven't heard that before. Was this recently, or awhile ago? 14:19:16 laine: 6 months ish 14:19:42 crobinso: Yeh the relabelling is just weird for normal desktop uses 14:20:20 eblake_: since danpb isn't here, do you have an opinion on the "tastes just like root"? 14:20:38 laine: Given that I can create an XML specifying an arbitrary qemu binary and arbitrary paths to devices and add arbitrary options to the qemu, I think it's pretty open 14:20:41 laine: if you have access to system libvirtd, you could storage APIs to read any file on the machine for example 14:20:50 * eblake_ reading scrollback 14:21:38 * satellit note the saved boxes instance did not take name of the f22 workstation it used got it from xxx.iso in Downloads directory. Renamed it in check/properties 14:22:48 If you're not able to turn that off, I'd say the policy stuff needs work then. unprivileged libvirtd should at most be a frontend to API calls to system libvirtd (with appropriate auth). 14:22:59 Anyway, I shouldn't hijack the test day with this... 14:23:00 giving users access to root's libvirtd without turning on ACLs is giving the user full root access - they need merely define a domain XML that reuses a system file as a disk, then run a malicious guest that compromises that file 14:23:34 but with ACLs, you can allow users to start guests but not define them, for example, so that you can let users run pre-defined guests from the root libvirtd but not define arbitrary guests 14:23:38 and that plugs the hole 14:23:58 eblake_: But then can they create new VMs of their own? 14:24:16 unprivileged guests are a lot less to worry about security wise (they can't do anything the user couldn't already do), but the lack of user networking is a huge drawback 14:24:35 you can set up ACLs so that a user is not allowed to create new VMs, only reuse existing ones 14:25:06 as long as the ACLs prevent the user from creating arbitrary guests, you've closed the hole of arbitrary guests being used to circumvent root 14:25:20 eblake_: OK, that's better but still quite restrictive 14:25:40 ACLs are a tricky beast - I don't know how easy or hard it is to set up a policy that would still be useful 14:25:40 would be nice if you could allow them to create/edit, but put restrictions on each element of the XML. 14:25:55 Might be difficult to describe in config though. 14:26:12 laine: Yes and you'd have to write a lot of code you'd have to be very very careful of 14:26:23 the ACL privilege code is written to use polkit, which means it can be arbitrarily complex javascript to decide if a user is allowed or denied permission on a per-operation basis 14:26:52 yes but you'd end up writing a lot of very complex javascript to do anything meaningful 14:26:57 so you can write code that vets that a proposed XML definition is safe, for whatever definition of safe you deem appropriate, and then allow the creation 14:27:10 but it is definitely not a trivial task 14:28:01 the thing mentioned before about passing the network to an unpriv libvirt seems much nicer for the desktop cases 14:28:26 definitely easier for the user :-) 14:28:28 that lets people do whatever they want to their own image files etc 14:28:32 laine: Yep 14:28:38 yeah I don't think using ACLs to allow an untrusted user to create VMs makes much sense. it would really be about having a mapping of 'user1 can start/stop/pause vm1' 14:29:17 it might be possible to require that domain creation use only images from a given storage pool 14:29:36 and then let the user manage that pool to their heart's content 14:29:37 crobinso: Which to be fair might be enough for many admin-supplied laptop/desktop configs 14:29:43 how about 'user1 can create disk images totalling up to 100GB in storage pool "engineering"'? 14:30:00 eblake_: you'd still have to be careful of anywhere else that lets you pass paths or options etc 14:30:03 davidgiluk: right, the ACLs are definitely useful 14:30:11 in other words, it's easier to prove whether domain xml uses pools for all than it is to prove that all files mentioned in each is safe 14:30:24 davidgiluk: they just aren't a general case alternative to full qemu:///system or qemu:///session 14:30:31 crobinso: yep 14:30:59 laine: Leave that problem to the filesystem, ah but you can only do that if the files are owned by that user 14:32:25 crobinso: Does the new virt-manager do something clever where it populates the list of VMs during the connect rather than waiting until it's got the whole list? 14:33:30 davidgiluk: more lazy than clever :) are you seeing VMs visually stream in? 14:33:43 crobinso: Yep 14:34:25 davidgiluk: I reworked a lot of the initial polling code and that was an unintended side effect. was bugging me too but not sure if anyone would care or notice. but if you file a bug I'll take another look at it 14:34:57 crobinso: No, I like it! 14:35:33 davidgiluk: ah :) I guess it could be useful if you're on a slow connection, but the stuttering bugs me :) 14:36:09 crobinso: it's just better than waiting for ages to know it's working 14:36:44 davidgiluk: yeah I need to play with slow connections more, to feel the pain of my co-workers and make sure things don't regress 14:38:11 crobinso: Please do :-) I'm working w/ 4 Mbits/sec speed here, need to upgrade it. 14:38:37 crobinso: It's mostly latency I think rather than bandwidth for me; I've got about 180ms between here and the machines I use in boston 14:39:01 davidgiluk: yeah latency is the killer 14:41:11 (actually 155ms today) 14:41:33 crobinso: You get fun things like not being able to hit the f12 to get the boot menu, because the spice connection hasn't come up in time 14:42:55 davidgiluk: yeah spice must be painful since we have to open so many channels behind the scenes, and have to serialize opening them. VNC should be much quicker on startup at least 14:43:10 right 14:43:33 crobinso: And spice also hits some problem with scrolling where there's a round trip in there for scrolling a linux text console 14:43:57 interesting 14:53:52 * laine is about to do "yum update --releasever=22 distro-sync" on an actual machine (after just doing yum update with updates-testing enabled). Any last recommendations? (e.g. "Stop! Don't do it!" :-O) 14:54:53 laine: worked fine for me on last attempt :) though around alpha time it was kinda rough 14:55:13 Okay, here goes... 14:55:34 that's how I upgraded this laptop (without updates-testing I think) a couple of days back 14:55:57 after fedora-updater refused to play 15:00:08 laine: After that, I also normally do: (1) package-cleanup --cleandupes; package-cleanup --leaves; package-cleanup --orphans (2) `rpmconf -a` that lets you decide what to do with: .rpmnew, .rpmsave files 15:00:43 And, optionally, rebuild the rpmbd (`sudo rpm --rebuilddb`) 15:01:08 remember yum is now yum-depreciated otherwise get dnf 15:01:45 yum is simlink 15:02:01 * laine once had two versions of almost every package installed due to yum crapping out in the middle of an upgrade, and was severly bummed before discovering package-cleanup --cleandupes 15:02:29 "yum-unappreciated" :-) 15:03:46 * satellit yum-deprecated? sp 15:04:27 nah. "yum-depreciated" is the command that will become worth less and less at each release, until it finally does nothing useful :-) 15:05:12 but some ops work betted in old yum...until all fuctions are migrated...? 15:05:19 better* 15:06:05 * satellit sorry abt off topic 15:06:56 I learned the other day that dnf by default silently ignores even security updates if they would cause a conflict, rather than giving an error or even warning. Yikes. 15:08:01 yes 15:08:50 I worry abt yumex-dnf in leveral lives that use it as main updater 15:09:05 several* 15:09:50 * satellit mate lxde included 15:10:28 * satellit xfce also 15:10:38 besides, I just like the image of my computer chowing down on yummy new versions of packages :-) (I know that's not where the name is from, but still like it) 15:11:17 : / fedora likes cutting edge...: / 15:12:28 I am downloading RC3 live .isos for boxes testing as we speak 15:14:06 https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC3_Installation?rd=Test_Results:Current_Installation_Test#Which_tests_to_run 15:16:10 Hmm. After eliminating problems due to rpmfusions packages (surprisingly few), I now am having trouble because of qemu-system-tricore-2.3.0 and libvirt-python-1.2.12 (both from fedora-virt-preview). 15:32:15 * davidgiluk assumes laine has something to run on tricore 15:34:02 davidgiluk: libguestfs pulls in all the qemu emulators by default IIRC, so it's on quite a few machines 15:34:10 ah 15:34:13 I doubt anyone has ever used the fedora package tho 15:34:53 there's a meta package 'qemu' which pulls in everything, and I believe libguestfs depends on that... or one of the libvirt RPMs 15:35:30 I think we depend on libvirt actually 15:35:34 which depends on qemu 15:35:45 does anyone care about that? 15:35:54 (libvirt-daemon-kvm probably) 15:40:46 actually repoquery isn't pointing to libguestfs. it's just libvirt-daemon-qemu->qemu->qemu-system-* 15:41:23 I want to test qcow images over NFS, but I can't for the life of me get NFS to mount on this F22 beta 15:41:43 http://fpaste.org/211956/29198899/ 15:41:50 Job for rpc-statd.service failed. See "systemctl status rpc-statd.service" and "journalctl -xe" for details. 15:42:07 davidgiluk: nope, nothing to run on tricore - that package was just automatically installed as a dependency when I enabled virt-preview repo. 15:43:04 Apr 16 08:41:59 virt-test.web-ster.com rpc.statd[1817]: failed to create RPC listeners, exiting 15:43:11 has anyone got NFS working on F22 beta? 15:43:27 * davidgiluk tries a mount 15:43:38 bakers: I don't have an nfs setup, sorry 15:44:18 bakers: OK, so that's the easy one - mounting an existing NFS share works 15:44:39 davidgiluk: What's the easy one? 15:44:55 bakers: I mounted an NFS share on my f22 laptop - that works 15:45:08 bakers: but lets see about exporting 15:45:22 davidgiluk: I'm just mounting (client) a CentOS 7 server 15:45:26 I can't get statd to start 15:45:46 Logs are not very helpful 15:45:59 bakers: TBH I'm not sure what the server is (It's about 3000 miles away over a VPN) but it certainly mounted OK on this f22 laptop 15:46:48 bakers: What does it show if you do journalctl -u rpc-statd.service 15:47:22 davidgiluk: http://fpaste.org/211960/91992371/ 15:48:04 * laine used nfs a couple months ago, but have to re-remember how to make it work each time I do it. 15:48:30 bakers: there's a recent thread here with that problem, haven't read through it though: https://bbs.archlinux.org/viewtopic.php?id=193410 15:48:37 bakers: Hmm, I apparently have a running statd, so I think that's the problem you've got 15:50:21 crobinso: That worked! I had to start rpcbind first 15:51:01 Weird it doesn't indicate that in the log files 16:00:54 crobinso: I'm up and working, thanks 16:03:02 bakers: cool :) 16:07:15 that sounds like there is a missing dependency 16:31:25 crobinso: I'm here also; just in a meeting atm ... so I will have a late start today 16:31:35 jsnow: hey! no worries 16:33:09 crobinso: I did get RC2 installed via UEFI usb key onto /dev/sdb on my lenovo yoga, though, and that went mostly well 16:34:32 jsnow: good to hear 16:35:46 * jsnow will start banging away on proper tests ... 16:39:46 I also installed via USB (EFI) to ext USB HD workstation and It booted on YogaPro2 16:40:40 wireless worked and got full screen unlike a KDE installed the same way which was microscopic 16:40:53 f22 RC2 16:42:18 satellit: f22 KDE? 16:43:19 yes on EFI USB install to Ext USB HD it was tiny screen-need magnifier to see cahanged screen setting so I could read it 16:43:25 changed* 16:43:42 * satellit plasma worked though 16:44:03 hehe, curious it didn't use the full res at startup 16:44:15 https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC2_Installation#Default_boot_and_install 16:44:38 YogaPro2 has v hi res screen 16:44:59 workstation could handle it 16:44:59 yeh 17:04:54 crobinso: do you have a preference on what guests I test with? (should I do Fedora 22 RC2 inside a HW f22rc2?) I've also got a large repository of windows guests 17:06:10 crobinso: getting this error launching either virt-viewer or virt-manager: WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-6NGy4Jqd2X: Connection refused 17:07:34 crobinso: i've ssh'ed to a bare metal system with -XC and confirmed that xclock displays correctly. 17:10:28 jenelson: Can I suggest something gnomeish instead - something that uses more than plain X 17:13:23 jsnow: f22 has been tested plenty, so testing windows guests would be good 17:13:31 crobinso: you got it 17:13:54 jenelson: is it actually failing to run, or is that just a warning ? 17:14:03 davidgiluk: gnome-terminal hangs with the same error 17:14:19 jenelson: running modern desktop apps over ssh -X tends to print a lot of those 17:14:21 crobinso: it's a warning; the process continues to run, but no window appears on my desktop 17:14:58 btw, desktop is running f21 17:16:41 jenelson: I'd say use virt-preview repo, download latest virt-manager onto f21, then use a remote connection in virt-manager to talk to f22 libvirt+kvm 17:17:21 can any of you guys try in your guest a dmesg | grep qxl and see if you see something about Head 5 being wrong 17:19:47 davidgiluk: will check 17:20:31 if you do see it then please add to https://bugzilla.redhat.com/show_bug.cgi?id=1212484 17:21:02 davidgiluk: doesn't appear for me 17:21:08 interesting 17:21:20 crobinso: I've got it in one L2 f22, and an L1 ubuntu 17:22:12 hmm, except it's gone now from there - weird 17:22:24 * davidgiluk is bet on it reading some uninitialised memory 17:28:20 crobinso: ack. 17:41:45 what would you expect the ownership on /dev/sr0 to be after using a CDROM in the guest and then shutting down the guest - returned to the user? It's shown as qemu.qemu 17:43:18 davidgiluk: that's due to libvirt changing ownership on files passed to the VM, I don't think it has smarts to try and restore owner when the VM shuts down, though there have been various attempts at it 17:43:52 crobinso: Nod 17:44:25 (I pulled a random bootable CD off my shelf - OpenSuse 12.3 gets to the GUI ok using the host CD) 17:47:42 hmmm....virt-manager has a rendering bug - the area taken for the scroll bars in storage views is much larger than the scroll bar itself, so part of the list is blanked out making it appear that the list is a short one. 17:50:23 danofsatx: screenshot? 17:51:24 crobinso: I was fiddling with the OS install page and noticed it had a test for --test-media-detection, so I made you a table of all the isos I own: http://fpaste.org/211999/29206433/ 17:52:05 nago: wow that's a lot of media! 17:52:27 crobinso: I was told not to let my MSDN subscription go to waste. :) 17:53:23 http://i.imgur.com/F7JYN3a.png 17:55:35 danofsatx: what desktop are you using? 17:56:58 crobinso: interestingly it seems like the media detection gives up far more often than it gets it right, at least for me :) 17:58:06 jsnow: it's all based on ISO volume IDs, and obviously libosinfo's regex is not sufficient. 17:59:33 jsnow: can you file a bug against libosinfo, and attach a a file or archive containing isoinfo -d -i run against each iso ? 17:59:46 crobinso: F22 Workstation, GNOME 3.16. Two more: first showing the bottom list cutoff, the second showing both the top and bottom cut off after one notch scroll with the wheel - http://i.imgur.com/4hqUP7C.png http://i.imgur.com/9gP7PCG.png 18:00:26 crobinso: yes, n.p. 18:00:41 danofsatx: can you run virt-manager --debug and reproduce, and see if there are any gtk errors printed to stdout ? 18:00:55 danofsatx: my guess is this isn't virt-manager's fault since we aren't doing anything interesting with that list 18:01:21 danofsatx: are you using a non-standard desktop theme then? icons don't look like stock gnome. could be theme related 18:01:41 yeah, I was thinking it could be the theme. 18:01:52 danofsatx: also there should be a newer virt-manager in updates-testing 18:02:02 not sure if it would matter here though 18:02:53 no gtk errors in debug mode 18:03:24 I'll go back to the default theme in a bit - everytime I switch themes, Konversation crashes. 18:25:09 crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1212599 18:25:57 jsnow: thanks! 18:26:07 yw 18:26:41 There's actually more ISOs on the service that I am patiently retrieving, I tend to download about 5-10 a day as I remember to 18:37:08 crobinso, admittedly I have not used the libvirt/virsh stuff as much as maybe I ought: should virt-install actually work as written in https://fedoraproject.org/wiki/QA:Testcase_Virtualization_CDROM_Guest_Install ? http://fpaste.org/212024/09365142/ 18:38:00 nago: is libvirt-daemon-config-network installed? probably need to install that, then restart libvirt 18:38:28 sec. fwiw going through virt-manager and the wizard worked just peachily 18:38:48 libvirt-daemon-config-network.x86_64 1.2.13-2.fc22 @System 18:38:56 nago: there's weirdness with that package so we don't pull it in by default, but 'yum groupinstall virtualization' brings it in. that said virt-install should explicitly warn about it rather than let libvirt error, since we can detect it easily 18:39:09 nago: strange, not sure why virt-install failed then 18:39:43 default network might not have been running, virt-manager will offer to start it, but the libvirt error doesn't suggest that 18:39:53 nago: does the virt-install issue reproduce? 18:40:22 yeah, it says it every time. I started a virt-manager install via the wizard to see if it would work (and it did, just fine) then tried the virt-install again, which still doesn't work. 18:41:13 ah, but rebooting libvirt did fix it. 18:41:46 nago: still strange though. can you pastebin 'sudo virsh dumpxml $vmname' for the VM you created with virt-manager ? 18:42:46 yes, ein minuten bitte 18:43:41 actually, why don't I finish this virt-install version and I will send you both so we can peep at the diff 18:44:32 nago: cool 18:52:03 FYI I just did a Virtulbox EFI flag set install of f22 Workstation RC-3 netinstall x86 and it boots 18:53:18 * satellit "Enable EFI" 19:04:17 weirdest problem. google-chrome doesn't let me post certain text blobs into fpaste.org. firefox works fine. *shrug* 19:07:15 crobinso, http://fpaste.org/212034/42921121/ 19:09:27 nago: virt-manager succeeded because it fell back to 'no network' :/ 19:09:42 ah, okay fun 19:09:53 nago: can you file a virt-manager bug with this info? there's some improvements here 19:10:15 sure. I also think that virt-install should delete the qcow2 it makes in these cases, they will just litter the drive otherwise 19:10:44 nago: one of the other pre-existing bugs is this: https://bugzilla.redhat.com/show_bug.cgi?id=867546 19:10:54 nago: yeah good point, file a bug for the disk cleanup too 19:11:05 pre-existing conditions; covered by fedora healthcare? ... 19:14:54 nago: :) more like, 'will linger unattended for too long' 19:26:36 is there no virt-install component under fedora in the RH bugzilla? 19:27:29 will just use libvirt and the powers that be will sort me out 19:29:39 there - I finally got F22 up and running on my box 19:30:12 hurray 19:30:22 and my very first problem: 'virsh event $dom --all' is broken (I already patched it upstream, looks like I should backport that to the maint branch used in Fedora) 19:30:52 nago: virt-install is a subpackage of virt-manager, so use component=virt-manager 19:31:14 eblake_: what does 'virsh event' do? 19:31:32 it lets you snoop for all events from the hypervisor, with optional filtering by domain name 19:31:39 except the filtering by domain is broken in 1.2.14 19:31:57 fixed upstream in commit 9289c85, so I'll backport that to the maint branch 19:34:48 crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1212616 19:35:04 crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1212617 19:35:40 crobinso: should I go ahead and add my bug report to the wiki page, to show that our test day is finding things? or just silently fix it? 19:35:45 crobinso: virt-preview repo enabled, upgraded. remote does work, but I am constantly asked for root@remote password. is there a way to authenticate once and for all? 19:36:24 eblake_: I'll take a bug :) 19:36:33 jenelson: ssh keys 19:36:34 what's the wiki page again? 19:37:08 eblake_: https://fedoraproject.org/wiki/Test_Day:2015-04-16_Virtualization 19:37:22 jsnow: thanks dude 19:38:06 crobinso: it probably works out that I have hardly used these interfaces. they're getting the idiot test. :x 19:38:17 crobinso: ok, but ssh-copy-id reports: WARNING: All keys were skipped because they already exist on the remote system. 19:38:34 crobinso: isn't there some helper-thingy i have to launch in the background? 19:38:45 jenelson: were they copied to root@ on the remote system? or just your username 19:38:50 crobinso: root 19:39:23 jenelson: hmm probably, gnome-shell always does it for me so I'm not positive 19:40:14 jenelson: ssh-agent bash, then ssh-add maybe? but not sure if that works with virt-manager, since it has daemonize itself to get ssh to cooperate 19:44:25 oops - wrong commit id above; I meant 31ef0836 19:44:48 at any rate, bug 1212620 now filed 19:46:46 crobinso: yeah, ssh-agent is what i was remembering. 19:47:18 crobinso: it is running, and it is actively managing the only key i have 19:48:34 jenelson: are you only getting the password dialogs when connecting to the VM graphical viewer, or when connecting to libvirt as well ? 19:49:15 jenelson: outside of virt, can you ssh to that machine without entering a password ? 19:49:19 crobinso: once when setting up the remote connection, a bunch of times connecting to the running guest 19:49:27 crobinso: yes, ssh w/o password works 19:50:26 heh, very funny disclaimer on the f22 installation screen. 19:50:46 jenelson: use virt-manager --debug, it might help, that prevents virt-manager from forking. but if it doesn't work, you'll get ssh prompts on stdout 19:50:55 I guess you can't amend a table entry once you've put it in 19:51:10 Sorry, folks I had to run away from computer for a few hours to deal with some emergency, couldn't participate fully in test day. 19:52:04 Anyhow, I normally test from latest Virt bits on a day-day basis, so I don't have to feel bad :-) 19:52:52 kashyap: don't worry about it :) but you missed a decent amount of chatter. last couple test days were quiet 19:53:15 crobinso: fsck. my bad. i launched virt-manager from my desktop as -root-. 19:53:16 crobinso: is F22 using 1.2.13 or 1.2.14? I guess I have fedora-virt-preview running on my F22 box 19:53:28 jenelson: ah :) it happens 19:53:41 eblake_: Oh, I was wondering when you said 'virsh event' doesn't work as expected, this is what you mean? "error: internal error: virsh event: no domain VSH_OT_DATA option" 19:53:46 so I've actually been testing 1.2.14 (because that's what's in rawhide) instead of 1.2.13-2 19:53:53 kashyap: yep - that's the error 19:54:00 eblake_: Hmm, never mind, I noticed the bug which you fixed - 1212620 19:54:03 crobinso: I bring chatter with me where I go. :s 19:57:17 A small RFE for libosinfo, to provide metadata for CirrOS - https://bugzilla.redhat.com/show_bug.cgi?id=1212409 19:57:35 * kashyap heads out for the night 19:59:08 not a big fan of gnome3's general layout and workspace paradigm, but I *am* a big fan of these command notifications that certain programs pop-up. "hey, that thing you launched is ready for your attention now!" 20:00:18 nago: yeah that's a nice improvement they added this cycle. first time I saw it I got angry and turned it off. then I heard other people raving about it, gave it two seconds of thought, and realized it's actually super helpful :) 20:00:53 yeah it's actually been a major boon the last two days because it keeps me from getting too distracted doing $other_things while I am waiting for something else 20:01:02 "hey, come back, ADD kid, your dinner's ready" 20:01:12 I'm waiting to see if they change the input focus in any way. If they do, then I'm out. 20:02:07 I still think I hate GNOME in general, though... but it really does seem like it has a stupid amount of features, so I'd almost feel guilty going back to XFCE at this point... 20:02:38 laine: ++ anything that changes input focus out from underneath me is evil. 20:04:21 My favorite gnome features are "segfault and freeze for several minutes while dumping core" and "use 100% of one core while frozen for an indefinite period" which have been happening to me at least once or twice a week on F21 for the last few months. 20:05:37 laine: lol 20:06:31 so PCI passthrough of a VF from a network pool works. 20:07:19 I created a Q35 machine but it won't let me migrate it. Who's the guy I yell at for this? ... 20:10:09 nago: what's the error? 20:10:45 laine: what's a network pool? 20:11:27 crobinso, I'm being cheeky. it's a feature that I am responsible for that didn't make it into QEMU 2.3 so it's not expected to work yet 20:11:56 nago: ah i see :) thought it was plausible there was libvirt check rejecting it or something 20:13:21 crobinso, no ... Q35 machines by default use an emulated SATA controller, but it has been marked as non-migratable for a long time. I was NACK'd for 2.3, but it'll be in 2.4 or I will quit Red Hat in shameful self-hatred 20:16:20 crobinso, had a failure downloading a package using Virt-Manager to install via URL. I suspect it's not reproducible, but it is upsetting that it declares the error "unrecoverable" 20:17:28 nago: yeah installing pre-release fedora will hit that quite a bit unfortunately, since repos can be in an inconsistent state. using the ISOs can avoid that 20:18:01 aaand via virt-install, it appears to have just simply frozen 20:28:55 crobinso: Gonna switch rooms then I'll be ready to do some testing 20:29:10 bakers: cool 20:31:46 crobinso: sorry, I've been distracted in #virt. A network pool is when a network definition contains a list of physical devices that can be given out for macvtap or PCI passthrough in a guest. 20:32:49 laine: ah, I'm out of the loop on a lot of libvirt features it seems :) 20:33:24 Here's an example of using it to make PCI passthrough of SRIOV VFs simpler to deal with: http://tinyurl.com/p3cx6p7 20:34:10 crobinso: What specifically would you like tested? 20:34:31 In that case you only put the netdev name of the PF device in the pool, and libvirt fills in the list of VF PCI addresses when you start the network. Then you have guests that have a simple 20:35:28 bakers: check the test cases listed here: https://fedoraproject.org/wiki/Test_Day:2015-04-16_Virtualization#Areas_to_test 20:35:50 bakers: you can report results in the tool over here: http://209.132.184.193/testdays/show_event?event_id=25 20:36:08 crobinso, Have you ever been to OSCon? Have I met you OSCon before? 20:36:50 bakers: never been to OSCon, not sure if we've met ? 20:41:20 crobinso: have we ever thought of any other ways to make the live image not come up with a default network for libvirt that would cripple things when installed? 20:41:37 I know that boxes had to rebuild again for F22 to work around the issue 20:41:51 eblake_: laine had an idea, but it's non-trivial 20:42:05 is it possible to write the libvirt postinstall scripts to probe the hostname, assuming the live image compose has a well-known hostname? 20:42:35 Oh, *that* again. Sigh. 20:42:49 eblake_: that's even hackier than my hack :-P 20:43:32 What I was thinking of is: 1) make libvirtd start depend on networking being started (don't know how reasonable/feasible that is) 20:43:41 eblake_: I don't think it has a well known hostname, compose is just done in koji. but that would be a righteous hack :) 20:44:03 hmmmm 20:44:36 2) define a new type of network called "superdefault" or something like that, where the network definition would give a starting subnet, a range, and libvirt would try each subnet in that range until it found one that didn't conflict with an existing route on the system. 20:46:24 systemd allows one-shot services, right? 20:46:35 eblake_: Depends on your definition 20:47:53 I guess I'm thinking of something that only runs one time, with a dependency on networking, and whose job is to install everything else with a non-conflicting range that will then come up every time but no longer depend on networking 20:48:04 eblake_: oneshot in systemd terminology basically means: 20:48:09 "Behavior of oneshot is similar to simple; however, it is expected 20:48:09 that the process has to exit before systemd starts follow-up units. 20:48:10 RemainAfterExit= is particularly useful for this type of service. 20:48:10 This is the implied default if neither Type= or ExecStart= are 20:48:10 specified." 20:48:25 then I guess oneshot isn't what I'm thinking of 20:48:47 so you're looking for "only runs once, ever"? 20:48:50 but something where installing libvirt makes the first boot slow enough to ensure we avoid conflicts, but then rewrites itself so that subsequent boots drop the dependency 20:49:05 so the first boot runs only once 20:49:30 For that, I'd use a oneshot that just checked for the presence of a stamp file somewhere and make that run Before=libvirtd.service 20:49:33 if I understand, the problem we are trying to avoid is having libvirt always depend on networking 20:49:58 but depending on networking for one time only will let us avoid the subnet collision 20:50:12 If the stamp file exists, then have it no-op. If it doesn't exist, have it do whatever setup you need, then let libvirt start 20:50:55 just idle ideas, since this is the second release in a row where we've had to cripple boxes to avoid a live image that has a conflicting subnet installation by default 20:51:00 But that's still not *perfect* if all you really want is a one-time ordering 20:51:12 Yeah, I've been following that bug 20:52:30 What I suggested above still might work, though. 20:52:54 You write a script that sleeps and runs 'systemctl is-active network.target' every second if the stampfile doesn't exist. 20:53:16 Once network.target is active, write the stampfile and exit success. 20:53:36 eblake_: It's a bit hacky, but it could work 21:00:35 This can't be solved at image build time, it has to be done anew each time libvirt starts on the target system. You can't assume that the environment will be the same the next time. 21:01:21 A livecd is built in mock on koji, and it could be run on real hardware, or it could be run in a virtual machine, and either case it might have different networking under it. 21:01:49 but if we depend on a stamp file for the witness of whether to loop on waiting for the network, vs. completing right away, then the live cd would exist without the stamp file 21:01:54 and thus loop for the network every time 21:02:12 while the common case (second and subsequent boots of a persistent system) will have the stamp file and not wait for networking 21:02:28 Ah, I see what you're getting at. 21:06:21 There are all sorts of shenanigans going on though that have to be taken into account. For example, the livecd image may actually have to start up the packages that are installed in mock (yeah, I guess it must). And once that happens and you have a livecd image, it gets booted somewhere and if you tell it "Install Fedora" then it doesn't download and install packages, it actually copies most of the livecd image onto the target disk di 21:06:21 rectly (to save time), then maybe does a bit of tweaking. 21:06:36 It's all pretty cool. And ugly. But cool. 21:12:59 Huh. I don't know if this happened on earlier versions or not, as I didn't pay attention. But if virt-manager gets disconnected due to restarting libvirtd and I click to reconnect right away, it will reconnect. If I instead wait [several minutes - maybe 10?], when I click to reconnect it will immediately get rejected with this: 21:13:03 polkitd[1345]: Operator of unix-session:2 FAILED to authenticate to gain authorization for action org.libvirt.unix.manage for unix-process:7868:832978 [/usr/bin/python2 -tt /usr/share/virt-manager/virt-manager] (owned by unix-user:laine) 21:13:14 So is that worth a BZ, or just to be expected? 21:14:05 laine: does it repeatedly fail to connect? or a one-off failure? 21:14:20 laine: and do you have any custom polkit rules? 21:16:04 will be back in a few to continue hammering away at things 21:16:07 crobinso: 1) repeatedly until I exit virt-manager and start it again, 2) no 21:16:16 (not that I'm aware of anyway) 21:16:59 laine: yeah file a bug, I'll see if I can reproduce. this is just connected to local libvirt right ? 21:18:32 crobinso: yes. 21:18:46 I only noticed it because I'm splitting my time between so many things 21:21:09 crobinso: i'm testing the aarm64 vm install. 21:21:27 crobinso: vm starts, unpacks stuff, asks me to either start a vnc session or go raw tty. i pick vnc, server starts, i see f22 language/keyboard page. so far so good. 21:22:01 crobinso: next screen is install summary. "Network & Hostname" has orange cone saying "Not connected" but it is. vnc is running on it. 21:23:40 jenelson: yeah my guess is that's just aarch64 installer bugs. I'd say just get as far as you can and ensure qemu doesn't crash :) 21:24:15 jenelson: only thing I could find was alpha media which is a month old 21:26:29 crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1212639 21:26:55 laine: thanks 21:29:13 okay, time to look into dinner... 21:51:18 Anyone else having issues with soft shutdown? 21:51:29 I get VM guest not responding 21:51:39 Sorry I mean reboot. Soft shutdown does work. 21:52:25 bakers: haven't heard that, but I don't try reboot that much since it historically never worked for me :) it's supposed to be better nowadays since we setup qemu-guest-agent 21:52:39 bakers: but if it's reproducible, please file a qemu bug 21:52:48 crobinso, Ok will do 21:57:46 kaboom 22:28:42 I'm testing cloud images... anyone know the root password for a cloud image? 22:29:36 bakers: check the 'import install' test case, it explains things. 22:30:03 bakers: by default though the cloud images are locked, they expect find a cloud-init device to set an initial password 22:30:09 bakers: which the desktop tools don't provide 22:30:20 bakers: so you need to use virt-customize 22:30:25 crobinso, Gotcha 22:30:37 I forgot how absolutely awful it was to get windows to *do* anything from a fresh install. 22:31:12 click here! look at this popup! you need to set this! wait, there's ten rounds of updates! 22:32:27 you can't get updates until you install the new windows update! would you like to do that? *opens window to do that* --> popup is triggered; YOU NEED UPDATES PLEASE CLICK HERE TO GET UPDATES 22:32:37 * nago is having an ugly couple of minutes. 22:38:28 nago, I feel your pair 22:38:30 errr... pain 22:39:45 Is Fedora 22 in beta yet? Or are we still alpha? 22:39:57 that's a rather unfortunate typo :p 22:40:15 nago, I know right :) 22:43:18 Going on just the URL, I think this counts as a Beta release. 22:45:40 crobinso, I've never done cloud images before. There is some cloud-init service that configures passwords? How does that work? 22:49:13 crobinso, I have managed to hang anaconda twice now trying to do net installs 22:49:28 once via virt-install and once via virt-manager. Guest just totally freezes up and CPU usage goes to 0%. 22:51:12 bakers: there's a daemon inside the VM. when the VM boots, daemon looks for either a disk device with a sepecific label, or talks to a well know IP address. fetches data from the source, uses it to setup default passwords 22:51:30 bakers: cloud providers will startup these disk images with the metadata available 22:51:43 guest appears totally deadlocked, won't accept terminal switch hotkeys, etc 22:51:52 bakers: so it standardizes setting up initial passwords, SSH keys, inside VMs, independent of cloud architecture 22:52:04 crobinso, So it connects to some well known IP (192.168.x.x) and fetches the password? Via http? or how? 22:52:11 Gotcha 22:52:51 I don't really have good diagnostics for this -- I am hesitant to file a bug. Thoughts? 22:52:58 crobinso, So I've done virt-customize twices on my F22 cloud image, and when it boots it hangs on the cloud-init service looking for a server to connect to 22:53:02 I assume that's not expected? 22:53:14 haha 22:54:04 Am I correct in assuming that if the box has a root password that it should NOT try the cloud-init stuff? 22:56:46 I stand corrected... the cloud image did boot with my changed root password. It did take about 5 minutes of timeout waiting for cloud-init though 22:59:40 bakers: yeah cloud-init is fun like that. in the import test case, I have a virt-customize command for disabling it 23:00:10 nago: nah don't bother on the bug, I just might recruit you to try again come GA freeze time to make sure it's working :) 23:00:31 crobinso: ok, I did mention the failure on the test results page though 23:00:38 jsnow: cool 23:00:58 the install itself seems fine, but there's something racy about anaconda inside QEMU that keeps locking up 23:01:14 so there's an emulation race somewhere. the netinst mechanisms are probably themselves fine 23:04:23 I've also got a nagging feeling I am hitting a bug I have seen somewhere before 23:04:54 I think someone popped into one of the VM channels within the last month to complain that windows update was spinning fruitlessly for them, and I suspect i am seeing that same behavior right now 23:11:37 I can't find that earlier report :\ 23:31:40 It's just dog slow. It does unstick eventually, but I can't shake the feeling that there's something really wrong with exactly how slow certain actions inside this VM are, and how high the CPU utilization is ... 23:31:44 something to pursue later 23:59:27 jhuston: you are a man of many IRC names 00:05:41 whoops 00:05:47 not on porpoise 00:06:04 for whatever reason my connection to freenode from the office is very bad 00:06:45 not uncommon for me to lose my freenode connection for days at a time for reasons currently unclear to me, but I don't often need to be on freenode so it is usually just a minor inconvenience 00:19:31 whoaaaaaaaaa. spice USB redirection. whoaaaa. 00:30:21 #endmeeting