On Thu, Nov 06, 2014 at 03:14:19PM +0100, Eric Blake wrote:
> On 11/06/2014 02:57 PM, Markus Armbruster wrote:
>
> >> Yes, you can override the backing file driver (backing.driver=raw should
> >> do the trick). Not really user-friendly, especially with long backing
> >> file chains, but it happens to be there.
> >>
> >> And of course, libvirt should be using it for non-qcow2 or qcow2 without
> >> the backing format header extension (but doesn't yet).
> >
> > I'm glad it's there. Too bad libvirt doesn't use it, yet. Supports my
> > point that secure usage is too hard now.
>
> Indeed, libvirt is still lacking on enforcing the backing type that it
> probed vs. letting qemu re-probe a (possibly different) backing type.
> Were libvirt to actually enforce this (that is, libvirt's default
> out-of-the-box policy is to avoid all probes, and treat anything without
> a type as raw) means that a user that forgets to use -obacking_fmt and
> creates a chain base<-mid<-top will have the following conflicting view:
>
> libvirt: mid[raw]<-top[qcow2]
> qemu: base[qcow2]<-mid[qcow2]<-top[qcow2]
>
> Right now, if the chain is only 2 deep, qemu happily boots the guest
> with qcow2 format (in spite of libvirt treating mid as raw); but when
> the chain is 3 deep, because libvirt failed to give SELinux permissions
> to base, then qemu fails to open base, and fails to boot, but the
> failure message is very cryptic.
>
> On the other hand, if libvirt were to ENFORCE its view that mid is raw,
> by passing appropriate drive options, then qemu would always boot, but
> now the top image would be visibly corrupted (treating a qcow2 file as
> raw leads to MUCH different data visible in the guest) and the guest
> will likely fail to boot completely, but with no error message from qemu
> (rather more likely that things just hang in a 100% cpu loop in the
> guest). Although the existing error message is cryptic, this new
> behavior of enforcing a probed image to be raw feels like it will be
> even more user-unfriendly.
>
> At any rate, I've certainly been working on getting libvirt to output
> the ENTIRE backing chain that it has determined, rather than its old
> behavior of keeping that information in memory only; this at least helps
> libvirt developers diagnose bug reports ("show me what libvirt thought
> your backing chain was, then go fix your XML to tell libvirt the truth
> and your problem will go away, if you didn't corrupt the backing files
> in the meantime with something like a 'commit' operation").
>
> [I mentioned libvirt's default policy is to forbid probing and treat
> untyped disks as raw; but both of those knobs can be tweaked, to either
> allow probing, or treat the default type as qcow2, or both]
>
>
> >>
> >> .img is not as clear, I've seen people using it for other formats. It's
> >> still a disk image, but not a raw one.
> >
> > Is this usage common?
>
> At least on my laptop - yes. I have several qcow2 files with an image
> suffix of .img (perhaps because I was lazy when I created them, or
> sometimes because I was quickly hacking a script to add a -fqcow2 to a
> qemu-img line without changing the file name, because changing the name
> would have a ripple effect on the rest of the script). But I don't know
> if my usage is typical, and I also don't mind adjusting my naming
> conventions to silence a warning if qemu starts getting picky about
> confusing name-vs-contents issues. And if I consistently use
> format=qcow2, I shouldn't be penalized with the warning, right?
If you look at the QEMU "startup" documentation[1] we link to from the
wiki[2], it uses .img for many of the QEMU image creation and usage
examples. That leads me to think that '.img' usage as a generic
extension may be fairly common. But, [1] seems outdated, as well.
[1] http://en.wikibooks.org/wiki/QEMU/Images
[2] http://wiki.qemu.org/Manual
