Re: [libvirt] RFC: Exposing backing chains in <domain> XML
[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
Attachments:
- signature.asc (application/pgp-signature — 604 bytes)