qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: hch@lst.de
Subject: [Qemu-devel] QEMU online guest disk resize wrt host block devices
Date: Thu, 1 Sep 2011 14:27:55 +0100	[thread overview]
Message-ID: <20110901132755.GG14462@redhat.com> (raw)

We want to support online resize of guest disks in the libvirt API for
QEMU, and had intended to use the fairly recently added 'block_resize'
command:

  commit db97ee6a976bacbb0d18818e951cfc41b39269a7
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Mon Jan 24 13:32:41 2011 +0100
 
    block: tell drivers about an image resize

  commit 6d4a2b3a47959f02e7f307f50396e70e8464f95e
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Mon Jan 24 13:32:33 2011 +0100

    block: add block_resize monitor command

There is unfortunately a problem with the design of this monitor command
because it has tied the task of resizing the host backing file for the
virtual disk, together with the task of notifying the guest device of the
block resize. This means that we can only use 'block_resize' for disks
that are backed by image files (raw, qcow2, etc) that QEMU can actually
resize.

To be able to support online resize of virtual disks backed by host
block devices, LVM volumes, SCSI LUNs, iSCSI LUNs, etc we need to be
able to decouple these tasks. The resize of the block device needs to
be done outside QEMU, either by privileged tools on the host, or by a
remote SAN administrator, or a combo of both.

IOW, we need a way to tell QEMU to merely re-read the host file/block
size to detect an externally performed resize, and then just notify
the guest. While this would also be sufficient for raw file images,
obviously we don't want todo this with any of the magic formats where
QEMU has to remain in charge of updating metadata while active.

I see two likely approaches:

 1. Add a parameter to the existing 'block_resize' command
    'refreshonly=true|false'

 2. Add a separate command  'block_refresh'

Both of these options would internally just re-read the capacity of the
BlockDriver image, and then notify the guest device.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

             reply	other threads:[~2011-09-01 13:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-01 13:27 Daniel P. Berrange [this message]
2011-09-01 14:05 ` [Qemu-devel] QEMU online guest disk resize wrt host block devices Christoph Hellwig
2011-09-01 14:30   ` Daniel P. Berrange
2011-09-01 15:55     ` Christoph Hellwig
2011-09-02 15:00       ` Daniel P. Berrange
2011-09-07 11:02       ` [Qemu-devel] [PATCH] block: allow resizing of images residing on host devices Christoph Hellwig
2011-09-09  9:37         ` Kevin Wolf
2011-09-01 14:27 ` [Qemu-devel] QEMU online guest disk resize wrt host block devices Daniel P. Berrange
2011-09-01 15:56   ` Christoph Hellwig
2011-09-05 13:03     ` 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=20110901132755.GG14462@redhat.com \
    --to=berrange@redhat.com \
    --cc=hch@lst.de \
    --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).