On Wed, Jun 06, 2018 at 11:14:32AM -0300, Eduardo Habkost wrote: > On Wed, Jun 06, 2018 at 02:50:10PM +0100, Daniel P. Berrangé wrote: > > On Wed, Jun 06, 2018 at 03:45:10PM +0200, Michal Suchánek wrote: > > > > > > I think that *if* we want an 'appliance' format that stores a whole VM > > > in a single file to ease VM distribution then the logical place to look > > > in qemu is qcow. The reason have been explained at length. > > > > I rather disagree. This is a common problem beyond just QEMU and everyone > > just uses an existing archive format (TAR, ZIP) for bundling together > > one or more disk images, metdata for config, and whatever other resources > > are applicable for the vendor. This works with any disk format (raw, > > qcow2, vmdk, vpc, etc) so is preferrable to inventing someting that is > > specific to qcow2 IMHO. > > Now we have N+1 appliance file formats. :) > > (We like it or not, qcow2 is already used as an appliance format > for single-disk VMs in practice.) > > But I agree this must not be specific to qcow2. The same VM > description format we agree upon should work with other disk > formats or with multi-disk appliances. > > If we specify a reasonable VM description format for appliances > and make it work inside (e.g.) tar files, we will still have the > option of allowing the description be placed inside qcow2 if we > really want to. I don't think we need to finish this qcow2 > bikeshedding exercise right now.
Yes, I think that is sensible, as once we actually try it out in real world cases, we might then find a tar/zip is sufficient after all and we don't need to do something extra for qcow2. Also means we can do experiments without committing to a qcow2 format spec change right away. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|