Description of problem: I just got virtualization configured in my rawhide boot partition and attempted to run some virtual machines I created in fedora 11, and got an assortment of miserable failures. I've got a raw file image with an ubuntu 9.10 machine: [root@zooty images]# pwd /var/lib/libvirt/images [root@zooty images]# qemu-img info ubu.img image: ubu.img file format: raw virtual size: 20G (21474836480 bytes) disk size: 3.2G When I do a virsh define and import the xml def dumped on fedora 11 and start the machine, it boots partway up, then I see this in /var/log/messages: Sep 20 15:59:18 zooty kernel: tun: Universal TUN/TAP device driver, 1.6 Sep 20 15:59:18 zooty kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk> Sep 20 15:59:18 zooty kernel: device vnet0 entered promiscuous mode Sep 20 15:59:18 zooty kernel: br0: port 2(vnet0) entering learning state Sep 20 15:59:18 zooty kernel: BUG: MAX_LOCK_DEPTH too low! Sep 20 15:59:18 zooty kernel: turning off the locking correctness validator. Sep 20 15:59:18 zooty kernel: Pid: 3622, comm: qemu-kvm Tainted: G W 2.6.31-33.fc12.x86_64 #1 Sep 20 15:59:18 zooty kernel: Call Trace: Sep 20 15:59:18 zooty kernel: [<ffffffff8109799b>] __lock_acquire+0xb84/0xc0e Sep 20 15:59:18 zooty kernel: [<ffffffff81097b13>] lock_acquire+0xee/0x12e Sep 20 15:59:18 zooty kernel: [<ffffffff8111a5f7>] ? mm_take_all_locks+0xf7/0x141 Sep 20 15:59:18 zooty kernel: [<ffffffff8111a5f7>] ? mm_take_all_locks+0xf7/0x141 Sep 20 15:59:18 zooty kernel: [<ffffffff8111a5f7>] ? mm_take_all_locks+0xf7/0x141 Sep 20 15:59:18 zooty kernel: [<ffffffff815067ee>] _spin_lock_nest_lock+0x45/0x8e Sep 20 15:59:18 zooty kernel: [<ffffffff8111a5f7>] ? mm_take_all_locks+0xf7/0x141 Sep 20 15:59:18 zooty kernel: [<ffffffff81505063>] ? mutex_lock_nested+0x4f/0x6b Sep 20 15:59:18 zooty kernel: [<ffffffff8111a5f7>] mm_take_all_locks+0xf7/0x141 Sep 20 15:59:18 zooty kernel: [<ffffffff811305a8>] ? do_mmu_notifier_register+0xb4/0x192 Sep 20 15:59:18 zooty kernel: [<ffffffff811305b0>] do_mmu_notifier_register+0xbc/0x192 Sep 20 15:59:18 zooty kernel: [<ffffffff811306e5>] mmu_notifier_register+0x26/0x3d Sep 20 15:59:18 zooty kernel: [<ffffffffa02a9eeb>] kvm_dev_ioctl+0x14a/0x2f7 [kvm] Sep 20 15:59:18 zooty kernel: [<ffffffff81151cdf>] vfs_ioctl+0x31/0xaa Sep 20 15:59:18 zooty kernel: [<ffffffff811522a1>] do_vfs_ioctl+0x4aa/0x506 Sep 20 15:59:18 zooty kernel: [<ffffffff81085fbb>] ? up_read+0x3a/0x55 Sep 20 15:59:18 zooty kernel: [<ffffffff81011f7a>] ? sysret_check+0x2e/0x69 Sep 20 15:59:18 zooty kernel: [<ffffffff81152362>] sys_ioctl+0x65/0x9c Sep 20 15:59:18 zooty kernel: [<ffffffff81011f42>] system_call_fastpath+0x16/0x1b I then tried a Windows XP machines which is setup as a qcow2 image based on another qcow2 image: [root@zooty images]# qemu-img info winxppro.img image: winxppro.img file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 48M cluster_size: 4096 backing file: winxpsp3-acpi-base.img (actual path: winxpsp3-acpi-base.img) [root@zooty images]# qemu-img info winxpsp3-acpi-base.img image: winxpsp3-acpi-base.img file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 5.4G cluster_size: 4096 It won't even start booting, it just says: qemu: could not open disk image /var/lib/libvirt/images/winxppro.img Version-Release number of selected component (if applicable): qemu-img-0.10.92-4.fc12.x86_64 qemu-system-x86-0.10.92-4.fc12.x86_64 qemu-common-0.10.92-4.fc12.x86_64 qemu-kvm-0.10.92-4.fc12.x86_64 gpxe-roms-qemu-0.9.7-5.fc12.noarch How reproducible: Same results every time. Steps to Reproduce: 1.see above 2. 3. Actual results: abject failure Expected results: being able to run virtual machines across an upgrade. Additional info:
(In reply to comment #0) > Sep 20 15:59:18 zooty kernel: BUG: MAX_LOCK_DEPTH too low! Nothing to be concerned about, see bug #507500 (In reply to comment #0) > I then tried a Windows XP machines which is setup as a qcow2 image > based on another qcow2 image: > > [root@zooty images]# qemu-img info winxppro.img > image: winxppro.img > file format: qcow2 > virtual size: 20G (21474836480 bytes) > disk size: 48M > cluster_size: 4096 > backing file: winxpsp3-acpi-base.img (actual path: winxpsp3-acpi-base.img) > [root@zooty images]# qemu-img info winxpsp3-acpi-base.img > image: winxpsp3-acpi-base.img > file format: qcow2 > virtual size: 20G (21474836480 bytes) > disk size: 5.4G > cluster_size: 4096 See bug #497131 about an svirt bug with using qcow2 copy-on-write files > > It won't even start booting, it just says: > > qemu: could not open disk image /var/lib/libvirt/images/winxppro.img qemu now runs as the qemu user now Try chmod o+x /var/lib/libvirt/images ?
OK, changing permissions works for the Windows XP image. Thanks! I assume the ubuntu problem won't be fixed till a kernel update shows up.
Actually my ubuntu problem was a different permission problem: Due to bug 524732 I was running virt-manager as root, and apparently the VM hung up trying to initialize the audio device because qemu couldn't connect to pulseaudio running as the wrong user with wrong home directory for current pulse daemon. Hanging forever seems pretty draconian - maybe just making it look like the sound hardware is busted and continuing would be better behavior? The ubuntu machine boots fine once I remove the sound hardware.
(In reply to comment #3) > I was running virt-manager as root, and apparently the VM hung up trying to > initialize the audio device because qemu couldn't connect to pulseaudio > running as the wrong user with wrong home directory for current pulse daemon. Could you confirm that that you had SELinux disabled when doing this? We do not enable audio devices when SELinux is enabled (see bug #508317) However, now that we are running qemu as an unprivileged user, we should never enable the pulseaudio/SDL backend It just so happens that danpb pushed a change upstream to do this recently: http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=b08e6d38ae I've just pulled this into F-12: * Thu Oct 1 2009 Mark McLoughlin <markmc> - 0.7.1-8 - Disable sound backend, even when selinux is disabled (#524499) I'll build it later on today
Yes, selinux is definitely disabled, both in /etc/selinux/config and with selinux=0 in grub.conf (belt and suspenders :-).
This is in rawhide now