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 header Are 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.