qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* Re: [Qemu-devel] [libvirt] RFC: Exposing backing chains in <domain> XML
       [not found]     ` <5321CE26.70703@redhat.com>
@ 2014-03-13 22:25       ` Eric Blake
  0 siblings, 0 replies; only message in thread
From: Eric Blake @ 2014-03-13 22:25 UTC (permalink / raw)
  To: Peter Krempa, libvir-list@redhat.com; +Cc: qemu-devel@nongnu.org

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

[adding qemu-devel]

Background to those new to the thread:

Previously, libvirt has been tracking a lot of disk tunables alongside
the active layer of a backing chain, without regards to any backing
files in the chain.  However, now that qemu supports named BDS nodes
anywhere in the backing chain, I'm realizing that libvirt needs to track
the entire backing chain in its <domain> XML for maximum control over
each qemu BDS.

On 03/13/2014 09:26 AM, Eric Blake wrote:

> In making the proposed split, I noticed that we've abused the <driver>
> element to contain a hodgepodge of things that are per-device (for
> example, cache is a per-device setting, while format is a per-file
> setting), so I'm now trying to figure out how to tweak the XML to
> express the difference.  I may end up keeping <driver> only at the top
> level, and adding a new <format> subelement inside <backingStore>, then
> for back-compat reasons duplicate <driver format='...'/> and <format> at
> the top level, or teaching the disk source formatter to merely append in
> a string of device-level attributes when formatting the active disk of
> the chain.

Among other things, libvirt can append the following to a -drive
command-line option:

cache=
aio=
rerror=
werror=
discard=
sgio=
bps=
...

Looking in the schema file, BlockdevOptionsBase supports many of this
options on a per blockdev basis.  Does that mean that libvirt should
allow for a different rerror= on a backing file than it does for the
active file?  Similarly for cache= or discard=?  Or are some of these
options really only sensible at the active layer, belonging more to the
-drive than to each backing BDS within the drive?  Knowing which options
belong where will help me partition the libvirt structure into
attributes that are per-file vs. those that are per-device.

-- 
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: 604 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2014-03-13 22:25 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <5320C1DA.6010802@redhat.com>
     [not found] ` <5320C6A5.3090100@redhat.com>
     [not found]   ` <5320EEF9.3020509@redhat.com>
     [not found]     ` <5321CE26.70703@redhat.com>
2014-03-13 22:25       ` [Qemu-devel] [libvirt] RFC: Exposing backing chains in <domain> XML Eric Blake

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