Description of problem: On oVirt 3.1, Fedora 16 and Fedora 17 guests hang during boot. F16 guests will install normally from the DVD iso, and then hang on first boot. F17 guests hang when booting from the DVD iso. I booted up my F16 VM in rescue mode, and started each of the services wanted by the default runlevel individually. It was getty.target that appears to be causing the hangup. All the other services start without an issue, but right after "systemctl start getty.target" the system cpu % grows quickly to 99% and the VM won't respond. Version-Release number of selected component (if applicable): 4.10.0-4.fc17 I chose vdsm as the affected component because a user on the list mentioned a similar-sounding issue with F16 and F17 guests, manipulating vdsm directly: http://lists.ovirt.org/pipermail/users/2012-June/002555.html. How reproducible: Install an F16 guest on oVirt 3.1 and attempt to boot, or attempt to install an F17 guest from the DVD install image. Steps to Reproduce: 1. 2. 3. Actual results: Guest hangs during boot. Expected results: Guest boots normally. Additional info:
does it reproduce with virt-manager?
(In reply to comment #1) > does it reproduce with virt-manager? I just tried this -- I connected to my node with virt-manager running on a separate machine, using the vdsm@rhev credentials. The F17 DVD image booted normally. From oVirt, booting from the same F17 DVD iso results in a hang.
Can we get the logs from VDSM when the VM is started
Created attachment 596917 [details] vdsm log from F17 VM
Created attachment 596918 [details] domain xml Attaching extracted domain xml from vdsm log. We need to try and reproduce using this xml to see what breaks,
jason - was the virt-manager try similar to vdsm configuration (spicevmc, usb, cpus, virtio devices, etc.)?
Created attachment 596986 [details] vm definition from virt-manager test
which version of qemu did you used? I can reproduce qemu(version < 1.1) will hangs when guest os connect the virtio console. vdsm will add this to vm: <console type='pty'> <target type='virtio' port='0'/> </console> if host didn't open this pty, when guest execute 'getty' on this console, guest will hangs I think it's a qemu bug, and it has already fix in qemu. You can try to upgrade your qemu to 1.1.0.
(In reply to comment #8) > which version of qemu did you used? I was using the current qemu from F17, which is 1.0.17. > > I think it's a qemu bug, and it has already fix in qemu. You can try to > upgrade your qemu to 1.1.0. I built qemu-1.1.0-4.fc18.src.rpm for F17 and used it to update the qemu pkgs on my node, and F17 booted from the install DVD as expected. So, yay! I'll test now with F16, too.
(In reply to comment #9) > I'll test now with F16, too. With the qemu 1.1 packages, F16 works, as well.
systemd creates a getty on serial ports available, and the virtio-console port is one of them. If there's no listener connected for that port on the host, the output from the guest is throttled till a listener is connected. This is desirable for virtio-serial ports, but not for console ports, whose output should be discarded in such cases. With the current guest code, the guest just keeps spinning in a while() loop till it hears back from the host after writing data on a console port. In this case, since there's no listener connected, the guest never hears back, and just keeps spinning. Fix is to simply not throttle console ports, and discard the data if no listener is connected. This is done in qemu upstream commit ed8e5a85a1741147ce06932b478a509ce3407061. This affects only in the case where the console chardev is of type 'pty'. 'unix' and 'tcp' chardevs will just throttle with current code. With the fix mentioned above, however, the default behaviour for 'unix' and 'tcp' chardevs will change as well to not throttle if the port is a console port.
Could you backport this fix to Fedora 17, so oVirt-3.1 can enjoy it?
(In reply to comment #12) > Could you backport this fix to Fedora 17, so oVirt-3.1 can enjoy it? Sure, please clone it for F16 (or re-assign), and the maintainer will take care of it.
(In reply to comment #13) > (In reply to comment #12) > > Could you backport this fix to Fedora 17, so oVirt-3.1 can enjoy it? > > Sure, please clone it for F16 (or re-assign), and the maintainer will take > care of it. If fixed in qemu, there's nothing to do in Vdsm. Moving.
Any update on this? it currently blocks oVirt 3.1 release.
I'll do a build for this today
qemu-1.0-18.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/qemu-1.0-18.fc17
Package qemu-1.0-18.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qemu-1.0-18.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10744/qemu-1.0-18.fc17 then log in and leave karma (feedback).
qemu-0.15.1-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/qemu-0.15.1-6.fc16
qemu-1.0-18.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
qemu-0.15.1-6.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.