Bug 837925
| Summary: | Fedora 16 and 17 guests hang during boot | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jason Brooks <jbrooks> | ||||||||
| Component: | qemu | Assignee: | Fedora Virtualization Maintainers <virt-maint> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | urgent | Docs Contact: | |||||||||
| Priority: | urgent | ||||||||||
| Version: | 17 | CC: | abaron, acathrow, amit.shah, bazulay, berrange, cfergeau, crobinso, dougsland, dwmw2, dyasny, herrold, iheim, itamar, knoel, mgoldboi, oschreib, pbonzini, rjones, scottt.tw, virt-maint, xuhj | ||||||||
| Target Milestone: | --- | Keywords: | Regression | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | |||||||||||
| : | 839156 (view as bug list) | Environment: | |||||||||
| Last Closed: | 2012-07-28 01:22:07 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 822145 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Jason Brooks
2012-07-05 20:18:40 UTC
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. |