[Pkg-libvirt-maintainers] Bug#537445: Bug#537445: restoring leaves

[Guido Günther]

On Tue, Aug 04, 2009 at 02:25:58PM +0200, martin f krafft wrote:
> also sprach Guido Günther <agx at sigxcpu.org> [2009.07.24.0119 +0200]:
> > you need to send it a "cont" to continue on the monitor socket.
> > cat cont > /dev/pts/0 
> > should do.
> 
> I kind of doubt that, and if it worked, then it was a bug. libvirt
> tries to hide the monitor socket, and also if it was just waiting
> for cont, then the machine wouldn't reboot after 60 seconds.
Libvirt hides the socket to libvirtd (when running in qemu:///session)
It doesn't hide any monitor sockets used by kvm/qemu. At least not that
I know of.

> Anyway, I tried it, and cont did not do anything. However, while
> trying, I also found that it worked *once* - just restore and the
> machine came back. I have not made it work a second time though.
Which further points to kvm getting confused. Rethinking this whole
issue: you can't restore a saved image easily without using libvirt
since it adds a custom header to identify the vm, didn't think about
this before, sorry.

So should you have the time and patience to reproduce without libvirt,
this should do:

* run the kvm instance without libvirt (remove all options except for
  the boot and disk stuff), e.g. I did:
    kvm -usb -boot d -cdrom ../isos/dsl-4.2.5.iso
* hit ctrl-alt-2
* save the using: 
    stop
    migrate "exec: dd of=foo.img"
    quit
* restart kvm with:
    cat foo.img |  kvm -S -usb -boot d -cdrom ../isos/dsl-4.2.5.iso -incoming exec:cat
* hit ctrl-alt-2 again and type "cont".

I just tried that with qemu and it works as expected. It should break in
your case. I'll try to reproduce with a current kvm once I get near a
kvm capable machine.
Cheers,
 -- Guido