Bug 875700
| Summary: | Saving virtual host leads to "undefined error" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Albert Flügel <albert.fluegel> |
| Component: | qemu-kvm | Assignee: | Ademar Reis <areis> |
| Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.3 | CC: | acathrow, areis, bsarathy, dyasny, juzhang, mkenneth, virt-maint |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-11-15 14:40:33 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: | |||
| Attachments: | |||
Created attachment 643485 [details]
strace of libvirtd while trying to save the virtual host from virt-manager
Created attachment 643486 [details]
strace of libvirtd while trying to save the virtual host from virsh
Created attachment 643487 [details]
strace of virsh trying to save the virtual host3 with virsh managedsave host3
Created attachment 643488 [details]
error message of the virt-manager when trying to save host3
Created attachment 643489 [details]
strace of the virt-manager when trying to save host3
Thank you for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution. If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization to assure a timely resolution. For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto That said, would you be able to test your guest (or a likely scenario) on a 6.3 host fully updated? Frankly, i don't understand how you perceive this report being a request for support. Anyway. Yes i'm definitely planning to test on a RHE 6.3 as soon as i find the time and the yum update works. Currently we have some inconsistency in the repo what makes yum fail. During the last days unfortunately i did not find the time, but i'll do this. Just also for the simple reason, that it probably fixes this problem, that really hurts. The same thing happens on 6.3 with the latest patches from yesterday (Nov 13 2012) installed. (In reply to comment #8) > Frankly, i don't understand how you perceive this report being a request for > support. Anyway. > I just wanted to make it clear that bugzilla is a slow channel and our regular Red Hat support channels should be used in case this issue is critical or time-sensitive for you. Thanks for the tests on RHEL6.3. Looks like you've hit bug 805172 (see also bug 841629). Indeed your host3.xml configuration file has USB references, which prevent migration in RHEL6.3. This has been fixed in RHEL6.4, which now supports live-migration of guests with USB devices attached, emulated and also redirected (migration to file is used by save/restore in libvirt). Thanks for your detailed report. *** This bug has been marked as a duplicate of bug 805172 *** So for the case someone finds this report, i write down the quick workaround / solution here: Remove the virtual USB devices. The controller may stay in place. Then saving / migration works ! Thanks for the analysis ! |
Created attachment 643484 [details] XML description file of the virtual host Description of problem: Saving a virtual instance fails with error error: internal error unable to execute QEMU command 'migrate': An undefined error has ocurred when running virsh managedsave ... or with the attached error when trying to save from virt-manager. It happens only with one of five virtual hosts running. Version-Release number of selected component (if applicable): qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64 How reproducible: either run virsh managedsave 7 or press the Save button in the "Shutdown" menu in virt-manager Steps to Reproduce: 1. run virsh managedsave 7 Actual results: Error message containing "undefined error" Expected results: virtual host is saved to file. Additional info: Find attached straces of virsh, virt-manager and libvirtd, the error message of virt-manager and the xml file of the problematic instance. The save has been started at 11:38:20 from virt-manager and at 11:44:51 from virsh. There are 5 virtual hosts on this RHEL6.2 machine (hostnames anonymised because of company policies). virsh list gives: [root@host0]# virsh list Id Name State ---------------------------------------------------- 2 host1 running 3 host2 running 4 host4 running 5 host5 running 7 host3 running no idea, why the Id order is this way. They have been created in the order host1 host2 host3 host4 host5. The problem happens only with host3. Saving the others work. So i list the properties of the hosts here: Name CPUs OS Memory location of img file disks disk space swap host1 4 RHEL6 64bit 30 GB local ext3 1 30 GB 12 GB host2 4 RHEL5 64bit 40 GB local ext3 1 30 GB 15 GB host3 2 RHEL3 32bit 4 GB NFS 1 72 GB 4 GB host4 4 RHEL5 64bit 16 GB NFS 1 34 GB 2 GB host5 4 RHEL5 64bit 16 GB NFS 2 30 + 3 GB 2 GB Memory Sum: 106 GB The directory to save the status is local and has 125 GB free space. Please note, that all virtual hosts are running, when the attempt to save host3 fails, so the entire space of 125 GB is available in the save filesystem. The only special thing i see with host3 is, that it has a 32 bit virtual CPU (aside from the old operating system). However, it does not help to configure a x86_64 CPU running this host. Running with 4 CPUs does not help either. On the contrary: on the virtual host the clock randomly jumps back and forth sometimes.