qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Uri Lublin <uril@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] migration: adding migration to/from a file
Date: Tue, 20 Jan 2009 14:15:48 +0200	[thread overview]
Message-ID: <4975C074.5010300@redhat.com> (raw)
In-Reply-To: <20090120111530.GJ6004@redhat.com>

Daniel P. Berrange wrote:
> On Mon, Jan 19, 2009 at 09:11:28AM -0600, Anthony Liguori wrote:
>> Uri Lublin wrote:
>>> Migration to file, reuses migration-to-fd.
>>> Migration from file, uses qemu-fopen directly.
>>>
>>> The saved state-file should be used only once and removed (or used
>>> with -snapshot, or a the disk-image should be copied), as the
>>> disk image is not saved, only the VM state.
>>>
>>> Also there is not point of doing a _live_ migration to file (except
>>> for debugging migration code), so I recommend to stop the VM before 
>>> migrating its state to a file.
>>>
>>> An advantage migration-to-file over savevm/loadvm is that for the latter
>>> a qcow2 is a requirement, while the former works for any image-format.
>>>
>>> Signed-off-by: Uri Lublin <uril@redhat.com>
>>> ---
>>> 

>> The migration code assumes that the file descriptor used is 
>> non-blocking.  In general, open() on a file system cannot produce a 
>> non-blocking file descriptor.
> 
> Does it matter if it blocks though ?  Migrating to a file is not
> "live" migration anyway, so if we happen to block the rest of the 
> QEMU event loop during course of writing to the file it doesn't seem
> too serious. Or is there some scenario which badly breaks with blocking
> writes even for non-live usage ?
> 

I first thought it's not that important too.
But it may be less than optimal, especially if qemu does not respond to monitor 
commands, which may affect management applications.
What does libvirt do when qemu does not respond to a monitor command ?

Uri.

  reply	other threads:[~2009-01-20 12:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-19  0:18 [Qemu-devel] [PATCH] migration: adding migration to/from a file Uri Lublin
2009-01-19  0:55 ` Paul Brook
2009-01-20 11:05   ` Uri Lublin
2009-01-20 14:06     ` Ian Jackson
2009-01-19 15:11 ` Anthony Liguori
2009-01-20 11:15   ` Daniel P. Berrange
2009-01-20 12:15     ` Uri Lublin [this message]
2009-01-20 16:24     ` Anthony Liguori
2009-01-20 11:32   ` Uri Lublin
2009-01-20 11:53     ` Daniel P. Berrange
2009-01-20 16:26       ` 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=4975C074.5010300@redhat.com \
    --to=uril@redhat.com \
    --cc=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).