qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC configurable block formats


From: Anthony Liguori
Subject: Re: [Qemu-devel] RFC configurable block formats
Date: Wed, 30 Sep 2009 18:27:56 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Markus Armbruster wrote:
We have code for a quite a few block formats.  A quick grep shows bochs,
cloop, cow, dmg, ftp, ftps, host_cdrom, host_device, host_floppy, http,
https, nbd, parallels, qcow, qcow2, raw, tftp, vdi, vmdk, vpc, vvfat.
Only formats ftp, ftps, http, https, tftp are optional (see configure
--enable-curl).

While I trust that all of these formats are useful at least for some
people in some circumstances, some of them are of a kind that friends
don't let friends use in production.

In short, I'd like to be able to configure block formats.  Simple
enough, eh?  Except there's a catch: I'd like to be able to include more
formats in tools like qemu-img than in qemu proper.  That lets me
restrict qemu proper, where a faulty block driver has the greatest
potential for mischief, to the formats I trust and need, and still keep
useful capability for other formats in qemu-img.

Thus, I'd like to be able to configure a block driver off for
everything, or on for utility programs and off for qemu proper, or on
for everything.

A naive implementation of this idea simply links only those block
drivers into a program that have been configured for it.  Unfortunately,
this leads to an unwanted difference in behavior between the different
programs when the format is probed.

Probing gives every block driver a chance to "score" the image, and
picks the one with the highest score (I'm simplifying, but it'll do to
illustrate the problem).  If two programs have different sets of
drivers, probing may yield different results.  I don't like that.

Say I configure crusty old qcow (note lack of 2) for utility programs
only.  Then I don't want qemu to silently treat qcow images as raw, I
want it to tell me it can't do qcow.  To be precise:

If a format is configured off, no program shall recognize it.

Else all programs shall recognize it, but

    if it is configured on for utility programs, off for qemu proper,
    then recognizing it in qemu proper shall be an error.

If you agree this is useful, I'd be willing to code it.

I'd rather see something like a driver white list/black list for qemu proper. The list would be used to exclude block formats and could be extended to support read-only formats vs. read-write formats. For instance, --enable-block-formats='qcow2 raw'. It avoids polluting the block interface with knowledge of the distinction between a "utility" program and qemu proper.

Regards,

Anthony Liguori






reply via email to

[Prev in Thread] Current Thread [Next in Thread]