From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLV2J-00051p-V3 for qemu-devel@nongnu.org; Wed, 23 May 2018 10:46:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLV2J-00023r-0O for qemu-devel@nongnu.org; Wed, 23 May 2018 10:46:44 -0400 Date: Wed, 23 May 2018 17:46:38 +0300 From: "Michael S. Tsirkin" Message-ID: <20180523174350-mutt-send-email-mst@kernel.org> References: <20180518180440-mutt-send-email-mst@kernel.org> <20180518170956.GI8615@redhat.com> <20180522073555.peibbwoqvbor7nrs@sirius.home.kraxel.org> <20180522171112-mutt-send-email-mst@kernel.org> <20180522150221.GF6233@localhost.localdomain> <20180523021221.GE28114@lemon.usersys.redhat.com> <20180523091604.GC7523@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180523091604.GC7523@localhost.localdomain> Subject: Re: [Qemu-devel] storing machine data in qcow images? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Fam Zheng , ehabkost@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com, Gerd Hoffmann , stefanha@redhat.com, berrange@redhat.com 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