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

[Andrea Bolognani]

On Thu, 2018-06-07 at 11:22 +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 07, 2018 at 12:02:29PM +0200, Andrea Bolognani wrote:
> > While hints might be considered a reasonable fit for qcow2, I think
> > it's pretty hard to argue for embedding the NVRAM file in there,
> > which to me signals quite clearly that an archive containing the
> > disk image(s) *and* the configuration hints *and* other ancillary
> > files such as the NVRAM is the only way to build a solution that's
> > not dead on arrival.
> 
> On a similar theme, I can imagine users wanting to provide a TPM
> data blob too, and for AMD SEV we'd need to be able to provide a
> DH key, and session blob too IIUC.

I'm not familiar with the technologies you're talking about, but
all that sounds like something very security sensitive and not
something eg. the Fedora project would want to bake into their
cloud images.

Perhaps we should keep in mind that this kind of archive format
lends itself quite naturally to both generic ready-made images and
custom, fully configured images: in the former case it would only
contain the few things mentione above, while in the latter it might
also have security sensitive data that's specific to the deployment
it's going to be used against.

For non-vanilla images, it might be interesting to include the
libvirt XML in its entirety, which would make it trivial to keep
around a full-contained copy of a guest that can be imported back
into libvirt with a single click; on the other hand, the management
layer might want to override that, and for generic images we
probably want to avoid the security implications of people
importing potentially untrusted configurations into the system
libvirt instance and stick to just a few hints instead.

So there's at least two partially overlapping use cases right
there. Fun :)

-- 
Andrea Bolognani / Red Hat / Virtualization