On Tue, Feb 25, 2020 at 12:50:21 +, Daniel Berrange wrote:
> On Mon, Feb 24, 2020 at 06:10:46PM +0100, Peter Krempa wrote:
> > On Mon, Feb 24, 2020 at 14:24:15 +, Daniel Berrange wrote:
> > > On Mon, Feb 24, 2020 at 02:34:16PM +0100, Peter Krempa wrote:
[...]
> > > Would there be any
On Mon, Feb 24, 2020 at 06:10:46PM +0100, Peter Krempa wrote:
> On Mon, Feb 24, 2020 at 14:24:15 +, Daniel Berrange wrote:
> > On Mon, Feb 24, 2020 at 02:34:16PM +0100, Peter Krempa wrote:
> > > On Wed, Feb 19, 2020 at 13:12:53 -0600, Eric Blake wrote:
>
> [...]
>
> > > I'll reiterate the
On Mon, Feb 24, 2020 at 14:24:15 +, Daniel Berrange wrote:
> On Mon, Feb 24, 2020 at 02:34:16PM +0100, Peter Krempa wrote:
> > On Wed, Feb 19, 2020 at 13:12:53 -0600, Eric Blake wrote:
[...]
> > I'll reiterate the historical state of the problem because I think it's
> > important:
> >
> >
On Mon, Feb 24, 2020 at 02:34:16PM +0100, Peter Krempa wrote:
> On Wed, Feb 19, 2020 at 13:12:53 -0600, Eric Blake wrote:
> > [adding qemu]
>
> Adding Daniel as he objected to qemu-img.
>
> >
> > On 2/19/20 12:57 PM, Peter Krempa wrote:
>
> [...]
>
> > > Additionally I think that we could
On Wed, Feb 19, 2020 at 13:12:53 -0600, Eric Blake wrote:
> [adding qemu]
Adding Daniel as he objected to qemu-img.
>
> On 2/19/20 12:57 PM, Peter Krempa wrote:
[...]
> > Additionally I think that we could just get rid of the copy of the image
> > detection copy in libvirt and replace it by
[adding qemu]
On 2/19/20 12:57 PM, Peter Krempa wrote:
Namely a user creates an overlay on top of single raw/qcow2 image and
expects it to work. And it's not just random users, libguestfs and
openstack also neglected to set the backing format.
Yes, and they are getting patched. Belatedly,
On Wed, Feb 19, 2020 at 11:07:09 -0600, Eric Blake wrote:
> On 2/19/20 10:40 AM, Peter Krempa wrote:
[]
> > Namely a user creates an overlay on top of single raw/qcow2 image and
> > expects it to work. And it's not just random users, libguestfs and
> > openstack also neglected to set the
On 2/19/20 10:40 AM, Peter Krempa wrote:
1b: base.raw probes as qcow2 (because of whatever the guest wrote there),
using it as qcow2 is wrong - the guest will see corrupted data. What's more,
if the probe sees it as qcow2 with backing file, and we open the backing
file, it also has security
On Wed, Feb 19, 2020 at 17:40:34 +0100, Peter Krempa wrote:
> On Wed, Feb 19, 2020 at 10:21:00 -0600, Eric Blake wrote:
> > On 2/17/20 11:13 AM, Peter Krempa wrote:
[...]
> > > With pre-blockdev configurations this will restore the previous
> > > behaviour for the images mentioned above as qemu
On 2/19/20 10:21 AM, Eric Blake wrote:
It took me a few minutes of thinking about this.
Scenario 1:
base.raw <- wrap.qcow2
where wrap.qcow2 specifies backing of base.raw but not the format. If
we probe, we can have a couple of outcomes:
1a: base.raw probes as raw (the probed image has no
On Wed, Feb 19, 2020 at 10:21:00 -0600, Eric Blake wrote:
> On 2/17/20 11:13 AM, Peter Krempa wrote:
> > Allow format probing to work around lazy clients which did not specify
> > their format in the overlay. Format probing will be allowed only, if we
>
> s/only, if/only if/
>
> > are able to
On 2/17/20 11:13 AM, Peter Krempa wrote:
Allow format probing to work around lazy clients which did not specify
their format in the overlay. Format probing will be allowed only, if we
s/only, if/only if/
are able to probe the image, the probing result was successful and the
probed image does
Allow format probing to work around lazy clients which did not specify
their format in the overlay. Format probing will be allowed only, if we
are able to probe the image, the probing result was successful and the
probed image does not have any backing or data file.
This relaxes the restrictions
13 matches
Mail list logo
