qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrea Bolognani
Subject: Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?
Date: Thu, 07 Jun 2018 12:02:29 +0200

On Wed, 2018-06-06 at 17:32 +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 06, 2018 at 10:36:20AM -0500, Eric Blake wrote:
> > But for the new config to be useful, you have to modify at least one tool in
> > the path.  At which point, it is just as easy to say: "libvirt is now smart
> > enough to read the config file out of a .qcow2 to know that it should prefer
> > a q35 machine" as it is to say "libvirt is now smart enough to treat a .tar
> > file containing .qcow2 and a config file that states that it should prefer a
> > q35 machine", and either approach requires just a single file for the user
> > to download.
> 
> Just to be clear, libvirt isn't going to do either of those things.
> 
> Whether there is metadata stuffed inside qcow2, or in a metdata file
> inside a tar file, libvirt is not going to look inside either of them.
> The XML is the only place libvirt deals with the hardware config.
> 
> Extracting machine type is always going to be a job for the layer above
> such as OpenStack/OVirt/Virt-manager/etc. They will then decide whether
> or not they want to honour that info, and if so, put it into the XML
> they give to libvirt.
> 
> As mentioned elsewhere, IMHO, it is more friendly to those tools
> to use pre-existing formats, eg TAR and XML/JSON, for which
> their respective programming langauges already have APIs/parsers.

Something that I haven't seen mentioned in the thread - and this
looks like as good a point as any to jump in - is that for q35
guests using EFI as well as aarch64 guests the "one click import"
experience requires not only hints about the machine (and firmware!)
type, but also a copy of the EFI variable store:

  $ virt-builder fedora-27 --arch aarch64 --notes
  Fedora® 27 Server (aarch64)

  [...]

  You will need to use the associated UEFI NVRAM variables file:
    http://libguestfs.org/download/builder/fedora-27-aarch64-nvram.xz

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.

It's pretty easy then to imagine using something like

  $ virt-builder \
    fedora-27 \
    --arch aarch64 \
    --format qva \
    --output f27-aarch64.qva

or download the equivalent from some website, followed by

  $ virt-install \
    --name f27-aarch64 \
    --import \
    --input f27-aarch.qva

or the equivalent pointy-clicky import step and having things
Just Work™, provided sufficient hints are included in the archive;
the user, or the management application, would of course be able
to override such hints at import time.

-- 
Andrea Bolognani / Red Hat / Virtualization



reply via email to

[Prev in Thread] Current Thread [Next in Thread]