09:17:35 <crobinso_away> #startmeeting virt_test_day_f21
09:17:35 <zodbot> Meeting started Thu Sep 25 09:17:35 2014 UTC.  The chair is crobinso_away. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:17:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
09:18:07 <crobinso_away> morning all. but I've got to drive my fiance to the airport so I won't be back for a couple hours :) just starting the meeting to catch IRC logs
09:18:52 <kashyap> Morning, Cole.
09:19:13 <kashyap> There a bunch of people here, take your time :-)
09:36:46 <rwmjones> unfortunately my dev system is now dead ..
09:38:03 <kashyap> Update to F21 did it?
09:44:53 <adamw> rwmjones: what, it's not a vm? :)
09:48:53 <kashyap> For those who're testing nested virt w/ libvirt+QEMU+KVM, just some quick notes here:
09:49:00 <kashyap> #link https://kashyapc.fedorapeople.org/virt/procedure-to-enable-nested-virt-on-intel-machines.txt
09:49:23 <kashyap> It uses the very handy `virt-xml` tool.
09:58:08 <rwmjones> no it's a real machine, UEFI is dead
11:49:17 * crobinso is back now
12:10:38 <davidgiluk> anyone seeing sshd throwing 'dyntransition' selinux warnings on an f21 host with a remote virt-manager trying to connect to it?
12:11:35 <davidgiluk> hmm, it looks like it's mislabelled after upgrade
12:13:04 * kashyap tries with plain virsh
12:14:26 <rwmjones> davidgiluk: probably unrelated, but the entire system was wrongly labelled after I did a yum update to F21 .. I had to boot into a rescue disk and touch /.autorelabel
12:15:25 <davidgiluk> rwmjones: Maybe not unrelated - lots of /usr/sbin is wrongly labelled
12:15:39 * davidgiluk goes to ask in -qa
12:16:36 <kashyap> This works just fine: $ virsh --connect qemu+ssh://remotehost/system list
12:18:09 <kashyap> (Although I use libvirt URI aliases configured in /etc/libvirt/libvirt.conf, instead of typing out the long command above.)
13:26:31 * pbrobinson waves to adamw
13:26:35 <adamw> pbrobinson: ahoy
14:06:51 * crobinso hears crickets
14:48:36 * eblake joins the party
15:10:12 * davidgiluk guesses he should think about trying the live migration; I guess if I put virt-preview on here (f20 laptop) it should then work to my f21 box
15:11:09 <eblake> davidgiluk: yes, live migration between F20 fedora-virt-preview and F21 should work
15:11:37 <eblake> in fact, we also would like to know that F20 to F21 works (but not necessarily F21 back to F20 - downgrades aren't supported, but upgrades should work)
15:12:37 <davidgiluk> eblake: f20 is 1.6.1 I think, so I'd give that a pretty low chance, 1.6.x has an odd bug
15:17:39 <davidgiluk> eblake: http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00513.html  so it might work if we get the right machine type
15:26:05 <roshi> how goes the test day?
15:26:46 <crobinso> davidgiluk: f20 -> f21 migration better work, otherwise people's snapshots would stop working :) I have a small test suite that checks basic migration isn't totally broken
15:26:50 <crobinso> roshi: pretty quiet
15:27:37 <crobinso> davidgiluk: broken across fedora versions that is
15:27:43 <roshi> well, I can try to be a bit louder if it helps :)
15:27:53 <davidgiluk> crobinso: Oh ok, maybe there's hope!
15:28:23 <crobinso> davidgiluk: but that's just qemu migration format, I rarely test actual network migration which has a lot of moving parts in libvirt that can regress. so testing real migration is definitely valuable
15:28:40 <crobinso> roshi: more noise can't hurt :)
15:31:15 <roshi> updating packages now
15:31:51 <roshi> fwiw, I've been using F21 virt tools since branch with no issues (aside from some UI artifacts not showing up)
15:33:37 <crobinso> roshi: cool, good to know
15:42:05 <roshi> I trust we're using the testday app for results?
15:42:30 <roshi> I see what you mean by it's quiet around here
15:47:19 <roshi> crobinso: did we get anything in the magazine for today?
15:47:45 <roshi> I think I might write something up for it here quick
15:47:56 <roshi> I'll be around today if people show up
15:48:07 <roshi> not sure how long you guys have been here or are planning to be here
15:50:15 <crobinso> roshi: I'll probably be here for another 8-9 hours :)
15:50:27 <crobinso> roshi: yeah sorry, we are using the app for results reporting
15:50:46 <crobinso> roshi: and a mention in the magazine would be appreciated
15:52:44 <davidgiluk> now, all I need to do is remember the magic rune to get iscsi tgt to work
15:54:30 <roshi> sounds good
15:54:49 <roshi> I'll write up a draft, let you proof it
16:07:57 <eblake> just thinking about the bash bug - I guess <qemu:cmdline> can be used to pass bogus env-vars to a qemu child and thus trigger the bug, but that's not escalation (you can't start a domain without already being privileged)
16:08:41 <eblake> do we have anything else in libvirt where we allow user-controlled environment variables to affect child processes, and where the env-vars are set at runtime?
16:09:48 <eblake> setting an env-var before spawning libvirtd is not an issue (if you have privileges to spawn libvirtd, it's your own fault), so even on older libvirt where we use shell to call iptables commands (instead of dBus), the shell we spawn is inheriting only the env-vars that were present when libvirtd was started, and not env-vars under user control
16:17:57 * davidgiluk is seeing libvirtd errors about isciadm
16:19:02 <davidgiluk> libvirtd[1022]: internal error: Child process (iscsiadm --mode discovery --type sendtargets --portal major.local:3260,1) unexpected exit status 21: iscsiadm: No portals found
16:19:20 <davidgiluk> that's f21 host
16:24:01 <davidgiluk> hmm, works better if I use the IP address, doesn't seem to like the avahi name
16:30:56 <jenelson> crobinso: greetings. it's my first test day. :)
16:31:22 <jenelson> crobinso: (you know me as jen)
16:31:25 <crobinso> jenelson: howdy jeff :)
16:31:45 <jenelson> crobinso: what's the magazine? what reporting tool?
16:32:06 <roshi> crobinso: http://fpaste.org/136479/16627031/
16:32:24 <crobinso> jenelson: start here: https://fedoraproject.org/wiki/Test_Day:2014-09-25_Virtualization
16:32:47 <crobinso> jenelson: the reporting tool is where you basically say PASS/FAIL for the recommended test cases on that page
16:33:10 <crobinso> jenelson: it's linked at the bottom. but if you haven't read the page yet, I'd suggest reading the first few sections
16:34:13 <roshi> that look alright crobinso
16:34:15 <roshi> ?
16:34:29 <crobinso> roshi: sorry missed it, one sec
16:34:58 <roshi> no worries :)
16:34:59 <crobinso> roshi: awesome dude, looks good. thanks a lot!
16:35:12 <roshi> np - letting the mktg people know I'm doing it :)
16:42:38 <davidgiluk> if I hit a bug on virt-preview, do I file it against f20 or f21?
16:44:19 <eblake> davidgiluk: file it on f21
16:44:38 <davidgiluk> ok
16:44:38 <eblake> virt-preview is the f21 bits exposed early on f20, but doesn't mean the problem exists for normal f20 users
16:45:10 <davidgiluk> right#
16:53:10 <davidgiluk> hmm - what's the right way to do this?  migrate from another machine on my network to 'localhost' - I get an error because the other machine doesn't know the DNS name of the laptop; is that a reasonable failure?
16:54:13 <eblake> yes, the failure makes sense (the source of the migration has to know how to get to the destination, and 'localhost' is not a good destination)
16:54:43 <eblake> you can pass the raw IP address of your localhost as the destination for the remote side source to use as its  migration target
16:55:01 <eblake> although it's been a while since I've attempted anything like that, so I'm fuzzy on the details
16:58:25 <davidgiluk> eblake: Should that be needed if the tunnel through libvirt box is ticket?
16:58:27 <davidgiluk> ticked?
16:59:45 <eblake> davidgiluk: are you trying to do the migration through the virt-manager gui?
16:59:53 <eblake> that's more a question crobinso can answer
16:59:54 <roshi> up on the magazine now crobinso
16:59:59 <roshi> sorry I didn't do it earlier
17:00:34 <davidgiluk> eblake: I'll write the bug up first
17:01:54 <crobinso> davidgiluk: yeah I'd have to see the details. we do attempt to determine the local hosts ip/hostname IIRC, so maybe we are screwing up
17:02:01 <crobinso> roshi: thanks again
17:02:09 <roshi> np
17:02:17 <roshi> onto doing some actual testing
17:22:50 <davidgiluk> hmm, managed a migrate in one direction - doesn't want to go back
17:43:49 <crobinso> davidgiluk: re: that migration CPU issue, I've definitely pin pointed part of the problem. when the VM is migrated, part of spice-gtk's usb handling isn't properly free'd. I think it has something to do with spice's 'seamless migrate' support, where it has special behavior when it detects migration. still digging though
17:44:03 <davidgiluk> crobinso: No problem
17:45:24 <davidgiluk> crobinso: I just filed https://bugzilla.redhat.com/show_bug.cgi?id=1146664   frankly I've not got a clue if it's virt-manager or libvirt
19:21:06 <roshi> this install from URL test was taking forever
19:23:35 <crobinso> roshi: yeah it takes quite a while...
19:23:47 <roshi> I need more ram
19:23:53 <roshi> :)
19:23:59 <roshi> but isn't that always the case?
19:36:40 <roshi> well, 33 views on the magazine article
23:05:02 <crobinso> I'm jumping offline, thanks for the help everyone
23:05:04 <crobinso> #endmeeting
23:06:53 <crobinso> hmm, does zodbot not confirm when the meeting is ended? or is that the wrong command...
23:11:21 <nirik> zodbot: listmeetings
23:11:23 <zodbot> nirik: ('#fedora-docs', 'freenode'), ('#fedora-test-day', 'freenode'), ('#fudcon-planning', 'freenode')
23:12:21 <nirik> #endmeeting