qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Live migration - exec: support to be reintroduced?


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] Live migration - exec: support to be reintroduced?
Date: Wed, 5 Nov 2008 14:19:01 +0000
User-agent: Mutt/1.4.1i

On Wed, Nov 05, 2008 at 08:09:56AM -0600, Anthony Liguori wrote:
> Chris Lalancette wrote:
> >Anthony Liguori wrote:
> >  
> >>Charles Duffy wrote:
> >>    
> >>>Howdy.
> >>>
> >>>KVM's live migration support used to support an exec: protoco, 
> >>>allowing  either a completely arbitrary transport or a mechanism for 
> >>>storing system state to a separate file for later resurrection, being 
> >>>used in the latter by libvirt's qemu driver. I notice that this 
> >>>support no longer exists in the current codebase.
> >>>Would a patch reimplementing this support be welcome?
> >>>      
> >>Absolutely.  I wasn't aware that libvirt used the exec: protocol.  I'm 
> >>somewhat surprised by that.  What did it use it for?
> >>    
> >
> >Hm, I didn't realize it used it either, but it uses it for doing a save 
> >operation:
> >
> >static int qemudDomainSave(virDomainPtr dom,
> >                           const char *path) {
> >...
> >    if (asprintf (&command, "migrate \"exec:"
> >                  "dd of='%s' oflag=append conv=notrunc 2>/dev/null"
> >                  "\"", safe_path) == -1) {
> >        qemudReportError(dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
> >                         "%s", _("out of memory"));
> >        VIR_FREE(safe_path);
> >        return -1;
> >    }
> >    free(safe_path);
> >
> >    if (qemudMonitorCommand(driver, vm, command, &info) < 0) {
> >...
> >
> >I don't know if there is a better way to do that with the qemu monitor, to 
> >avoid
> > using migrate altogether.  In any case, I'm sure other people would find 
> > exec:
> >useful as well.
> >  
> 
> Sure.  It would make sense for it to use file: instead of exec: though.
> 
> However, why is it not just using savevm?  Saving the CPU state in the 
> absence of checkpointing storage doesn't make a lot of sense.

This isn't for snapshotting, so checkpointing of storage is unneccessary.
This is just straight save+restore, akin to hibernate-to-disk for a 
physical machine. 

The savevm command only works with qcow files, which is not guarenteed
to be available in this context.

We do intend to support real snapshotting of VMs at some point, for which
"savevm" could be useful

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]