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

From: Fam Zheng <famz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	ehabkost@redhat.com, qemu-block@nongnu.org,
	qemu-devel@nongnu.org, mreitz@redhat.com,
	Gerd Hoffmann <kraxel@redhat.com>,
	stefanha@redhat.com, berrange@redhat.com
Subject: Re: [Qemu-devel] storing machine data in qcow images?
Date: Wed, 23 May 2018 10:12:21 +0800	[thread overview]
Message-ID: <20180523021221.GE28114@lemon.usersys.redhat.com> (raw)
In-Reply-To: <20180522150221.GF6233@localhost.localdomain>

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.

Fam