qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Live migration - exec: support to be reintroduced?
Date: Wed, 5 Nov 2008 14:19:01 +0000	[thread overview]
Message-ID: <20081105141901.GL25523@redhat.com> (raw)
In-Reply-To: <4911A934.9040007@codemonkey.ws>

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	other threads:[~2008-11-05 14:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-05  0:40 [Qemu-devel] Live migration - exec: support to be reintroduced? Charles Duffy
2008-11-05  5:38 ` Anthony Liguori
2008-11-05  7:54   ` Chris Lalancette
2008-11-05 14:09     ` Anthony Liguori
2008-11-05 14:19       ` Daniel P. Berrange [this message]
2008-11-05 14:52         ` Jamie Lokier
2008-11-05 15:12         ` Anthony Liguori
2008-11-05 18:10           ` [Qemu-devel] " Charles Duffy
2008-11-05 18:55           ` Charles Duffy
2008-11-05 19:10             ` Anthony Liguori
2008-11-05 10:05   ` [Qemu-devel] " Daniel P. Berrange
2008-11-05 13:03     ` Avi Kivity
2008-11-05 14:14       ` Anthony Liguori
2008-11-05 14:37         ` Daniel P. Berrange
2008-11-05 15:19           ` Anthony Liguori
2008-11-05 17:23             ` Daniel P. Berrange
2008-11-05 17:30               ` Anthony Liguori
2008-11-05 18:13             ` Avi Kivity
2008-11-05 18:10         ` Avi Kivity
2008-11-07  1:54   ` [Qemu-devel] [PATCH] " Charles Duffy
2008-11-07 18:49     ` [Qemu-devel] Re: [PATCH] Re: Live migration - exec: support to be reintroduced? (r2) Charles Duffy
2008-11-11 16:41       ` Charles Duffy
2008-11-11 16:46       ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081105141901.GL25523@redhat.com \
    --to=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).