From: Eric Blake <eblake@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Anthony Liguori <anthony@codemonkey.ws>,
quintela@trasno.org, KVM devel mailing list <kvm@vger.kernel.org>,
Developers qemu-devel <qemu-devel@nongnu.org>,
Jeff Cody <jcody@redhat.com>,
Federico Simoncelli <fsimonce@redhat.com>
Subject: blockdev operations [was: [Qemu-devel] KVM call agenda for Tuesday 28th]
Date: Tue, 28 Feb 2012 09:07:19 -0700 [thread overview]
Message-ID: <4F4CFBB7.9060707@redhat.com> (raw)
In-Reply-To: <CAJSP0QVfzmJ8=dsndF2a5oiv-kV2UxKdyUMgCp-w1a+d81c33g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3417 bytes --]
On 02/28/2012 07:58 AM, Stefan Hajnoczi wrote:
> On Tue, Feb 28, 2012 at 2:47 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto:
>>> I'm not a fan of transactions or freeze/thaw (if used to atomically
>>> perform other commands).
>>>
>>> We should not export low-level block device operations so that
>>> external software can micromanage via QMP. I don't think this is a
>>> good idea because it takes the block device offline and possibly
>>> blocks the VM. We're reaching a level comparable to an HTTP interface
>>> for acquiring pthread mutex, doing some operations, and then another
>>> HTTP request to unlock it. This is micromanagement it will create
>>> more problems because we will have to support lots of little API
>>> functions.
>>
>> So you're for extending Jeff's patches to group mirroring etc.?
>>
>> That's also my favorite one, assuming we can do it in time for 1.1.
>
> Yes, that's the approach I like the most. It's relatively clean and
> leaves us space to develop -blockdev.
Here's the idea I was forming based on today's call:
Jeff's idea of a group operation can be extended to allow multiple
operations while reusing the framework. For oVirt, we need the ability
to open a mirror (by passing the mirror file alongside the name of the
new external snapshot), as well as reopening a blockdev (to pivot to the
other side of an already-open mirror).
Is there a way to express a designated union in QMP? I'm thinking
something along the lines of having the overall group command take a
list of operations, where each operation can either be 'create a
snapshot', 'create a snapshot and mirror', or 'reopen a mirror'.
I'm thinking it might look something like:
{ 'enum': 'BlockdevOp',
'data': [ 'snapshot', 'snapshot-mirror', 'reopen' ] }
{ 'type': 'BlockdevAction',
'data': {'device': 'str', 'op': 'BlockdevOp',
'file': 'str', '*format': 'str', '*reuse': 'bool',
'*mirror': 'str', '*mirror-format': 'str' } }
{ 'command': 'blkdev-group-action-sync',
'data': { 'actionlist': [ 'BlockdevAction' ] } }
The overall command is atomic - either all operations will succeed, or
the command returns an error pointing to the name of the device that
failed leaving all devices in their pre-command state. Then, for each
requested operation:
If op is 'snapshot', then 'file' names the new snapshot file; 'reuse' is
optional (defaults to false) to say whether qemu creates the file from
scratch, or opens an existing file with the backing file already
populated correctly. 'format' gives the format of 'file', defaulting to
qcow2. 'mirror' and 'mirror-format' must not be given.
If op is 'snapshot-mirror', then 'mirror' is mandatory; and both 'file'
and 'mirror' are opened as a new mirrored snapshot. Again, 'reuse'
affects whether qemu creates the new files from scratch or trusts oVirt
to pre-create both files with backing file information; and 'format' and
'mirror-format' allow control over the image format being opened.
If op is 'reopen', then 'file' is the name of the file to be opened to
replace the current file tied to the blockdev, with type given by
'format'. 'reuse', 'mirror', and 'mirror-format' must not be given.
--
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: 620 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <eblake@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: KVM devel mailing list <kvm@vger.kernel.org>,
Jeff Cody <jcody@redhat.com>,
Developers qemu-devel <qemu-devel@nongnu.org>,
Federico Simoncelli <fsimonce@redhat.com>,
quintela@trasno.org, Anthony Liguori <anthony@codemonkey.ws>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: [Qemu-devel] blockdev operations [was: KVM call agenda for Tuesday 28th]
Date: Tue, 28 Feb 2012 09:07:19 -0700 [thread overview]
Message-ID: <4F4CFBB7.9060707@redhat.com> (raw)
In-Reply-To: <CAJSP0QVfzmJ8=dsndF2a5oiv-kV2UxKdyUMgCp-w1a+d81c33g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3417 bytes --]
On 02/28/2012 07:58 AM, Stefan Hajnoczi wrote:
> On Tue, Feb 28, 2012 at 2:47 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto:
>>> I'm not a fan of transactions or freeze/thaw (if used to atomically
>>> perform other commands).
>>>
>>> We should not export low-level block device operations so that
>>> external software can micromanage via QMP. I don't think this is a
>>> good idea because it takes the block device offline and possibly
>>> blocks the VM. We're reaching a level comparable to an HTTP interface
>>> for acquiring pthread mutex, doing some operations, and then another
>>> HTTP request to unlock it. This is micromanagement it will create
>>> more problems because we will have to support lots of little API
>>> functions.
>>
>> So you're for extending Jeff's patches to group mirroring etc.?
>>
>> That's also my favorite one, assuming we can do it in time for 1.1.
>
> Yes, that's the approach I like the most. It's relatively clean and
> leaves us space to develop -blockdev.
Here's the idea I was forming based on today's call:
Jeff's idea of a group operation can be extended to allow multiple
operations while reusing the framework. For oVirt, we need the ability
to open a mirror (by passing the mirror file alongside the name of the
new external snapshot), as well as reopening a blockdev (to pivot to the
other side of an already-open mirror).
Is there a way to express a designated union in QMP? I'm thinking
something along the lines of having the overall group command take a
list of operations, where each operation can either be 'create a
snapshot', 'create a snapshot and mirror', or 'reopen a mirror'.
I'm thinking it might look something like:
{ 'enum': 'BlockdevOp',
'data': [ 'snapshot', 'snapshot-mirror', 'reopen' ] }
{ 'type': 'BlockdevAction',
'data': {'device': 'str', 'op': 'BlockdevOp',
'file': 'str', '*format': 'str', '*reuse': 'bool',
'*mirror': 'str', '*mirror-format': 'str' } }
{ 'command': 'blkdev-group-action-sync',
'data': { 'actionlist': [ 'BlockdevAction' ] } }
The overall command is atomic - either all operations will succeed, or
the command returns an error pointing to the name of the device that
failed leaving all devices in their pre-command state. Then, for each
requested operation:
If op is 'snapshot', then 'file' names the new snapshot file; 'reuse' is
optional (defaults to false) to say whether qemu creates the file from
scratch, or opens an existing file with the backing file already
populated correctly. 'format' gives the format of 'file', defaulting to
qcow2. 'mirror' and 'mirror-format' must not be given.
If op is 'snapshot-mirror', then 'mirror' is mandatory; and both 'file'
and 'mirror' are opened as a new mirrored snapshot. Again, 'reuse'
affects whether qemu creates the new files from scratch or trusts oVirt
to pre-create both files with backing file information; and 'format' and
'mirror-format' allow control over the image format being opened.
If op is 'reopen', then 'file' is the name of the file to be opened to
replace the current file tied to the blockdev, with type given by
'format'. 'reuse', 'mirror', and 'mirror-format' must not be given.
--
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: 620 bytes --]
next prev parent reply other threads:[~2012-02-28 16:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-27 12:22 KVM call agenda for Tuesday 28th Juan Quintela
2012-02-27 12:22 ` [Qemu-devel] " Juan Quintela
2012-02-27 17:21 ` Eric Blake
2012-02-27 21:58 ` Paolo Bonzini
2012-02-27 21:58 ` Paolo Bonzini
2012-02-27 22:06 ` Anthony Liguori
2012-02-27 22:09 ` Paolo Bonzini
2012-02-27 22:09 ` [Qemu-devel] " Paolo Bonzini
2012-02-28 14:39 ` Stefan Hajnoczi
2012-02-28 14:47 ` Paolo Bonzini
2012-02-28 14:47 ` Paolo Bonzini
2012-02-28 14:58 ` Stefan Hajnoczi
2012-02-28 14:58 ` Stefan Hajnoczi
2012-02-28 16:07 ` Eric Blake [this message]
2012-02-28 16:07 ` [Qemu-devel] blockdev operations [was: KVM call agenda for Tuesday 28th] Eric Blake
2012-02-28 16:12 ` blockdev operations [was: [Qemu-devel] " Paolo Bonzini
2012-02-28 16:12 ` [Qemu-devel] blockdev operations [was: " Paolo Bonzini
2012-02-29 10:16 ` Kevin Wolf
2012-02-29 10:16 ` Kevin Wolf
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=4F4CFBB7.9060707@redhat.com \
--to=eblake@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=fsimonce@redhat.com \
--cc=jcody@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@trasno.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.