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

[Michal Suchánek]

On Wed, 23 May 2018 18:35:31 +0200
Markus Armbruster <address@hidden> wrote:

> Eduardo Habkost <address@hidden> writes:
> 
> > On Wed, May 23, 2018 at 01:19:46PM +0200, Markus Armbruster wrote:  
> >> Eduardo Habkost <address@hidden> writes:
> >>   
> >> > On Mon, May 21, 2018 at 07:44:40PM +0100, Daniel P. Berrangé
> >> > wrote:  
> >> >> On Mon, May 21, 2018 at 03:29:28PM -0300, Eduardo Habkost
> >> >> wrote:  
> >> >> > On Sat, May 19, 2018 at 08:05:06AM +0200, Markus Armbruster
> >> >> > wrote:  
...  
> >> >> > The point here is to allow users to simply copy an existing
> >> >> > disk image, and it will contain enough hints for a cloud
> >> >> > stack to choose reasonable defaults for machine-type and disk
> >> >> > type automatically.  Requiring the user to perform a separate
> >> >> > step to encapsulate the disk image in another file format
> >> >> > defeats the whole purpose of the proposal.  
> >> >> 
> >> >> It doesn't have to mean more work for the user - the application
> >> >> that is used to create the image can do that on their behalf.
> >> >> oVirt for example can import/export OVA files, containing OVF
> >> >> metadata. I could imagine virt-manager, and other tools adding
> >> >> export ability without much trouble if this was deemed a
> >> >> desirable thing. Bundling gives ability to have multiple disk
> >> >> images in one archive, which is something OVF does.  
> >> >
> >> > I have the impression that "the application that is used to
> >> > create the image" is a very large set.  It can be virt-manager,
> >> > virt-install, virt-manager, or even QEMU itself.
> >> >
> >> > Today people can simply create a VM on virt-manager, or run QEMU
> >> > manually, and upload the qcow2 image directly from its original
> >> > location (they don't need to copy/export it).  Don't we want the
> >> > same procedure to keep working instead of requiring users to use
> >> > another tool?  
> >> 
...
> >> With OVF, you solve the problem further up the stack: you do
> >> virtual appliances instead of disk images.
> >>   
> >
> > I guess the main problem is that people are already using disk
> > images as if they were virtual appliances.
> >
> > We can tell people to stop doing that and use OVF, but then we
> > won't make anybody's life any easier: publishers of images might
> > need to generate both qcow2 and OVF images if they want it to
> > work with older hosts; consumers will need to find out if they
> > need qcow2 or OVF.  
> 
> I'm afraid providing for "hints" in QCOW2 could only add problems.  To
> pick the right hints, publishers need to predict how future software
> consuming the image will interpret them.  Consumers may have to
> configure their software to interpret hints in various ways.

That depends on the hint.

If you define that the key libvirt-xml contains the libvirt machine
definition it is up to libvirt to define what exactly the hint contains.

It allows exporting a machine from virt-manager or virsh and importing
into same with exact same properties. Looking at it will probably give
you some idea how to configure the VM in another virtualization
solution.

Similarly OpenStack can define different hint for OpenStack VMs. 

You are free to equip you appliance with multiple hints if you want it
to work it on multiple virtualization solutions. It is much more
efficient than providing multiple appliance images that embed the
same disk image and different metadata. Virtualization solutions are
free to implement conversions to ease importing VMs from different
source, even for something as horrible as OVF.

It is a bit limiting, though.

You cannot make an applicance with multiple disks when the metadata is
embedded in a disk image.

Thanks

Michal