On 08/28/2017 08:18 PM, John Snow wrote: >>> We'd have to develop a new syntax for specifying these resources that >>> can be stored in a qcow2 file, >> >> It's called the json-pseudo-protocol and was developed exactly for this. >> > > That's what I was hinting at for "or otherwise co-opt an existing > syntax" but I was unaware that it was intended for "exactly" this. > > Do we actually use it in any on-disk format, currently? qcow2 only lets > you specify simple filenames in the qcow2 metadata, right?
You can specify json-pseudo backing names both on the command line AND embedded in the qcow2 file itself (within the length limits imposed by the qcow2 header size). Yes, this means it is already possible to create qcow2 files that can only be opened by qemu (or else teaching your alternative program how to parse qemu's json-pseudo-protocol). > >>> or otherwise co-opt an existing syntax >>> in-use by QEMU. This syntax would likely be useful only to QEMU, which >>> would steer the qcow2 format in a direction not too useful by other >>> emulators, and qcow2 is an open format, so we may want to avoid this. >> >> Storing a file name in the backing link field that cannot be interpreted >> by other programs is in my opinion still very much better than not >> storing any information whatsoever, because in the former case other >> programs can at least say "sorry, I have no idea what this means" (or >> maybe they can indeed interpret it, who knows), whereas in the latter >> they may not even know that the qcow2 image is incomplete. >> > > I don't disagree personally, but I seem to recall that Kevin was adamant > that the qcow2 bitmap extension should remain useful and semantically > meaningful to third parties, so I try to keep that in mind. Maybe I > should let him chime in instead of try to "concern troll" my own > suggestions into the ground. We already have that situation today, but you are right to worry about whether making it even more prevalent is something we can try to minimize. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
