This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 573427 - qemu-0.12.3 won't start VMs
qemu-0.12.3 won't start VMs
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Justin M. Forbes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-14 15:54 EDT by James Ralston
Modified: 2013-01-09 06:32 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-03 12:22:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
XML definition file for VM that 0.12.3-1 won't start (1.16 KB, application/xml)
2010-03-14 15:56 EDT, James Ralston
no flags Details
XML definition file for VM that 0.12.3-1 won't start (1.16 KB, text/plain)
2010-03-14 15:57 EDT, James Ralston
no flags Details

  None (edit)
Description James Ralston 2010-03-14 15:54:36 EDT
I updated to these packages from updates-testing:

qemu-common-0.12.3-1.fc12.x86_64
qemu-img-0.12.3-1.fc12.x86_64
qemu-kvm-0.12.3-1.fc12.x86_64
qemu-system-x86-0.12.3-1.fc12.x86_64

Now, I cannot start my VMs from virsh:

virsh # start dragonslicer
error: Failed to start domain dragonslicer
error: monitor socket did not show up.: Connection refused

When I revert back to qemu-0.11.0-13, I can start my VMs again.
Comment 1 James Ralston 2010-03-14 15:56:57 EDT
Created attachment 400032 [details]
XML definition file for VM that 0.12.3-1 won't start
Comment 2 James Ralston 2010-03-14 15:57:59 EDT
Created attachment 400033 [details]
XML definition file for VM that 0.12.3-1 won't start
Comment 3 James Ralston 2010-03-14 16:05:01 EDT
From /var/log/libvirt/qemu/dragonslicer.log

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-0.11 -m 512 -mem-path /dev/hugepages/libvirt/qemu -smp 1 -name dragonslicer -uuid 3cfca5cf-bd01-640f-db3c-c703f6ef62e1 -monitor unix:/var/lib/libvirt/qemu/dragonslicer.monitor,server,nowait -localtime -no-acpi -boot c -drive file=/dev/os/dragonslicer,if=virtio,index=0,boot=on -drive file=,if=ide,media=cdrom,index=2 -net nic,macaddr=00:16:3e:7e:c8:3e,vlan=0,model=virtio,name=virtio.0 -net tap,fd=17,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -k en-us -vga cirrus 
qemu: could not open disk image : No such file or directory

I then reverted back to qemu-0.11.0-13:

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-0.11 -m 512 -mem-path /dev/hugepages/libvirt/qemu -smp 1 -name dragonslicer -uuid 3cfca5cf-bd01-640f-db3c-c703f6ef62e1 -monitor unix:/var/lib/libvirt/qemu/dragonslicer.monitor,server,nowait -localtime -no-acpi -boot c -drive file=/dev/os/dragonslicer,if=virtio,index=0,boot=on -drive file=,if=ide,media=cdrom,index=2 -net nic,macaddr=00:16:3e:7e:c8:3e,vlan=0,model=virtio,name=virtio.0 -net tap,fd=17,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -k en-us -vga cirrus 

So, it's the exact same command line, but 0.12.3-1 is bombing out...
Comment 4 James Ralston 2010-03-19 02:14:04 EDT
0.12.3-2.fc12 fails in exactly the same way.
Comment 5 Justin M. Forbes 2010-03-19 08:14:51 EDT
Is seabios installed on your host?  It is a dep for qemu, so it should have installed automatically.
Comment 6 James Ralston 2010-03-19 11:37:37 EDT
Yes; seabios-0.5.1-1.fc12 is installed:

$ repoquery --envra --pkgnarrow=installed 'qemu*' seabios
2:qemu-common-0.11.0-13.fc12.x86_64
2:qemu-img-0.11.0-13.fc12.x86_64
2:qemu-kvm-0.11.0-13.fc12.x86_64
2:qemu-system-x86-0.11.0-13.fc12.x86_64
0:seabios-0.5.1-1.fc12.x86_64
Comment 7 James Ralston 2010-03-21 05:26:25 EDT
If it helps any, here's an strace of what 0.12.3-2 does:

26833 stat("/dev/os/stonecutter", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 1), ...}) = 0
26833 open("/dev/os/stonecutter", O_RDWR|O_SYNC|O_CLOEXEC) = 8
26833 rt_sigprocmask(SIG_BLOCK, [USR2], NULL, 8) = 0
26833 signalfd(4294967295, [USR2], 8)   = 9
26833 fcntl(9, F_GETFD)                 = 0
26833 fcntl(9, F_SETFD, FD_CLOEXEC)     = 0
26833 fcntl(9, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
26833 lseek(8, 0, SEEK_END)             = 17179869184
26833 open("", O_RDONLY|O_NONBLOCK)     = -1 ENOENT (No such file or directory)
26833 stat("", 0x7fff98086d10)          = -1 ENOENT (No such file or directory)
26833 open("", O_RDONLY|O_SYNC|O_CLOEXEC) = -1 ENOENT (No such file or directory)
26833 write(2, "qemu: could not open disk image "..., 60) = 60
26833 exit_group(1)                     = ?

Contrast that with what 0.11.0-13 does:

27050 stat("/dev/os/stonecutter", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 1), ...}) = 0
27050 rt_sigprocmask(SIG_BLOCK, [USR2], NULL, 8) = 0
27050 signalfd(4294967295, [USR2], 8)   = 7
27050 fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
27050 open("/dev/os/stonecutter", O_RDWR|O_SYNC) = 8
27050 lseek(8, 0, SEEK_END)             = 17179869184
27050 rt_sigaction(SIGINT, {0x40a9e0, [], SA_RESTORER, 0x3098c0f0f0}, NULL, 8) = 0
27050 rt_sigaction(SIGHUP, {0x40a9e0, [], SA_RESTORER, 0x3098c0f0f0}, NULL, 8) = 0
27050 rt_sigaction(SIGTERM, {0x40a9e0, [], SA_RESTORER, 0x3098c0f0f0}, NULL, 8) = 0
27050 rt_sigaction(SIGCHLD, {0x409470, [], SA_RESTORER|SA_NOCLDSTOP, 0x3098c0f0f0}, NULL, 8) = 0
27050 socket(PF_FILE, SOCK_STREAM, 0)   = 9
27050 unlink("/var/lib/libvirt/qemu/stonecutter.monitor") = -1 ENOENT (No such file or directory)
27050 bind(9, {sa_family=AF_FILE, path="/var/lib/libvirt/qemu/stonecutter.monitor"}, 110) = 0
27050 listen(9, 1)                      = 0
27050 fcntl(9, F_GETFL)                 = 0x2 (flags O_RDWR)
27050 fcntl(9, F_SETFL, O_RDWR|O_NONBLOCK) = 0
27050 open("/dev/ptmx", O_RDWR)         = 10
27050 statfs("/dev/pts", {f_type="DEVPTS_SUPER_MAGIC", f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
27050 ioctl(10, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
27050 ioctl(10, TIOCGPTN, [3])          = 0
27050 stat("/dev/pts/3", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
27050 stat("/dev/pts/3", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
...
Comment 8 James Ralston 2010-03-31 13:20:57 EDT
I found the problem:

--- dragonslicer.xml    2010-03-31 12:33:25.518293599 -0400
+++ dragonslicer.xml.knowngood  2010-03-31 12:30:46.491302327 -0400
@@ -27,7 +27,9 @@
       <source dev='/dev/os/dragonslicer'/>
       <target dev='vda' bus='virtio'/>
     </disk>
-    <disk type='block' device='cdrom'>
+    <disk type='file' device='cdrom'>
+      <driver name='qemu'/>
+      <source file='/home/qralston/dban-1.0.7_i386.iso'/>
       <target dev='hdc' bus='ide'/>
       <readonly/>
     </disk>

I'm running kvm on my laptop. I usually have an extra battery in the bay slot, not my DVD-RW drive, so /dev/cdrom usually doesn't exist.

qemu-kvm-0.11 doesn't care that /dev/cdrom isn't actually present when I start a virtual guest configured to use it. But qemu-kvm-0.12 does.

I seem to recall reading a discussion about this very issue (what to do when a guest is configured to use block device that can disappear and reappear on the host). I'm not sure what the decision was--perhaps this new behavior in 0.12 represents the decision.

I still think there's a bug here, though: when /dev/cdrom wasn't present, kvm attempted to open the null string. I suspect that's why the error message didn't explicitly mention that it was /dev/cdrom that wasn't found.
Comment 9 Bug Zapper 2010-11-03 15:46:19 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bug Zapper 2010-12-03 12:22:17 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.