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?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
