Re: [Qemu-devel] storing machine data in qcow images?

[Eduardo Habkost]

On Fri, May 18, 2018 at 06:30:38PM +0300, Michael S. Tsirkin wrote:
> Hi!
> Right now, QEMU supports multiple machine types within
> a given architecture. This was the case for many architectures
> (like ARM) for a while, somewhat more recently this is the case
> for x86 with I440FX and Q35 options.
> 
> Unfortunately this means that it's no longer possible
> to more or less reliably boot a VM just given a disk image,
> even if you select the correct QEMU binary:
> you must supply the correct machine type.
> 
> Some guests go even further and require specific devices to be present.
> 
> Would it be reasonable to support storing this information in the qcow
> image itself?  For example, I can see it following immediately the
> backing file path within the image.
> 
> As Eduardo pointed out off-list, the format could be a set of key-value
> pairs. Initially qemu-img could gain ability to retrieve and manipulate
> these. Down the road we could teach qemu to use them automatically.
> We could also thinkably warn the user, or drop the image from the boot
> order.

Some additional context:

Currently OpenStack and other management stacks support importing
"guest images", that are often just qcow2 disk images.  Today all
management stacks suppose x86 guest images all work using
pc-i440fx, but this is likely to change with newer guest OS
versions.

Right now it's very convenient for users to simply create disk
images using whatever VM management tools they have (e.g.
virt-image, virt-install, virsh) to install and configure a
guest, and all they need to do is to upload the resulting disk
image.

If information about the machine-type and disk type used to
create the VM is saved in the disk image, OpenStack and other
management stacks can use this information as hints to choose the
right machine-type for a given guest image.  This would also help
the system detect mistakes like using an image for the wrong
architecture.

I don't think QEMU needs to use this information automatically,
necessarily.  I think the first step is to simply make QEMU save
this information in the disk image, and making qemu-img able to
read and write this information.

> 
> Reasonable (IMO) things we could store in such a section:
> - qemu architecture to use with the image
> - machine type

Maybe just the machine-type family would be enough?

> 
> more possibilities:
> - required cpu flags
> - expected frontend devices
> - kernel flags for device tree based guests

All these might be useful in some cases.  I think it's important
to highlight that these would be just hints for systems importing
the disk image, and not mandatory.

> 
> Security considerations
> - If there is a machine type specific security issue,
>   this makes it easier to trick user to hitting it.
>   Not sure how common this is.

Yeah, we need to keep this in mind for every hint we add to this
system.

I would prefer a system with a very limited set of
possible input values, to avoid transforming this into a new
attack vector.

For example, I think the hint needs to specify: only the
machine-type family instead of the full machine-type version;
only expected NIC model instead of NIC model + mac address + PCI
address; only the CPU architecture instead of CPU model name +
flags.

(But "guest kernel flags" seems acceptable, because it's parsed
only by guest code.)

If any management stack requires a more detailed VM description,
they won't be covered by this system, and they can't expect qcow2
disk images to carry all the information they need.


> - We most likely shouldn't get backend parameters from the image

Agreed.

-- 
Eduardo