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

[Kevin Wolf]

Am 23.05.2018 um 04:12 hat Fam Zheng geschrieben:
> On Tue, 05/22 17:02, Kevin Wolf wrote:
> > Am 22.05.2018 um 16:19 hat Michael S. Tsirkin geschrieben:
> > > On Tue, May 22, 2018 at 09:35:55AM +0200, Gerd Hoffmann wrote:
> > > >   Hi,
> > > > 
> > > > > You must /sometimes/ supply the correct machine type.
> > > > > 
> > > > > It is quite dependent on the guest OS you have installed, and even
> > > > > just how the guest OS is configured.  In general Linux is very
> > > > > flexible and can adapt to a wide range of hardware, automatically
> > > > > detecting things as needed. It is possible for a sysadmin to build
> > > > > a Linux image in a way that would only work with I440FX, but I
> > > > > don't think it would be common to see that.
> > > > 
> > > > I think it would be pretty hard to actually build such an image.
> > > > 
> > > > The more critical thing for linux guests is the storage driver which
> > > > must be included into the initrd so the image can mount the root
> > > > filesystem.  And the firmware, bios vs. uefi is more critical than
> > > > pc vs. q35.
> > > 
> > > I think we can start by finding a location to embed a string in a qcow
> > > image, add ability for qemu-img to set and get this string.  We can
> > > discuss how it's formatted separately.
> > 
> > If we want it, we'll find a place to store it.
> > 
> > But the first thing we need is a spec for what's actually in it. Just
> > storing a machine type hint would be a one-off hack that wouldn't last
> > very long before we want to add the next thing.
> > 
> > Essentially, what we need is a description of the virtual machine that
> > we suggest to use with this image. We can try to reuse something
> > existing there, like libvirt XML or OVF, or invent something new (a JSON
> > array describing runtime options?). One difference to existing formats
> > is probably that we want only frontends and no backends in the
> > description.
> > 
> 
> Do we really need a uniform way and require compliance to the standard we
> choose, and implement verification in the block driver, or can we get away 
> with
> a description field that accepts any text and leave it to the user to decide
> what to put there? In the header we could assign a Content-type field that
> defaults to 'text/plain' to the description, that way apps can mark the data 
> as
> "application/ovf" if they want, or whatever the upper layer decides.

Yes, we can. But I'm not sure if I want. Providing low-level features
without telling users how they are supposed to be used usually results
in a big surprise for both sides eventually.

Kevin