11:21:56 <crobinso> #startmeeting virt_test_day_f22
11:21:56 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
11:22:19 <crobinso> morning all
11:23:33 * kashyap waves
11:34:34 <kparal> 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 <crobinso> kparal: satellit: no worries, adding test results later is still appreciated
11:58:20 <crobinso> davidgiluk: did you just hit that virt-manager spice socket crasher?
11:58:35 <davidgiluk> 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 <crobinso> davidgiluk: ah so you aren't running latest virt-manager?
11:59:20 * crobinso is relieved
12:00:11 <davidgiluk> 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 <crobinso> davidgiluk: that's interesting, haven't noticed that but I don't use VM IP that much. f22 VM ?
12:12:46 <davidgiluk> crobinso: yeh, f22 on f22
12:12:53 <davidgiluk> (installing an f22 into that :-)
12:13:40 <davidgiluk> 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 <quintela> It is me, or virt-install don't have --os_variant=fedora22?
12:14:52 <crobinso> quintela: yeah it's missing: https://bugzilla.redhat.com/show_bug.cgi?id=1211797
12:15:11 <quintela> 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 <crobinso> davidgiluk: usermode == nat? or do you mean qemu slirp?
12:17:51 <davidgiluk> 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 <quintela> Using slirp at this age O:-)
12:19:05 <crobinso> davidgiluk: there is a way to do port forwarding with slirp, but I don't recall if libvirt supports it
12:19:45 <quintela> davidgiluk: -redir something
12:19:55 <quintela> davidgiluk: I stand that you want to use proper bridge support.
12:19:59 <crobinso> 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 <davidgiluk> 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 <quintela> qemu-system-i386 -net user,hostfwd=tcp::5555-:23 [...]
12:20:38 <quintela> telnet localhost 5555
12:20:46 <davidgiluk> quintela: Right, that's what I wanted
12:21:10 <quintela> davidgiluk: that is the new syntax
12:22:02 <davidgiluk> quintela: Yep, just no way of doing it via the GUIs
12:23:15 <davidgiluk> crobinso: You say that libvirt will allow an unprivilged user to do that - how?
12:23:49 <crobinso> davidgiluk: <network><source bridge="virbr0"/></network>
12:24:24 <davidgiluk> crobinso: ah, but not via the network details gui ?
12:24:28 <crobinso> davidgiluk: you can allow unprivileged access to other host bridges by extending /etc/qemu/bridge.conf
12:24:50 <crobinso> davidgiluk: should be possibly via virt-manager, let me look
12:25:44 <crobinso> 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 <davidgiluk> sure
12:30:05 <davidgiluk> https://bugzilla.redhat.com/show_bug.cgi?id=1212443
12:36:12 <davidgiluk> hmm, just managed to get a spice crash;
12:37:22 <crobinso> 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 <crobinso> davidgiluk: backtrace mentioned the spice migration channel
12:38:15 <davidgiluk> crobinso: I'm just waiting for abrt to download ~750MB of debuginfo packages and then we'll see
12:38:23 <crobinso> :)
12:39:19 <davidgiluk> 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 <crobinso> davidgiluk: yeah that will definitely stress things :)
12:48:23 <davidgiluk> 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 <crobinso> 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 <davidgiluk> crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1212454    any idea which spice package that should be against?
12:54:43 <davidgiluk> spice-server?
12:54:45 <crobinso> davidgiluk: component=spice
12:54:48 <davidgiluk> ok
12:55:13 <quintela> humm, what is the "civilized way" of convincing f22 that I want to use systemd-networkd?
12:55:21 <quintela> If I can do that on the kickstart, the better.
12:56:28 <crobinso> quintela: hmm no idea, I haven't used it
12:57:11 <quintela> 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 <quintela> not sure if only 5 mins of praying is enoug ...
12:57:23 <davidgiluk> 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 <davidgiluk> 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 <crobinso> satellit: gnome-boxes testing is definitely useful
13:12:03 <satellit> k will reboot from centos7 mate....
13:12:42 <satellit_e> rebooting...
13:15:55 <quintela> crobinso: do you mean previously that I should be able to run virt-install as a normal user?
13:17:23 <quintela> I am clearly doing something wrong.  I just did s|qemu:///system/|qemu:///session|
13:17:29 <quintela> and make sure that I can write into the file
13:17:34 <crobinso> 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 <quintela> (master *)$ ll /mnt/images/test2.img -rw-r--r--. 1 quintela quintela 11G Mar  8 13:27 /mnt/images/test2.img
13:18:36 <quintela> (master *)$
13:25:05 <kashyap> davidgiluk: Was afk, reading the trace
13:25:19 <kashyap> Err, s/trace/backlog
13:28:57 <kashyap> 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 <quintela> crobinso: things like Minimal install for server, and select XFce as desktop enviroment for Workstation are not allowed anymore, right?
13:30:09 <davidgiluk> 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 <quintela> 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 <davidgiluk> spice somewhere, but kernel, qemu or what
13:31:03 <quintela> davidgiluk: in doubt, all of them!
13:31:09 <quintela> #alwayshelping O:-)
13:31:16 <crobinso> 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 <davidgiluk> and why it only does it in my L2 I don't know
13:31:39 <crobinso> quintela: about installing xfce on server, not too sure. my install testing is limited to selecting defaults :)
13:32:33 <crobinso> 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 <davidgiluk> crobinso: Thanks, yes
13:41:26 <davidgiluk> https://bugzilla.redhat.com/show_bug.cgi?id=1212484
13:41:34 <davidgiluk> that's the weird qxl messages
13:46:06 * satellit adding gnome-boes to f22 Mate RC-3 with yumex
13:46:14 <satellit> boxes*
13:48:17 * satellit had to add launcher to main menu
14:05:20 <satellit> 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 <satellit> 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 <crobinso> satellit: cool. you testing rc2 or rc3 ?
14:08:51 <satellit> rc2 in HD and wks.iso  no time to reinstall all
14:09:21 <laine> (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 <davidgiluk> laine: Hmm, pity; for a desktop use it would be quite nice
14:10:36 <laine> well, actually usermode networking should die in a fire :-P
14:11:21 <crobinso> davidgiluk: gnome-boxes used slirp for a while, and have been trying to get away from it for the past year
14:11:32 <davidgiluk> crobinso: What does it use instead?
14:11:45 <crobinso> davidgiluk: the virbr0-from-usermode thing I mentioned
14:11:50 <davidgiluk> crobinso: Ah OK
14:12:07 <crobinso> 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 <laine> the qemu bridge helper (which, ironically, should *also* die in a fire. Unfortunately there is no alternative for unprivileged libvirt :-( )
14:12:46 <davidgiluk> 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 <davidgiluk> laine: and that's why we still have slirp
14:14:26 <laine> 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 <davidgiluk> laine: I don't understand your confusion - why would you want to give people root access by default all the time
14:16:29 <crobinso> satellit: oh cool, I haven't been following the blocker bugs much
14:16:41 <davidgiluk> laine: It's also not that unusual to have setups where the users aren't allowed root on their install
14:17:09 <laine> 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 <davidgiluk> 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 <crobinso> 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 <laine> davidgluk: I haven't heard that before. Was this recently, or awhile ago?
14:19:16 <davidgiluk> laine: 6 months ish
14:19:42 <davidgiluk> crobinso: Yeh the relabelling is just weird for normal desktop uses
14:20:20 <laine> eblake_: since danpb isn't here, do you have an opinion on the "tastes just like root"?
14:20:38 <davidgiluk> 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 <crobinso> 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 <laine> 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 <laine> Anyway, I shouldn't hijack the test day with this...
14:23:00 <eblake_> 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 <eblake_> 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 <eblake_> and that plugs the hole
14:23:58 <davidgiluk> eblake_: But then can they create new VMs of their own?
14:24:16 <eblake_> 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 <eblake_> you can set up ACLs so that a user is not allowed to create new VMs, only reuse existing ones
14:25:06 <eblake_> 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 <davidgiluk> eblake_: OK, that's better but still quite restrictive
14:25:40 <eblake_> 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 <laine> would be nice if you could allow them to create/edit, but put restrictions on each element of the XML.
14:25:55 <laine> Might be difficult to describe in config though.
14:26:12 <davidgiluk> laine: Yes and you'd have to write a lot of code you'd have to be very very careful of
14:26:23 <eblake_> 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 <davidgiluk> yes but you'd end up writing a lot of very complex javascript to do anything meaningful
14:26:57 <eblake_> 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 <eblake_> but it is definitely not a trivial task
14:28:01 <davidgiluk> the thing mentioned before about passing the network to an unpriv libvirt seems much nicer for the desktop cases
14:28:26 <laine> definitely easier for the user :-)
14:28:28 <davidgiluk> that lets people do whatever they want to their own image files etc
14:28:32 <davidgiluk> laine: Yep
14:28:38 <crobinso> 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 <eblake_> it might be possible to require that domain creation use only images from a given storage pool
14:29:36 <eblake_> and then let the user manage that pool to their heart's content
14:29:37 <davidgiluk> crobinso: Which to be fair might be enough for many admin-supplied laptop/desktop configs
14:29:43 <laine> how about 'user1 can create disk images totalling up to 100GB in storage pool "engineering"'?
14:30:00 <davidgiluk> eblake_: you'd still have to be careful of anywhere else that lets you pass paths or options etc
14:30:03 <crobinso> davidgiluk: right, the ACLs are definitely useful
14:30:11 <eblake_> in other words, it's easier to prove whether domain xml uses pools for all <disks> than it is to prove that all files mentioned in each <disk> is safe
14:30:24 <crobinso> davidgiluk: they just aren't a general case alternative to full qemu:///system or qemu:///session
14:30:31 <davidgiluk> crobinso: yep
14:30:59 <davidgiluk> 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 <davidgiluk> 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 <crobinso> davidgiluk: more lazy than clever :) are you seeing VMs visually stream in?
14:33:43 <davidgiluk> crobinso: Yep
14:34:25 <crobinso> 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 <davidgiluk> crobinso: No, I like it!
14:35:33 <crobinso> davidgiluk: ah :) I guess it could be useful if you're on a slow connection, but the stuttering bugs me :)
14:36:09 <davidgiluk> crobinso: it's just better than waiting for ages to know it's working
14:36:44 <crobinso> 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 <kashyap> crobinso: Please do :-) I'm working w/ 4 Mbits/sec speed here, need to upgrade it.
14:38:37 <davidgiluk> 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 <crobinso> davidgiluk: yeah latency is the killer
14:41:11 <davidgiluk> (actually 155ms today)
14:41:33 <davidgiluk> 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 <crobinso> 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 <davidgiluk> right
14:43:33 <davidgiluk> 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 <crobinso> 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 <crobinso> laine: worked fine for me on last attempt :) though around alpha time it was kinda rough
14:55:13 <laine> Okay, here goes...
14:55:34 <davidgiluk> that's how I upgraded this laptop (without updates-testing I think) a couple of days back
14:55:57 <davidgiluk> after fedora-updater refused to play
15:00:08 <kashyap> 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 <kashyap> And, optionally, rebuild the rpmbd (`sudo rpm --rebuilddb`)
15:01:08 <satellit> remember yum is now yum-depreciated otherwise get dnf
15:01:45 <satellit> 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 <laine> "yum-unappreciated" :-)
15:03:46 * satellit yum-deprecated?  sp
15:04:27 <laine> 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 <satellit> but some ops work betted in old yum...until all fuctions are migrated...?
15:05:19 <satellit> better*
15:06:05 * satellit sorry abt off topic
15:06:56 <laine> 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 <satellit> yes
15:08:50 <satellit> I worry abt yumex-dnf in leveral lives that use it as main updater
15:09:05 <satellit> several*
15:09:50 * satellit mate lxde included
15:10:28 * satellit xfce also
15:10:38 <laine> 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 <satellit> : / fedora likes cutting edge...: /
15:12:28 <satellit> I am downloading RC3 live .isos for boxes testing as we speak
15:14:06 <satellit_e> https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC3_Installation?rd=Test_Results:Current_Installation_Test#Which_tests_to_run
15:16:10 <laine> 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 <crobinso> davidgiluk: libguestfs pulls in all the qemu emulators by default IIRC, so it's on quite a few machines
15:34:10 <davidgiluk> ah
15:34:13 <crobinso> I doubt anyone has ever used the fedora package tho
15:34:53 <crobinso> 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 <rwmjones> I think we depend on libvirt actually
15:35:34 <rwmjones> which depends on qemu
15:35:45 <rwmjones> does anyone care about that?
15:35:54 <rwmjones> (libvirt-daemon-kvm probably)
15:40:46 <crobinso> actually repoquery isn't pointing to libguestfs. it's just libvirt-daemon-qemu->qemu->qemu-system-*
15:41:23 <bakers> 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 <bakers> http://fpaste.org/211956/29198899/
15:41:50 <bakers> Job for rpc-statd.service failed. See "systemctl status rpc-statd.service" and "journalctl -xe" for details.
15:42:07 <laine> 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 <bakers> Apr 16 08:41:59 virt-test.web-ster.com rpc.statd[1817]: failed to create RPC listeners, exiting
15:43:11 <bakers> has anyone got NFS working on F22 beta?
15:43:27 * davidgiluk tries a mount
15:43:38 <crobinso> bakers: I don't have an nfs setup, sorry
15:44:18 <davidgiluk> bakers: OK, so that's the easy one - mounting an existing NFS share works
15:44:39 <bakers> davidgiluk: What's the easy one?
15:44:55 <davidgiluk> bakers: I mounted an NFS share on my f22 laptop - that works
15:45:08 <davidgiluk> bakers: but lets see about exporting
15:45:22 <bakers> davidgiluk: I'm just mounting (client) a CentOS 7 server
15:45:26 <bakers> I can't get statd to start
15:45:46 <bakers> Logs are not very helpful
15:45:59 <davidgiluk> 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 <davidgiluk> bakers: What does it show if you do     journalctl -u rpc-statd.service
15:47:22 <bakers> 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 <crobinso> 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 <davidgiluk> bakers: Hmm, I apparently have a running statd, so I think that's the problem you've got
15:50:21 <bakers> crobinso: That worked! I had to start rpcbind first
15:51:01 <bakers> Weird it doesn't indicate that in the log files
16:00:54 <bakers> crobinso: I'm up and working, thanks
16:03:02 <crobinso> bakers: cool :)
16:07:15 <davidgiluk> that sounds like there is a missing dependency
16:31:25 <jsnow> crobinso: I'm here also; just in a meeting atm ... so I will have a late start today
16:31:35 <crobinso> jsnow: hey! no worries
16:33:09 <jsnow> 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 <crobinso> jsnow: good to hear
16:35:46 * jsnow will start banging away on proper tests ...
16:39:46 <satellit> I also installed via USB (EFI) to ext USB HD workstation and It booted on YogaPro2
16:40:40 <satellit> wireless worked and got full screen unlike a KDE installed the same way which was microscopic
16:40:53 <satellit> f22 RC2
16:42:18 <davidgiluk> satellit: f22 KDE?
16:43:19 <satellit> 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 <satellit> changed*
16:43:42 * satellit plasma worked though
16:44:03 <davidgiluk> hehe, curious it didn't use the full res at startup
16:44:15 <satellit> https://fedoraproject.org/wiki/Test_Results:Fedora_22_Beta_RC2_Installation#Default_boot_and_install
16:44:38 <satellit> YogaPro2 has v  hi res screen
16:44:59 <satellit> workstation could handle it
16:44:59 <davidgiluk> yeh
17:04:54 <jsnow> 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 <jenelson> 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 <jenelson> crobinso: i've ssh'ed to a bare metal system with -XC and confirmed that xclock displays correctly.
17:10:28 <davidgiluk> jenelson: Can I suggest something gnomeish instead - something that uses more than plain X
17:13:23 <crobinso> jsnow: f22 has been tested plenty, so testing windows guests would be good
17:13:31 <jsnow> crobinso: you got it
17:13:54 <crobinso> jenelson: is it actually failing to run, or is that just a warning ?
17:14:03 <jenelson> davidgiluk: gnome-terminal hangs with the same error
17:14:19 <crobinso> jenelson: running modern desktop apps over ssh -X tends to print a lot of those
17:14:21 <jenelson> crobinso: it's a warning; the process continues to run, but no window appears on my desktop
17:14:58 <jenelson> btw, desktop is running f21
17:16:41 <crobinso> 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 <davidgiluk> 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 <crobinso> davidgiluk: will check
17:20:31 <davidgiluk> if you do see it then please add to https://bugzilla.redhat.com/show_bug.cgi?id=1212484
17:21:02 <crobinso> davidgiluk: doesn't appear for me
17:21:08 <davidgiluk> interesting
17:21:20 <davidgiluk> crobinso: I've got it in one L2 f22, and an L1 ubuntu
17:22:12 <davidgiluk> hmm, except it's gone now from there - weird
17:22:24 * davidgiluk is bet on it reading some uninitialised memory
17:28:20 <jenelson> crobinso: ack.
17:41:45 <davidgiluk> 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 <crobinso> 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 <davidgiluk> crobinso: Nod
17:44:25 <davidgiluk> (I pulled a random bootable CD off my shelf - OpenSuse 12.3 gets to the GUI ok using the host CD)
17:47:42 <danofsatx> 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 <crobinso> danofsatx: screenshot?
17:51:24 <nago> 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 <crobinso> nago: wow that's a lot of media!
17:52:27 <jsnow> crobinso: I was told not to let my MSDN subscription go to waste. :)
17:53:23 <danofsatx> http://i.imgur.com/F7JYN3a.png
17:55:35 <crobinso> danofsatx: what desktop are you using?
17:56:58 <jsnow> 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 <crobinso> jsnow: it's all based on ISO volume IDs, and obviously libosinfo's regex is not sufficient.
17:59:33 <crobinso> 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 <danofsatx> 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 <nago> crobinso: yes, n.p.
18:00:41 <crobinso> danofsatx: can you run virt-manager --debug  and reproduce, and see if there are any gtk errors printed to stdout ?
18:00:55 <crobinso> danofsatx: my guess is this isn't virt-manager's fault since we aren't doing anything interesting with that list
18:01:21 <crobinso> danofsatx: are you using a non-standard desktop theme then? icons don't look like stock gnome. could be theme related
18:01:41 <danofsatx> yeah, I was thinking it could be the theme.
18:01:52 <crobinso> danofsatx: also there should be a newer virt-manager in updates-testing
18:02:02 <crobinso> not sure if it would matter here though
18:02:53 <danofsatx> no gtk errors in debug mode
18:03:24 <danofsatx> I'll go back to the default theme in a bit - everytime I switch themes, Konversation crashes.
18:25:09 <jsnow> crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1212599
18:25:57 <crobinso> jsnow: thanks!
18:26:07 <nago> yw
18:26:41 <nago> 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 <nago> 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 <crobinso> nago: is libvirt-daemon-config-network installed? probably need to install that, then restart libvirt
18:38:28 <nago> sec. fwiw going through virt-manager and the wizard worked just peachily
18:38:48 <nago> libvirt-daemon-config-network.x86_64            1.2.13-2.fc22            @System
18:38:56 <crobinso> 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 <crobinso> nago: strange, not sure why virt-install failed then
18:39:43 <crobinso> 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 <crobinso> nago: does the virt-install issue reproduce?
18:40:22 <nago> 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 <nago> ah, but rebooting libvirt did fix it.
18:41:46 <crobinso> nago: still strange though. can you pastebin 'sudo virsh dumpxml $vmname' for the VM you created with virt-manager ?
18:42:46 <nago> yes, ein minuten bitte
18:43:41 <nago> 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 <crobinso> nago: cool
18:52:03 <satellit> 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 <nago> weirdest problem. google-chrome doesn't let me post certain text blobs into fpaste.org. firefox works fine. *shrug*
19:07:15 <nago> crobinso, http://fpaste.org/212034/42921121/
19:09:27 <crobinso> nago: virt-manager succeeded because it fell back to 'no network' :/
19:09:42 <nago> ah, okay fun
19:09:53 <crobinso> nago: can you file a virt-manager bug with this info? there's some improvements here
19:10:15 <nago> 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 <crobinso> nago: one of the other pre-existing bugs is this: https://bugzilla.redhat.com/show_bug.cgi?id=867546
19:10:54 <crobinso> nago: yeah good point, file a bug for the disk cleanup too
19:11:05 <nago> pre-existing conditions; covered by fedora healthcare? ...
19:14:54 <crobinso> nago: :) more like, 'will linger unattended for too long'
19:26:36 <nago> is there no virt-install component under fedora in the RH bugzilla?
19:27:29 <nago> will just use libvirt and the powers that be will sort me out
19:29:39 <eblake_> there - I finally got F22 up and running on my box
19:30:12 <nago> hurray
19:30:22 <eblake_> 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 <crobinso> nago: virt-install is a subpackage of virt-manager, so use component=virt-manager
19:31:14 <crobinso> eblake_: what does 'virsh event' do?
19:31:32 <eblake_> it lets you snoop for all events from the hypervisor, with optional filtering by domain name
19:31:39 <eblake_> except the filtering by domain is broken in 1.2.14
19:31:57 <eblake_> fixed upstream in commit 9289c85, so I'll backport that to the maint branch
19:34:48 <jsnow> crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1212616
19:35:04 <jsnow> crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1212617
19:35:40 <eblake_> 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 <jenelson> 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 <crobinso> eblake_: I'll take a bug :)
19:36:33 <crobinso> jenelson: ssh keys
19:36:34 <eblake_> what's the wiki page again?
19:37:08 <crobinso> eblake_: https://fedoraproject.org/wiki/Test_Day:2015-04-16_Virtualization
19:37:22 <crobinso> jsnow: thanks dude
19:38:06 <jsnow> crobinso: it probably works out that I have hardly used these interfaces. they're getting the idiot test. :x
19:38:17 <jenelson> crobinso: ok, but ssh-copy-id reports: WARNING: All keys were skipped because they already exist on the remote system.
19:38:34 <jenelson> crobinso: isn't there some helper-thingy i have to launch in the background?
19:38:45 <crobinso> jenelson: were they copied to root@ on the remote system? or just your username
19:38:50 <jenelson> crobinso: root
19:39:23 <crobinso> jenelson: hmm probably, gnome-shell always does it for me so I'm not positive
19:40:14 <crobinso> 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 <eblake_> oops - wrong commit id above; I meant 31ef0836
19:44:48 <eblake_> at any rate, bug 1212620 now filed
19:46:46 <jenelson> crobinso: yeah, ssh-agent is what i was remembering.
19:47:18 <jenelson> crobinso: it is running, and it is actively managing the only key i have
19:48:34 <crobinso> 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 <crobinso> jenelson: outside of virt, can you ssh to that machine without entering a password ?
19:49:19 <jenelson> crobinso: once when setting up the remote connection, a bunch of times connecting to the running guest
19:49:27 <jenelson> crobinso: yes, ssh w/o password works
19:50:26 <jenelson> heh, very funny disclaimer on the f22 installation screen.
19:50:46 <crobinso> 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 <jsnow> I guess you can't amend a table entry once you've put it in
19:51:10 <kashyap> 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 <kashyap> Anyhow, I normally test from latest Virt bits on a day-day basis, so I don't have to feel bad :-)
19:52:52 <crobinso> kashyap: don't worry about it :) but you missed a decent amount of chatter. last couple test days were quiet
19:53:15 <jenelson> crobinso: fsck. my bad. i launched virt-manager from my desktop as -root-.
19:53:16 <eblake_> 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 <crobinso> jenelson: ah :) it happens
19:53:41 <kashyap> 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 <eblake_> 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 <eblake_> kashyap: yep - that's the error
19:54:00 <kashyap> eblake_: Hmm, never mind, I noticed the bug which you fixed - 1212620
19:54:03 <jsnow> crobinso: I bring chatter with me where I go. :s
19:57:17 <kashyap> 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 <nago> 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 <crobinso> 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 <nago> 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 <nago> "hey, come back, ADD kid, your dinner's ready"
20:01:12 <laine> I'm waiting to see if they change the input focus in any way. If they do, then I'm out.
20:02:07 <nago> 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 <jenelson> laine: ++ anything that changes input focus out from underneath me is evil.
20:04:21 <laine> 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 <nago> laine: lol
20:06:31 <laine> so PCI passthrough of a VF from a network pool works.
20:07:19 <nago> 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 <crobinso> nago: what's the error?
20:10:45 <crobinso> laine: what's a network pool?
20:11:27 <nago> 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 <crobinso> nago: ah i see :) thought it was plausible there was libvirt check rejecting it or something
20:13:21 <nago> 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 <nago> 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 <crobinso> 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 <nago> aaand via virt-install, it appears to have just simply frozen
20:28:55 <bakers> crobinso: Gonna switch rooms then I'll be ready to do some testing
20:29:10 <crobinso> bakers: cool
20:31:46 <laine> 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 <crobinso> laine: ah, I'm out of the loop on a lot of libvirt features it seems :)
20:33:24 <laine> 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 <bakers> crobinso: What specifically would you like tested?
20:34:31 <laine> 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 <interface type='network'><source network='passthrough'/></network>
20:35:28 <crobinso> bakers: check the test cases listed here: https://fedoraproject.org/wiki/Test_Day:2015-04-16_Virtualization#Areas_to_test
20:35:50 <crobinso> bakers: you can report results in the tool over here: http://209.132.184.193/testdays/show_event?event_id=25
20:36:08 <bakers> crobinso, Have you ever been to OSCon? Have I met you OSCon before?
20:36:50 <crobinso> bakers: never been to OSCon, not sure if we've met ?
20:41:20 <eblake_> 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 <eblake_> I know that boxes had to rebuild again for F22 to work around the issue
20:41:51 <crobinso> eblake_: laine had an idea, but it's non-trivial
20:42:05 <eblake_> 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 <laine> Oh, *that* again. Sigh.
20:42:49 <laine> eblake_: that's even hackier than my hack :-P
20:43:32 <laine> 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 <crobinso> 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 <nago> hmmmm
20:44:36 <laine> 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 <eblake_> systemd allows one-shot services, right?
20:46:35 <sgallagh> eblake_: Depends on your definition
20:47:53 <eblake_> 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 <sgallagh> eblake_: oneshot in systemd terminology basically means:
20:48:09 <sgallagh> "Behavior of oneshot is similar to simple; however, it is expected
20:48:09 <sgallagh> that the process has to exit before systemd starts follow-up units.
20:48:10 <sgallagh> RemainAfterExit= is particularly useful for this type of service.
20:48:10 <sgallagh> This is the implied default if neither Type= or ExecStart= are
20:48:10 <sgallagh> specified."
20:48:25 <eblake_> then I guess oneshot isn't what I'm thinking of
20:48:47 <sgallagh> so you're looking for "only runs once, ever"?
20:48:50 <eblake_> 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 <eblake_> so the first boot runs only once
20:49:30 <sgallagh> 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 <eblake_> if I understand, the problem we are trying to avoid is having libvirt always depend on networking
20:49:58 <eblake_> but depending on networking for one time only will let us avoid the subnet collision
20:50:12 <sgallagh> 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 <eblake_> 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 <sgallagh> But that's still not *perfect* if all you really want is a one-time ordering
20:51:12 <sgallagh> Yeah, I've been following that bug
20:52:30 <sgallagh> What I suggested above still might work, though.
20:52:54 <sgallagh> You write a script that sleeps and runs 'systemctl is-active network.target' every second if the stampfile doesn't exist.
20:53:16 <sgallagh> Once network.target is active, write the stampfile and exit success.
20:53:36 <sgallagh> eblake_: It's a bit hacky, but it could work
21:00:35 <laine> 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 <laine> 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 <eblake_> 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 <eblake_> and thus loop for the network every time
21:02:12 <eblake_> 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 <laine> Ah, I see what you're getting at.
21:06:21 <laine> 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 <laine> rectly (to save time), then maybe does a bit of tweaking.
21:06:36 <laine> It's all pretty cool. And ugly. But cool.
21:12:59 <laine> 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 <laine> 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 <laine> So is that worth a BZ, or just to be expected?
21:14:05 <crobinso> laine: does it repeatedly fail to connect? or a one-off failure?
21:14:20 <crobinso> laine: and do you have any custom polkit rules?
21:16:04 <nago_brb> will be back in a few to continue hammering away at things
21:16:07 <laine> crobinso: 1) repeatedly until I exit virt-manager and start it again, 2) no
21:16:16 <laine> (not that I'm aware of anyway)
21:16:59 <crobinso> laine: yeah file a bug, I'll see if I can reproduce. this is just connected to local libvirt right ?
21:18:32 <laine> crobinso: yes.
21:18:46 <laine> I only noticed it because I'm splitting my time between so many things
21:21:09 <jenelson> crobinso: i'm testing the aarm64 vm install.
21:21:27 <jenelson> 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 <jenelson> 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 <crobinso> 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 <crobinso> jenelson: only thing I could find was alpha media which is a month old
21:26:29 <laine> crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1212639
21:26:55 <crobinso> laine: thanks
21:29:13 <laine> okay, time to look into dinner...
21:51:18 <bakers> Anyone else having issues with soft shutdown?
21:51:29 <bakers> I get VM guest not responding
21:51:39 <bakers> Sorry I mean reboot. Soft shutdown does work.
21:52:25 <crobinso> 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 <crobinso> bakers: but if it's reproducible, please file a qemu bug
21:52:48 <bakers> crobinso, Ok will do
21:57:46 <nago> kaboom
22:28:42 <bakers> I'm testing cloud images... anyone know the root password for a cloud image?
22:29:36 <crobinso> bakers: check the 'import install' test case, it explains things.
22:30:03 <crobinso> bakers: by default though the cloud images are locked, they expect find a cloud-init device to set an initial password
22:30:09 <crobinso> bakers: which the desktop tools don't provide
22:30:20 <crobinso> bakers: so you need to use virt-customize
22:30:25 <bakers> crobinso, Gotcha
22:30:37 <nago> I forgot how absolutely awful it was to get windows to *do* anything from a fresh install.
22:31:12 <nago> click here! look at this popup! you need to set this! wait, there's ten rounds of updates!
22:32:27 <nago> 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 <bakers> nago, I feel your pair
22:38:30 <bakers> errr... pain
22:39:45 <bakers> Is Fedora 22 in beta yet? Or are we still alpha?
22:39:57 <nago> that's a rather unfortunate typo :p
22:40:15 <bakers> nago, I know right :)
22:43:18 <nago> Going on just the URL, I think this counts as a Beta release.
22:45:40 <bakers> crobinso, I've never done cloud images before. There is some cloud-init service that configures passwords? How does that work?
22:49:13 <nago> crobinso, I have managed to hang anaconda twice now trying to do net installs
22:49:28 <nago> once via virt-install and once via virt-manager. Guest just totally freezes up and CPU usage goes to 0%.
22:51:12 <crobinso> 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 <crobinso> bakers: cloud providers will startup these disk images with the metadata available
22:51:43 <nago> guest appears totally deadlocked, won't accept terminal switch hotkeys, etc
22:51:52 <crobinso> bakers: so it standardizes setting up initial passwords, SSH keys, inside VMs, independent of cloud architecture
22:52:04 <bakers> crobinso, So it connects to some well known IP (192.168.x.x) and fetches the password? Via http? or how?
22:52:11 <bakers> Gotcha
22:52:51 <nago> I don't really have good diagnostics for this -- I am hesitant to file a bug. Thoughts?
22:52:58 <bakers> 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 <bakers> I assume that's not expected?
22:53:14 <nago> haha
22:54:04 <bakers> 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 <bakers> 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 <crobinso> 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 <crobinso> 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 <jsnow> crobinso: ok, I did mention the failure on the test results page though
23:00:38 <crobinso> jsnow: cool
23:00:58 <nago> the install itself seems fine, but there's something racy about anaconda inside QEMU that keeps locking up
23:01:14 <nago> so there's an emulation race somewhere. the netinst mechanisms are probably themselves fine
23:04:23 <jsnow> I've also got a nagging feeling I am hitting a bug I have seen somewhere before
23:04:54 <jsnow> 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 <jsnow> I can't find that earlier report :\
23:31:40 <jsnow> 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 <jsnow> something to pursue later
23:59:27 <crobinso> jhuston: you are a man of many IRC names
00:05:41 <jhuston> whoops
00:05:47 <jhuston> not on porpoise
00:06:04 <jhuston> for whatever reason my connection to freenode from the office is very bad
00:06:45 <jhuston> 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 <jhuston> whoaaaaaaaaa. spice USB redirection. whoaaaa.
00:30:21 <crobinso> #endmeeting