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

[Michael S. Tsirkin]

On Wed, May 23, 2018 at 11:16:04AM +0200, Kevin Wolf wrote:
> 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

The idea to include a format in there sounds very reasonable to me
though. We can then start with a simple text format just showing the
QEMU command line, and others can reuse it for OVF format, etc.

-- 
MST