qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH 00/14] block (mostly qcow2) changes (v6)
@ 2009-03-17 20:40 Uri Lublin
  2009-03-17 20:40 ` [Qemu-devel] [PATCH 01/14] Introducing qcow2 extensions Uri Lublin
  2009-03-24 11:22 ` [Qemu-devel] [PATCH 00/14] block (mostly qcow2) changes (v6) Gleb Natapov
  0 siblings, 2 replies; 17+ messages in thread
From: Uri Lublin @ 2009-03-17 20:40 UTC (permalink / raw)
  To: qemu-devel; +Cc: Uri Lublin

In this patchset there are three main features:
1. Introduce Qcow2 extensions.
2. Keep backing file format such that no probing is needed.
3. Keep track of highest-allocated-offset and report it upon a user request.
4. Add an open-flag to distinguish between a leaf image and a backing file
   (base image). Also keep the open-flags so we can later use them to
   close and reopen images.

1. Qcow2 extensions are build of magic (id) len (in bytes) and data.
They reside between the end of the header and the backing filename (if exists).
Unknown extensions are ignored (assumed to be added by a newer version)
Based on a work done by Shahar Frank.

2. By keeping the backing file format we:
a. Provide a way to know the backing file format without probing
   it (setting the format at creation time).
b. Enable using qcow2 format over host block devices.
   (only if the user specifically asks for it, by providing the format
   at creation time).

I've added bdrv_create2 and drv->bdrv_create2 (implemented only
by block-qcow2 currently) to pass the backing-format to create.

Also fixes a security flaw found by Daniel P. Berrange on [1]
which summarizes: "Autoprobing: just say no."

[1] http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg01083.html

3. One of the main usage for highest-allocated-offset is to know and act
upon a case of end-of-storage-space. Instead of waiting for
-ENOSPACE (which now may cause the VM to stop), one can
define a threshold and extend the diskspace allocated for
the image.
This info is also good for management systems, so they
can report the user disk space status.

4. With bdrv_close and reopen capability we can possibly:
   a. Open backing files with read-only permission, and reopen with RW
      if needed.
   b. Reopen on destination side after migration before starting to run
      This solves a case where the source changes the disk (especially
      meta-data) while migration is in process.
   c. Check open-flags to keep track of highest-allocated-offset for 
      only leaf images.
      

Changes from v5:
   Patchset includes newly introduced qcow2 extensions.
   Usage of such qcow2 extensions for keeping both backing format and 
       highest-allocated-offset.
   No scanning of qcow2 images upon open.
   Not yet support for num-free.
   Added bdrv_close_all + calling it at end of main.
   Support highest_alloc only for leaf images.

Uri Lublin (14):
      Introducing qcow2 extensions
      block: support known backing format for image create and open
      block-qcow2: keep backing file format in a qcow2 extension
      qemu-img: adding a "-F base_fmt" option to "qemu-img create -b"
      block-qcow2: keep highest allocated offset
      block-qcow2: export highest-alloc through BlockDriverInfo and get_info()
      block: info blockstats: show highest_allocated if exists
      Add a bdrv_close_all() and  call it at the end of main()
      block-qcow2: keep highest alloc offset in a qcow2 extension
      qemu-img: info: show highest_alloc if exists
      qcow2: qcow_read_extensions: make "advance offset over extension" common
      block: pass BDRV_BACKING flag to open of a backing file
      block: keep flags an image was opened with
      block-qcow2: do not keep track of highest-alloc for backing files

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2009-03-24 11:45 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-17 20:40 [Qemu-devel] [PATCH 00/14] block (mostly qcow2) changes (v6) Uri Lublin
2009-03-17 20:40 ` [Qemu-devel] [PATCH 01/14] Introducing qcow2 extensions Uri Lublin
2009-03-17 20:40   ` [Qemu-devel] [PATCH 02/14] block: support known backing format for image create and open Uri Lublin
2009-03-17 20:40     ` [Qemu-devel] [PATCH 03/14] block-qcow2: keep backing file format in a qcow2 extension Uri Lublin
2009-03-17 20:40       ` [Qemu-devel] [PATCH 04/14] qemu-img: adding a "-F base_fmt" option to "qemu-img create -b" Uri Lublin
2009-03-17 20:40         ` [Qemu-devel] [PATCH 05/14] block-qcow2: keep highest allocated offset Uri Lublin
2009-03-17 20:40           ` [Qemu-devel] [PATCH 06/14] block-qcow2: export highest-alloc through BlockDriverInfo and get_info() Uri Lublin
2009-03-17 20:40             ` [Qemu-devel] [PATCH 07/14] block: info blockstats: show highest_allocated if exists Uri Lublin
2009-03-17 20:40               ` [Qemu-devel] [PATCH 08/14] Add a bdrv_close_all() and call it at the end of main() Uri Lublin
2009-03-17 20:40                 ` [Qemu-devel] [PATCH 09/14] block-qcow2: keep highest alloc offset in a qcow2 extension Uri Lublin
2009-03-17 20:40                   ` [Qemu-devel] [PATCH 10/14] qemu-img: info: show highest_alloc if exists Uri Lublin
2009-03-17 20:40                     ` [Qemu-devel] [PATCH 11/14] qcow2: qcow_read_extensions: make "advance offset over extension" common Uri Lublin
2009-03-17 20:40                       ` [Qemu-devel] [PATCH 12/14] block: pass BDRV_BACKING flag to open of a backing file Uri Lublin
2009-03-17 20:40                         ` [Qemu-devel] [PATCH 13/14] block: keep flags an image was opened with Uri Lublin
2009-03-17 20:40                           ` [Qemu-devel] [PATCH 14/14] block-qcow2: do not keep track of highest-alloc for backing files Uri Lublin
2009-03-24 11:22 ` [Qemu-devel] [PATCH 00/14] block (mostly qcow2) changes (v6) Gleb Natapov
2009-03-24 11:44   ` Avi Kivity

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).