Re: [Qemu-devel] [PATCH 0/3] vpc: support probing of fixed size images

[Jeff Cody <jcody@redhat.com>]

On Fri, Aug 15, 2014 at 08:00:19AM -0600, Eric Blake wrote:
> On 08/15/2014 07:37 AM, Kevin Wolf wrote:
> 
> > We can choose Markus's suggestion of using the file name to guess the
> > format. I don't really like it much, but it seems like a fair compromise
> > that doesn't hurt usability as much.
> 
> In other words, if a user gives a file a "known suffix", then it is
> their own fault if they made that file raw and the guest then happened
> to convert the file to the format matching the suffix?  Or would this
> start giving warnings if the known suffix doesn't match the probed contents?
>

(Eric, I should have cc'ed you on my last email, sorry)

Image this scenario:

    existing chain created a while ago, via:

        qemu-img create -f qcow2 foo.img 1G
        qemu-img create -f qcow2 -b foo.img bar.img 1G


User launches qemu by this commandline:

    qemu-kvm -drive file=bar.img,format=qcow2


Old behavior:

  | foo.img | <--- | bar.img |
  | (qcow2) |      | (qcow2) |

New behavior:

  | foo.img | <--- | bar.img |
  | (raw)   |      | (qcow2) |


So I think we want to make sure that we don't just fall back to raw
for unknown filename extensions.


> > 
> > If we don't want this, we can approach the problem from a different
> > angle: The problem is not probing per se, but that images probed as raw
> > can be written to by guests in a way that the next time they are probed
> > as something else.
> > 
> > What if we let the raw driver know that it was probed and then it
> > enables a check that returns -EIO for any write on the first 2k if that
> > write would make the image look like a different format?
> 
> Not entirely future-proof - as we add support for more formats over
> time, something that passes today could fail in the future.  Worse, a
> guest could exploit an older qemu to write a header that a newer qemu
> would reject.  But it does sound like an interesting approach
> (preventing the guest from doing something risky).
>