qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Kuniyasu Suzaki <k.suzaki@aist.go.jp>
Cc: stefanha@gmail.com, qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: [Qemu-devel] live migration which includes previos snapshot
Date: Fri, 02 Nov 2012 09:40:15 -0600	[thread overview]
Message-ID: <5093E95F.2070101@redhat.com> (raw)
In-Reply-To: <20121103.000020.17416294.k.suzaki@aist.go.jp>

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

On 11/02/2012 09:00 AM, Kuniyasu Suzaki wrote:
>> You are not the first to request this - libvirt would also like the
>> ability to have read-only access into the contents of an internal
>> snapshot while the rest of qemu continues to write into the image.
> 
> Do you mean that libvirt can change the access mode of internal
> harddisk from read-write to read-only?

No.  I meant that reading an internal snapshot (a read-only operation)
while still using the rest of the qcow2 file read-write for live
operation would be a nice feature.  The very nature of the qcow2 file
format means that you cannot have two writers at the same time; the best
you can do is expose the snapshots as a read-only backing file of yet
another qcow2 file if you want a second writer based on the state of the
snapshot without interfering with the first writer.

> Please tell me how to change the mode by libvirt.

Libvirt can't support reading of internal snapshots until qemu supports
it.  In other words, it's a feature no one has written yet, but which
several people want.

> 
> Does the qemu which has read-only access only, use another COW file?
> Nested COWs sound interested, but the inter COW must be read-only, I think.

Correct - any reading of internal snapshots must be read-only - you are
required to use external backing files before you can have multiple
writers sharing a common backing file.

> 
>>> 2. Use Paolo's runtime NBD server to export the snapshot slave when
>>> the VM is forked:
>>
>> An NBD server on top of the read-only state is an additional step that
>> will make access easier.
> 
> Does an NBD work as COW? It looks convenient.

Rather, I'm thinking of making the NBD of the read-only internal
snapshot be the backing file of the new qcow2 layer.  But yes, NBD is
probably the best way for qemu to expose the contents of an internal
snapshot, rather than inventing yet another protocol.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 617 bytes --]

  reply	other threads:[~2012-11-02 15:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-02  3:15 [Qemu-devel] live migration which includes previos snapshot Kuniyasu Suzaki
2012-11-02  7:19 ` Stefan Hajnoczi
2012-11-02  8:24   ` Kuniyasu Suzaki
2012-11-02 10:30     ` Stefan Hajnoczi
2012-11-02 13:12       ` Eric Blake
2012-11-02 15:00         ` Kuniyasu Suzaki
2012-11-02 15:40           ` Eric Blake [this message]
2012-11-02 15:18       ` Kuniyasu Suzaki
2012-11-02 15:41         ` Eric Blake

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=5093E95F.2070101@redhat.com \
    --to=eblake@redhat.com \
    --cc=k.suzaki@aist.go.jp \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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).