10:45:07 <crobinso> #startmeeting virt_test_day_f20
10:45:07 <zodbot> Meeting started Tue Oct  8 10:45:07 2013 UTC.  The chair is crobinso. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:45:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
10:46:07 <crobinso> good morning/afternoon/evening folks :)
10:46:22 <mrezanin> crobinso: Hi Cole
10:46:44 <atodorov> crobinso: hi
10:54:38 <atodorov> crobinso: I'm looking at the ARM on x86 test case, can you point me to a doc/RTFM where these dtb files are described and what do they do
10:54:43 <atodorov> or just tell me :)
10:55:21 <atodorov> also I see vexpress-v2p-caX where X has several different values and I wonder what this is
10:56:21 <crobinso> atodorov: dtb = 'device tree binary'. device tree is a text format that describes the hardware layout of a machine. arm hardware typically isn't self describing like x86 and pci is, so you need to give the kernel a file that describes the hw layout of the arm board it is running on
10:56:47 <crobinso> atodorov: but I don't know the difference between the different vexpress variants :) I still have plenty of learning to do myself
10:59:46 <atodorov> crobinso: thanks, that explains a lot :)
11:23:14 <tjanez> After installing F20 Beta TC2, doing 'yum groupinstall virtualization', I followed the Virtualization URL Guest Install testcase
11:24:08 <tjanez> On step 5 of 5, under Advanced options I see 'No networking' and an orange exclamation mark. Is that expected?
11:24:39 <tjanez> This is 'New VM' wizard of virt-manager
11:26:05 <atodorov> tjanez: did you reboot ?
11:26:24 <atodorov> it looks like you don't have a bridge configured and the default NAT network hasn't been created as well
11:26:32 <atodorov> I think this is not expected
11:26:36 <atodorov> crobinso ^^^^
11:26:55 <tjanez> atodorov: no, i didn't reboot
11:27:39 <laine_> libvirt's "default" network *should* be started when libvirtd is started for the first time...
11:28:03 <atodorov> tjanez: is libvirtd running then
11:28:04 <laine_> atodorov: does "virsh net-list --all" show a network named "default"?
11:28:12 <crobinso> tjanez: not expected. I did see that once during testing but I think it's entirely a virt-manager issue, what's 'sudo virsh net-list --all' show ?
11:28:15 <crobinso> :)
11:28:38 <laine_> jynx! Don't you owe me a beer now or something?
11:28:59 <tjanez> systemctl reports libvirtd.service is enabled and running
11:29:15 <crobinso> laine_: kvm forum is coming up, I'll hand you a free beer :)
11:29:29 <tjanez> "virsh net-list --all" -> the table is empty
11:29:38 <laine_> Yeah, for once there is an oppurtunity to pay up on all those beers everybody keeps promising each other :-)
11:30:10 <laine_> So maybe the network config package isn't part of the "virtualization" meta-package?
11:30:14 <atodorov> laine_: yes, networking works for me
11:30:41 <tjanez> laine_: which package are you referring to?
11:30:51 <laine_> just a sec, I'm getting the name...
11:31:04 <laine_> libvirt-daemon-config-network
11:31:27 <laine_> That used to be part of the base libvirt package, but it got split up into several components awhile back.
11:31:33 <crobinso> tjanez: make sure you run that virsh command as root, or explicitly do: virsh --connect qemu:///system net-list --all
11:31:35 <tjanez> laine_: I can confirm this package is not installed
11:32:34 <atodorov> tjanez: it is missing in the virtualization group I guess (or is not a default/mandatory package)
11:32:39 <crobinso> tjanez: yeah that missing package is the cause :) I thought groupinstall virtualization pulled that in, I'll look
11:33:30 <laine_> That wasn't mistakenly pulled out to "fix" the problems with networking when installing virtualization in a virtual machine, was it?
11:33:44 <tjanez> cronbinso: " virsh --connect qemu:///system net-list --all" also returns an empty table
11:34:23 <tjanez> ok, I'll install libvirt-daemon-config-network
11:34:29 <tjanez> and report back
11:34:40 <tjanez> should I manually restart libvirtd.service?
11:35:36 <crobinso> tjanez: yeah, manually restart libvirtd after libvirt-daemon-config-network installs
11:36:32 <tjanez> crobinso: this worked, I now have a default network
11:37:05 <tjanez> Should I file a bug on a missing Requires or will some of you fix it?
11:39:00 <crobinso> tjanez: hmm, one second
11:39:40 <crobinso> tjanez: when you first ran virt-manager, did it ask you about installing any packages ?
11:40:32 <tjanez> No
11:42:16 <crobinso> tjanez: hmm. okay, please file a bug against 'comps' that the virtualization group is missing libvirt-daemon-config-network. FYI 'comps' is the place where we track package groups
11:42:19 <atodorov> crobinso: a question: in the snapshots test case it says: Run snapshot 2, verify ..., Run snapshot 1, ....
11:42:28 <crobinso> tjanez: and cc me on the bug
11:42:37 <bitlord> same problem with network here, as tjanez said,  libvirt-daemon-config-network fixed it
11:42:46 <atodorov> how do I run a snapshot ? do you mean to shut down all running snapshots and then start that one
11:43:09 <atodorov> I don't see a way to switch between the various snapshots otherwise
11:43:41 <tjanez> crobinso: do you prefer putting it in comps vs. a hard-dependency of some other package, e.g. libvirt?
11:44:08 <crobinso> atodorov: select a snapshot, and either right click->run or hit the 'play' button at the bottom.
11:44:20 <atodorov> ok, got it
11:44:25 <crobinso> tjanez: the packages were originally split for various valid reasons so we can't mandate it
11:44:53 <tjanez> crobinso: Ok, thanks for the explanation
11:45:01 <crobinso> tjanez: for example gnome-boxes doesn't care about the network, and it can cause issues if used within a virtual machine. but for the virtualization group package set it should be included at least
11:45:56 <tjanez> crobinso: Aha, I see
11:47:17 <crobinso> atodorov: the UI might not make it clear, but think of the snapshot as a 'screenshot' of your vm. when you take a snapshot, it just kinda sits there in a file and your VM moves on. but you can 'run' that old snapshot and it will revert your VM to the that old memory and disk state. so there isn't really a concept of a 'currently running' snapshot, or more than one 'running' snapshot, they are all just points in time
11:47:25 <laine> Ugh. Many of the fedoraproject mirrors don't have the F20 Alpha iso images :-/ I had to retry several times
11:47:55 <crobinso> laine: yeah the f20 mirrors seem to be in rough shape, I've hit that too
11:48:15 <atodorov> crobinso: I got confused by the State: Running and the active icons in the UI
11:48:27 <atodorov> I guess it can be improved a bit, will file a RFE
11:48:29 <crobinso> laine: dl.fedoraproject.org is the master mirror
11:48:48 <laine> would be nice if the download page would cycle between the different mirrors until it finds one that works, like yum does...
11:49:06 <crobinso> atodorov: ah that makes sense, please file a bug about that, I can reword things
11:49:35 <crobinso> laine: yeah I suspect there's a bug somewhere, I'll ask
11:50:11 <tjanez> laine: atodorov suggested I install Beta TC2 rather than Alpha
11:50:19 <tjanez> laine: http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/
11:50:32 <laine> Oh, thanks for the info. I'll stop my downloads now!
12:00:19 <tjanez> crobinso: Filled the bug and added you on Cc: https://bugzilla.redhat.com/show_bug.cgi?id=1016606
12:00:34 <tjanez> OT: Bugzilla is awfully slow...
12:00:57 <atodorov> crobinso: Launch virt-manager. Start with a shutoff VM. Verify that the guest has a  'Channel qemu-ga' device listed in its hardware details.
12:01:19 <atodorov> crobinso: is it expected this device to be there by default  or not? I don't see it but I can add it and start the test
12:02:30 <crobinso> atodorov: it should be there by default. one or yours bug indicated your were missing virtio console as well. what virt-manager version do you have?
12:03:22 <crobinso> atodorov: but yes, please add it and continue with the test. should be able to do 'add hardware'->channel->select the org.qemu name and it should set up the correct default
12:03:40 <crobinso> tjanez: thanks for filing that
12:03:54 <atodorov> crobinso: I'm using virt-manager-0.10.0-4.git79196cdf.fc20.noarch
12:04:05 <atodorov> I will file a bug for the missing hardware then
12:04:28 <crobinso> atodorov: did you definitely specify fedora20 for your VM OS? (in the 'new vm' wizard)
12:04:53 <crobinso> atodorov: or fpaste your ~/.cache/virt-manager.log and I can confirm
12:04:59 <atodorov> I was using URL to install from and I think it was correctly recognized as such
12:05:24 <crobinso> atodorov: hmm, okay, please file a bug and attach your virt-manager.log
12:06:49 <atodorov> crobinso: ok
12:24:16 <crobinso> eblake: mornin
12:24:23 <eblake> hello!
12:24:48 <eblake> which is better? run tests under F19 + fedora-virt-preview, or upgrade my bare-metal machine to full F20?
12:25:51 <atodorov> mrezanina: ping, how long did you have to wait for the arm guest to start ? nothing happens for me, just black screen. Also did you use the +lpae kernel/initrd or not ?
12:28:20 <tjanez> eblake: If you'll do a fresh install, atodorov suggested using Beta TC2
12:28:30 <tjanez> eblake: I don't know about the upgrade
12:29:01 <atodorov> crobinso: ^^^^, I've followed the ARM test case instructions but nothing happens and I'm kind of lost here
12:29:19 <eblake> tjanez: I'd rather do a fedup or yum upgrade to my F19 partition; but it is a quad boot machine, so I guess I could wipe my existing rawhide partition (which hasn't booted lately anyways) and replace it with a fresh TC2 install
12:30:03 <crobinso> eblake: I updated to f20 and it's been pretty smooth so far
12:30:40 <crobinso> atodorov: don't use lpae kernel, it didn't work for me :/
12:30:42 <eblake> crobinso: with fedup, or just yum?
12:30:47 <crobinso> eblake: yum
12:31:15 <atodorov> crobinso: ok, will try the other
12:31:19 <crobinso> atodorov: but you should start seeing output within 5 seconds, if not then it's configured wrong
12:31:49 <crobinso> atodorov: this stuff is pretty touchy, and the failure scenarios suck but qemu devs know about it's not a priority
12:32:04 <crobinso> *know about it and it is not a priority
12:35:17 <tjanez_> I abandoned the 'Guest install via URL' test case due to mirror problems for F20 Alpha
12:35:57 <tjanez_> Now I tried to use the Beta TC2 I downloaded and I'm stuck with the following virt-manager error: http://ur1.ca/fuv68
12:37:12 <tjanez_> the permissions of the ISO image are the following: -rw-rw-r--. qemu  qemu  system_u:object_r:virt_content_t:s0 Fedora-Live-Desktop-x86_64-20-Beta-TC2.iso
12:38:11 <atodorov> crobinso: non pae kernel+initrd moved past the boot point, but now I'm stuck with growroot Fatal: Failed to re-mount /dev/vda3, this is bad
12:39:01 <atodorov> oops, priot to that it says: mount: special device /dev/vda3 does not exist and priot to that it shows sfdisk -d which clearly shows vda1, 2, 3 and 4
12:39:31 <crobinso> atodorov: can you show the guest XML ?
12:41:04 <crobinso> tjanez_: hmm, did virt-manager ask you anything about changing your home directory permissions ?
12:41:51 <atodorov> crobinso: http://www.fpaste.org/45073/
12:42:00 <tjanez_> crobinso: No. I've given the output of
12:42:23 <tjanez_> crobinso: 'ls -alZ' and it looks ok to me
12:43:24 <crobinso> tjanez_: it's more subtle then that: the qemu user need search permissions all the way down to the iso file. can you file a virt-manager bug and attach ~/.cache/virt-manager/virt-manager.log, and that error message
12:44:01 <crobinso> tjanez_: the workaround is move the iso to /var/lib/libvirt/images, restart virt-manager, and continue. that directory already has the correct permissions and labeling
12:44:12 <crobinso> tjanez_: so maybe kick off the install, _then_ file the bug :)
12:44:26 <tjanez_> crobinso: Ok, thanks, will do that :)
12:45:22 <atodorov> tjanez_: just setenforce 0 if you have your files in non standard location
12:46:08 <tjanez_> atodorov: well, I could do that, but wouldn't testing with SELinux enabled be of more value?
12:47:16 <crobinso> tjanez_: also in that bug report ls -ld $HOME and ls -ld $HOME/Downloads, and getfacl for each
12:47:22 <atodorov> tjanez_: yes, but that depends on where your focus is. right now I prefer giving virt-manager a spin without selinux getting in the way
12:48:28 <crobinso> tjanez_: I would be interested as well if setenforce 0 makes that case work, since that limits it
12:48:43 <crobinso> atodorov: I can't tell what the issue is from your XML, looks fine there :/
12:48:53 <crobinso> atodorov: this is using the beta images?
12:49:11 <atodorov> crobinso: yes, using Beta-TC2, arm with MATE desktop
12:49:17 <atodorov> should I try the minimal one
12:49:36 <tjanez_> atodorov: I don't have a special focus, I was just asking for your (and other developers') opinion :)
12:49:52 <atodorov> and can I use the same vmlinuz+initrd without extracting them again ?
12:50:14 <crobinso> atodorov: not sure
12:50:23 <atodorov> crobinso: ok, will try
12:50:28 <crobinso> atodorov: I'll try and reproduce with the beta images, I only tried alpha and minimal myself
12:50:51 <atodorov> crobinso: btw I think I know the answer to my earlier question about the a9, a15  dtb images
12:50:56 <crobinso> tjanez_: I run with setenforce 0 but I watch for selinux errors reported by sealert
12:51:26 <atodorov> together with cpu arch == arm you have to select the CPU type in virt-manager and this is where these variants come into play
12:52:23 <crobinso> atodorov: right I know they largely map to different boards/machine types. but there's like 3 vexpress-a9 dtb and I don't know the difference between those :)
12:54:25 <tjanez_> atodorov, crobinso: I just did 'sudo setenforce 0' and re-clicked the 'Finish' button on Step 5 of 5, but it still returns the same error
12:54:45 <crobinso> tjanez_: okay, please include that info in the eventual bug report
12:55:25 <tjanez_> crobinso: Ok, will do. I'll move the image to /var/lib/libvirt/images now...
13:05:13 <kashyap> eblake, Yes, I can attest to it too, F20 update went just fine:    yum update yum; yum clean all;  yum --releasever=20 distro-sync --nogpgcheck -y
13:13:25 <crobinso> atodorov: downloading the beta image now, so i'll try to confirm in a bit.
13:15:00 <atodorov> crobinso: tested with the TC2 minimal image, same isssue. filing a bug right now
13:15:36 <crobinso> atodorov: sounds good, please include guest XML, and /var/log/libvirt/qemu/$vmname.log
13:22:05 <atodorov> crobinso: 1016648
13:42:13 <roshi> crobinso: how's the test day going so far?
13:43:27 <crobinso> roshi: we've generated a lot of bug reports. so, successful :)
13:44:43 <roshi> good to hear!
13:49:32 <atodorov> roshi: 8 bugs from me :)
13:49:38 <atodorov> 2 for anaconda though
13:49:49 <roshi> awesome atodorov
13:49:52 <roshi> good work
13:50:17 * roshi just woke up
14:10:59 <crobinso> atodorov: hmm, qemu-system-arm crashes for me with the the beta :/ but I don't think I'm running the latest qemu build
14:11:00 <dustymabe> hey guys does anyone get random guests that are left around after creating a guest?
14:11:05 <dustymabe> 25    guestfs-f8z0ja20o9ys8zs8       paused
14:11:43 <atodorov> dustymabe: where do you see this ?
14:11:46 <crobinso> dustymabe: those are libguestfs temporary guests... though they shouldn't be paused I don't think.
14:12:16 <atodorov> crobinso: I had seen the VM guest and sometimes anaconda not shutdown gracefully but I'm not able to reproduce consistently
14:12:19 <atodorov> can this be related
14:12:25 <dustymabe> basically after I do an install
14:12:34 <dustymabe> I'll work on getting a solid reproducer
14:12:56 <atodorov> dustymabe: that could be a the anaconda issue I'm talking about ^^^
14:13:40 <crobinso> dustymabe: ah, I bet it's due to your usage of nested virt. if the guest hits a kvm error, it can go into the paused state. libguestfs launches with some equivalent of -cpu host which might be triggering kvm issues due to all the nesting
14:14:52 <dustymabe> ok.. anything you want me to do to investigate?
14:15:28 <crobinso> dustymabe: I pinged rjones, if he's around he might have ideas. /var/log/libvirt/vmname/guestfs-f8z0ja20o9ys8zs8.log might give a hint
14:16:22 <atodorov> crobinso: a question about Pause/Resume UX - I don't see the guest console becoming gray or looking like it is disabled, should it hint the user visually as to what is the current state ?
14:18:50 <rwmjones> dustymabe: did you run libguestfs-test-tool?  can you paste the complete output somewhere
14:18:56 <crobinso> atodorov: we used to do that a long time ago, but dropped it because it was a pain to get right with the console scaling. it's a reasonable idea but I don't see it being implemented anytime soon :)
14:19:47 <dustymabe> rwmjones: no I have just been using virt-install
14:19:58 <atodorov> crobinso: I will update the test case then to indicate the UI is not updated
14:20:10 <dustymabe> rwmjones: the log did show me an error: KVM: entry failed, hardware error 0x7
14:20:39 <dustymabe> rwmjones: I am using host passthrough with nested virt so maybe that is why it is having trouble
14:20:39 <rwmjones> dustymabe: this was a libguestfs problem or a libvirt problem?  I didn't see previous discussion
14:21:12 <dustymabe> rwmjones: I just notice on my system that I have a random guest that hangs around: 25    guestfs-f8z0ja20o9ys8zs8       paused
14:21:41 <dustymabe> rwmjones: this is after running a couple of virt-install tests.. nothing special
14:22:06 <rwmjones> hmm strange, are you running virt-manager?
14:22:48 <dustymabe> i have ran virt-manager but only to view console of the guests.. to create the guests I have been using virt-install
14:23:22 <dustymabe> Would you like for me to send you a link to the full output in the log?
14:23:24 <rwmjones> don't know, but you can virsh destroy that guest .. it shouldn't be there and it should be in paused state
14:24:11 <rwmjones> s/should be/should NOT be/
14:24:37 <dustymabe> here is a link to the log file: http://pastebin.com/xgU6WgB2
14:25:18 <rwmjones> looks badly broken; could be nested KVM or something else KVM-related
14:26:07 <dustymabe> ok.. I'll keep it in mind and continue testing
14:26:58 <dustymabe> i do have one other nested virt question.. has anyone else seen NMI's in L2 guest? Similar to this: https://bugzilla.kernel.org/show_bug.cgi?id=58941
14:27:50 <dustymabe> The guest continues to run fine but the messages get printed to console periodically
14:47:07 <dustymabe> is it still valid to create a guest with --graphics none and expect to see anaconda install on the serial console?
14:47:17 <crobinso> dustymabe: haven't heard of that NMI issue, but not surprising :) nested vmx is finicky
14:48:29 <crobinso> dustymabe: did anaconda ever do it automatically? I though passing in a kickstart, or at least 'console=ttyS0' was required
14:48:39 <crobinso> to get the non-graphical install
14:49:50 <crobinso> but if you're doing --os-variant fedora20 you'd likely need to tell it 'console=hvc0' since that's the virtio console inside the guest, but I haven't confirmed that actually works
14:50:13 <dustymabe> If i recall correctly, at least in RHEL6 if you passed in --nographics it would default to connect you to the serial console where you could receive messages from ttyS0
14:50:21 <dustymabe> and I passed in console=ttyS0
14:50:23 <dustymabe> ahh got it
14:50:29 <dustymabe> so it is not ttyS0 anymore?
14:50:58 <dustymabe> i'll try with console=hvc0
14:55:48 <dustymabe> crobinso: bingo.. i'm now getting messages on the serial console
14:56:04 <atodorov> crobinso, dustymabe: https://bugzilla.redhat.com/show_bug.cgi?id=1016715 , FYI. I filed the poweroff hang issue which unfortunately is not easy to reproduce :(
14:56:16 <atodorov> if you see it again please add more info to this bug
14:56:31 <atodorov> I have to go now. enough testing for me today
14:56:45 <crobinso> atodorov: thanks for all the help!
14:56:55 <dustymabe> atodorov: were you using nested virt?
14:57:36 <atodorov> dustymabe: nope, just bare metal F20
14:58:05 <dustymabe> atodorov: thanks.. just trying to narrow down if nested virt was the reason for what I saw or not. If i see it again I'll try to narrow it down
14:58:23 <crobinso> dustymabe: yeah I changed the default for f20 to virtio console, but I was afraid it would causes issues like that.
14:59:20 <crobinso> dustymabe: virtio console is nice because after install, systemd knows to start a getty on it, so you can do: virsh start --console $vmname and get a login prompt with zero extra config
14:59:48 <crobinso> dustymabe: but for people doing headless installs it means passing different kernel args...
14:59:49 <dustymabe> crobinso: with "--graphics none" could virt-install append console=<appropriate console> to the kernel command line?
15:01:24 <dustymabe> crobinso: I think systemd will do that for any serial console that is provided to the kernel command line (not just hvc0)
15:01:51 <crobinso> dustymabe: yeah we could add console automatically, or warn if it's likely not going to work
15:02:26 <crobinso> dustymabe: right systemd does that automatically if the grub kernel command line is altered. but the nice thing about hvc0 is that systemd does it _regardless_ of the kernel command line, so zero extra config is needed
15:02:50 <dustymabe> crobinso: got it
15:03:28 <dustymabe> crobinso: how do you track feature requests such as the one mentioned above?
15:04:04 <crobinso> dustymabe: just file a fedora virt-manager bug and I'll move it around if necc.
15:05:15 <dustymabe> crobinso: got it.. this will help lessen your worries about switching the default console (at least for initial install)
15:06:15 <dustymabe> ok.. next on the list
15:06:45 <dustymabe> i created a guest without graphics.. and then later attempted to add spice graphics to the VM using virt-manager
15:07:20 <dustymabe> I get the following error:
15:07:36 <dustymabe> details=Error adding device: XML error: Attempted double use of PCI slot 0000:00:02.0 (may need "multifunction='on'" for device on function 0)
15:08:07 <dustymabe> this is because the network card was already using that pci slot
15:09:08 <crobinso> dustymabe: hmm, can you pastebin ~/.cache/virt-manager/virt-manager.log ?
15:09:41 <crobinso> dustymabe: and the full guest XML
15:10:44 <dustymabe> crobinso: yes. let me truncate the log and recreate real quick so there are only messages we care about
15:10:54 <crobinso> thanks
15:17:34 <dustymabe> crobinso: Here is log: http://pastebin.com/zjNd2FUq
15:19:29 <dustymabe> crobinso: Here is the guest xml http://pastebin.com/jSbfs7f7
15:19:30 <crobinso> dustymabe: I'll check it in a bit, I'm on a phone call now. did you work around the issue in the meantime?
15:20:00 <dustymabe> crobinso: yep.. i just wanted to bring it up
15:20:34 <crobinso> dustymabe: sounds good. please file virt-manager bug about that and I'll follow up there
15:21:32 <dustymabe> ok
15:25:30 <dustymabe> tjanez_: are you still around? I am also having issues with installing via a URL.. Is anyone else?
15:25:33 <dustymabe> Warning: Downloading 'http://download.fedoraproject.org/pub/fedora/linux/development/20/x86_64/os//images/product.img' failed!
15:26:33 <crobinso> dustymabe: yeah mirror manager is messed up, replace download.fedoraproject.org with dl.fedoraproject.org and it should work
15:27:35 <crobinso> download.fedoraproject.org will automagically choose a mirror, but some of the mirrors are incomplete so bits will fail. dl.fedoraproject.org is the master fedora mirror
15:27:45 <dustymabe> ok thanks
15:48:47 <tjanez_> dustymabe: As crobinso pointed out, the state of development mirrors (or F20 Alpha mirrors) is quite bad. Anaconda even crashed on me during install due to a missing rpm.
15:48:59 <tjanez_> dustymabe: I just downloaded an ISO and used that.
15:49:49 <dustymabe> tjanez_: thanks.. i am using dl.fedoraproject.org now.. seems better
15:50:13 <tjanez_> crobinso: I'll have to leave now, is it still valuable to perform more test cases later or tomorrow?
16:03:34 <crobinso> tjanez_: yes please, any time this week is fine really
16:03:40 <crobinso> tjanez_: thanks for the help :)
16:04:49 <tjanez_> crobinso: No problem, I was glad to help out :) Will do some more tests later.
16:19:14 <crobinso> dustymabe: file those bugs yet? I've got some info to dump :)
16:20:33 <dustymabe> crobinso: not yet will do that now.. somehow my whole system went down at the end of an network install.. i couldn't switch to a different vty or anything
16:20:46 <dustymabe> working on the bug reports now
16:20:56 <dustymabe> i'll file the virt-manager one first
16:21:22 <crobinso> ugh, system crash. no good.
16:35:03 <dustymabe> crobinso: https://bugzilla.redhat.com/show_bug.cgi?id=1016775
16:38:51 <kashyap> dustymabe, I was just reading some scroll, if you're using nested virt (kvm on kvm), please ensure you're having versions:
16:38:52 <kashyap> 3.12.0-0.rc3.git1.2.fc21.x86_64
16:38:53 <kashyap> qemu-kvm-1.4.2-7.fc19.x86_64
16:38:53 <kashyap> libvirt-daemon-kvm-1.0.5.5-1.fc19.x86_64
16:39:00 <kashyap> (Or higher)
16:39:57 <crobinso> kashyap: does yum --enablerepo=rawhide update kernel 'just work' or does it want to pull in the world ?
16:39:58 <kashyap> Here is the link for No debug (i.e. slightly faster) Rawhide kernels -- http://fedoraproject.org/wiki/RawhideKernelNodebug
16:40:37 <kashyap> crobinso, Good question, it should be fedora-rawhide (exact repo name), no?
16:40:43 <kashyap> Btw, good morning!
16:41:40 <crobinso> kashyap: good evening to you :)
16:41:41 <kashyap> crobinso, Ok, that doesn't work :-)
16:41:48 <dustymabe> kashyap: thanks for the info. my kernel is older (from F19)
16:41:48 <kashyap> I just use the nodebug kernels
16:42:01 <kashyap> crobinso, Rawhide kernels have debug enabled.
16:42:35 <kashyap> crobinso, Yeah, I'm about to wind up and take a walk :-)
16:46:27 <dustymabe> cronbinso: should i put the bug i filed on the test day page somewhere? where should it go?
16:46:49 <dustymabe> oops.. crobinso
16:47:09 <crobinso> dustymabe: sure, just add a line under the 'known bugs' section
16:47:15 <crobinso> dustymabe: auto complete is your friend :)
16:47:31 <kashyap> 'cron'binso - :-)
16:48:20 <kashyap> dustymabe, And, yes (to your previous question) - NMIs in L2 is not uncommon.  (One of the KVM unit tests specific to NMI was failing, there was a discussion upstream for a fix, I think it should be fixed if you're trying kvm.git next.)
16:48:58 <crobinso> kashyap: so is 3.11 much better than 3.10 for nested vmx?
16:49:33 <kashyap> crobinso, Certainly. Even with 3.13.0, I had some host crashes, debugging w/ Paolo/gleb.
16:50:01 <kashyap> So, I was just installing kernels from kvm.git queue.
16:51:08 <kashyap> crobinso, Side note: With nested EPT (EPT enabled on both L0 & L1), you see 10x perf improvement compared to shadow on shadow (EPT disabled on both L0 & L1)
16:52:00 <kashyap> crobinso, By 10x, a simple example:  with nEPT -- Kernel compile in L2 takes 5 minutes; with shadow-on-shadow, same Kernel compile on L2 takes 50 minutes.
16:52:36 <crobinso> nice
16:53:06 <kashyap> defconfig that is. Standard distro bloat Kernel takes more time, as it enables every darn thing :)
16:54:03 <kashyap> Anyway, stepping out for now. See ya. Will read scroll later.
16:54:19 <dustymabe> kashyap: thanks for the info :)
17:10:24 <dustymabe> Is it possible in virt-install to append kernel args to an install based off a cd?
17:10:56 <dustymabe> if you specify a url location then virt-install will detect kernel, initrd, etc.. and then feed that info to the qemu command
17:11:30 <dustymabe> if you do a cd it doesn't so there is no kernel option in the qemu command and thus the qemu command will reject any --append statements
17:11:32 <crobinso> dustymabe: nope, there's no easy way to get the kernel args to the kernel that's booted from the iso
17:12:38 <crobinso> dustymabe: it's kind of crazy, but what you can do is use virt-manager on the host machine to connect over ssh to libvirt inside the VM, then kick off a graphical install
17:13:17 <dustymabe> crobinso: yep and add your kernel command line options there
17:13:38 <crobinso> dustymabe: I though virt-install gave a warning that --kernel-args won't work for CDROM boot... did it not?
17:14:52 <dustymabe> crobinso: I don't think so.. or at least I did not notice until qemu cursed at me
17:15:17 <dustymabe> crobinso: FYI I was using --location /dev/sr0 and --extra-args for the kernel args
17:15:46 <crobinso> dustymabe: well if qemu gives an explicit error that's good enough for me
17:17:09 <dustymabe> crobinso: it wasn't immediately obvious but I did figure it out. wasn't immediately obvious because I didn't know that for the web install it was passing kernel and for the other one it wasn't
17:17:17 <dustymabe> crobinso: i figured it out though and it makes sense now
17:17:51 <crobinso> dustymabe: yeah, using --location with a cdrom kind of works and kind of doesn't, I should clarify it one of these days
17:18:12 <dustymabe> crobinso: would it make sense to do the same "detection" for cd/iso installs filtered through the --location argument as is done for URL installs?
17:18:55 <crobinso> dustymabe: I would like to, but it's not as easy :) libosinfo will help with that but we need to port to it
17:20:30 <dustymabe> crobinso: got it.. im sure you've wanted to append kernel args to cd installs too for a while
17:21:06 <dustymabe> crobinso: in an automated fashion that is
19:51:04 <atodorov> hi guys, if anyone is interested, here's my test day post mortem review - http://atodorov.org/blog/2013/10/08/fedora-20-virtualization-test-day-post-mortem/
19:53:32 <crobinso> atodorov: great, thanks
19:57:49 <dustymabe> atodorov: was it you that opened the bug about anaconda not restarting cleanly at the end of install?
19:59:00 <atodorov> dustymabe: yes, one sec
19:59:21 <atodorov> https://bugzilla.redhat.com/buglist.cgi?bug_id=1016435%2C1016449%2C1016488%2C1016530%2C1016604%2C1016613%2C1016648%2C1016663%2C1016704%2C1016715&list_id=1785007
19:59:47 <atodorov> here's all my bugs for today, the one you are asking about is https://bugzilla.redhat.com/show_bug.cgi?id=1016715
20:01:45 <dustymabe> atodorov: thanks
20:20:26 <dustymabe> ok guys im heading out.
20:20:42 <dustymabe> crobinso: on our discussion earlier about injecting kernel args for cd install
20:21:18 <dustymabe> crobinso: I think we can get what we want by mounting the iso/cd and then pointing --location to the directory
20:21:39 <dustymabe> crobinso: then kernel args work
21:08:57 <crobinso> dustymabe: yeah, the only problem with that is then getting the install media into the guest, but you could export the mount point over http
21:46:46 <dustymabe> crobinso: you know i was just brainstorming this
21:47:51 <dustymabe> would be cool if we could share the directory to the guest using http://www.linux-kvm.org/page/9p_virtio
21:48:25 <dustymabe> although i'm sure that would be a nightmare for situations where the guest is remote from the system you are running virt-install on
21:49:06 <crobinso> dustymabe: yeah that is definitely an option, but only for sufficiently new guests. it's also not perfect: need to be root to mount an iso, and many isos are live media which aren't typical install trees, etc.
21:51:37 <dustymabe> crobinso: didn't think about the "root" part
00:55:16 <crobinso> #endmeeting