Hello,
I'm not sure if I am having a kvm/qemu issue, a virt-manager issue, or a
libvirt issue, so if I am asking the wrong crowd please let me know! In
short, restoring some suspended kvm guests via virt-manager is failing
because libvirt cannot read the qemu header. I cannot find any
documentation on what this means. From virsh's limited documentation I
was able to gather that there is probably something wrong with an xml
file somewhere, but I cannot find it. Any advice is greatly appreciated!
Synopsis:
I have 5 KVM guests on a Fedora 16 laptop host. I manage them locally
through virt-manager. These guests are JUNOS 10.1R1 (installed over
FreeBSD 4.1 mini-inst) on a patched bios (SeaBIOS
pre-0.6.1-20100805_064324-Compaq8510w). One time I suspended my laptop
and the kvm domains were suspended as well. Trying to restore yields the
following error:
Error restoring domain: operation failed: failed to read qemu header
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in
cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in
tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/domain.py", line 1050, in
startup
self._backend.create()
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 510, in
create
if ret == -1: raise libvirtError ('virDomainCreate() failed',
dom=self)
libvirtError: operation failed: failed to read qemu header
#end error output
Package version info:
libvirt-python-0.9.6-2.fc16.x86_64
libvirt-0.9.6-2.fc16.x86_64
libvirt-client-0.9.6-2.fc16.x86_64
gpxe-roms-qemu-1.0.1-4.fc16.noarch
qemu-system-x86-0.15.1-3.fc16.x86_64
qemu-common-0.15.1-3.fc16.x86_64
qemu-kvm-0.15.1-3.fc16.x86_64
qemu-img-0.15.1-3.fc16.x86_64
virt-manager-0.9.0-7.fc16.noarch
virt-manager-common-0.9.0-7.fc16.noarch
virt-viewer-0.4.1-3.fc16.x86_64
Again, any advice is appreciated. I hope I have provided enough info.
Thank you for your time!
-- Dennis
CONFIDENTIALITY NOTICE: The information contained in this message may be
privileged and/or confidential. If you are not the intended recipient, or
responsible for delivering this message to the intended recipient, any review,
forwarding, dissemination, distribution or copying of this communication or any
attachment(s) is strictly prohibited. If you have received this message in
error, please notify the sender immediately, and delete it and all attachments
from your computer and network.
On 12/15/2011 08:48 AM, Dennis Householder wrote:> Hello, > > I'm not sure if I am having a kvm/qemu issue, a virt-manager issue, or a > libvirt issue, so if I am asking the wrong crowd please let me know! In > short, restoring some suspended kvm guests via virt-manager is failing > because libvirt cannot read the qemu header. I cannot find any > documentation on what this means. From virsh's limited documentation I > was able to gather that there is probably something wrong with an xml > file somewhere, but I cannot find it. Any advice is greatly appreciated!This is the correct list; the error message comes from libvirt's qemuDomainSaveImageOpen() method, and implies that you have a corrupted save file (save files are created by 'virsh save' to a user-specified location, or by 'virsh managedsave' to a libvirt-maintained location; the libvirt-guests init script uses virsh managedsave as part of host shutdown).> > Synopsis: > I have 5 KVM guests on a Fedora 16 laptop host. I manage them locally > through virt-manager. These guests are JUNOS 10.1R1 (installed over > FreeBSD 4.1 mini-inst) on a patched bios (SeaBIOS > pre-0.6.1-20100805_064324-Compaq8510w). One time I suspended my laptop > and the kvm domains were suspended as well. Trying to restore yields the > following error: > > Error restoring domain: operation failed: failed to read qemu headerAre you restoring via 'virsh restore path/to/file', or are you just trying to start the guest with 'virsh start' or a similar action in virt-manager? If the former, then path/to/file is indeed corrupt; can you show us the size of that file, as well as 'od -N 128 -tx1z path/to/file'? If the latter, then you've uncovered a bug in the managedsave code (which I will be fixing shortly) - we attempt to detect and unlink corrupt managedsave files automatically, but in looking at the code, I see I missed a code path - if the file is corrupt because it is too short, then we fail to do the unlink(), making the problem perpetual. If this is the case, then please give me the same output as requested in the previous paragraph, but using /var/lib/libvirt/qemu/save/<dom>.save as the path/to/file. Then, after you have given me the details, you can work around the problem by doing 'virsh start --force' to force a fresh boot (the save file is already corrupt, so there is unfortunately no way to get the runtime state of the guest back to what it was when you suspended your host); hopefully your guest can fsck and recover gracefully from what was in the virtual disks at the time of the host suspend. -- Eric Blake eblake at redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 620 bytes Desc: OpenPGP digital signature URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20111215/00e75f1c/attachment.sig>