Re: [Qemu-devel] qcow2 snapshot + resize

Re: [Qemu-devel] qcow2 snapshot + resize

[lihuiba]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Max, 

I'll see what I can do, and give you my plan.


Thanks!




>On 29.12.2015 10:38, lihuiba wrote:
>> Hi,
>>
>> In our production environment, we need to extend a qcow2 image with
>> snapshots in it. This feature, however, is not implemented yet. 
>>
>> So I want to ask, if this feature is under active development?
>
>No, it is not.
>
>> How can I
>> help with this feature?
>
>Well, you can implement it. ;-)
>
>> It seems that, this feature is not too difficult as long as cluster_size
>> is kept unchanged. Is this correct?
>
>The thing is that one would need to update all the inactive L1 tables. I
>don't think it should be too difficult, it's just that apparently so far
>nobody ever had the need for this feature.

>I can take a look, but I can't say anything about whether or when
>anything will come out of it.

>Max



[-- Attachment #2: Type: text/html, Size: 1237 bytes --]

Re: [Qemu-devel] qcow2 snapshot + resize

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

On 01/05/2016 05:10 AM, lihuiba wrote:

>>> In our production environment, we need to extend a qcow2 image with
>>> snapshots in it.

>> The thing is that one would need to update all the inactive L1 tables. I
>> don't think it should be too difficult, it's just that apparently so far
>> nobody ever had the need for this feature.

Is resizing a snapshot really what you want?  Ideally, a snapshot tracks
the data from a point in time, including the metadata of the size being
tracked at that time.  Extending the snapshots then reverting to that
snapshot means your guest would see a larger disk on revert than it did
at the time the snapshot was created, which guests might not handle very
well.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] qcow2 snapshot + resize

[John Snow]

On 01/05/2016 08:55 AM, Eric Blake wrote:
> On 01/05/2016 05:10 AM, lihuiba wrote:
> 
>>>> In our production environment, we need to extend a qcow2 image with
>>>> snapshots in it.
> 
>>> The thing is that one would need to update all the inactive L1 tables. I
>>> don't think it should be too difficult, it's just that apparently so far
>>> nobody ever had the need for this feature.
> 
> Is resizing a snapshot really what you want?  Ideally, a snapshot tracks
> the data from a point in time, including the metadata of the size being
> tracked at that time.  Extending the snapshots then reverting to that
> snapshot means your guest would see a larger disk on revert than it did
> at the time the snapshot was created, which guests might not handle very
> well.
> 

Unless reverting to a snapshot also implied undoing the re-size.

Re: [Qemu-devel] qcow2 snapshot + resize

[lihuiba]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

At 2016-01-05 21:55:56, "Eric Blake" <eblake@redhat.com> wrote:
>On 01/05/2016 05:10 AM, lihuiba wrote:
>
>>>> In our production environment, we need to extend a qcow2 image with
>>>> snapshots in it.
>
>>> The thing is that one would need to update all the inactive L1 tables. I
>>> don't think it should be too difficult, it's just that apparently so far
>>> nobody ever had the need for this feature.
>
>Is resizing a snapshot really what you want?  Ideally, a snapshot tracks
>the data from a point in time, including the metadata of the size being
>tracked at that time.  Extending the snapshots then reverting to that
>snapshot means your guest would see a larger disk on revert than it did
>at the time the snapshot was created, which guests might not handle very
>well.
I want to make resizing (extending only) and snapshot independent to each other,otherwise going back and forth in snapshots may cause the disk shrinked and extended. That would introduce some technical trouble, and possibly confuse user as well.



[-- Attachment #2: Type: text/html, Size: 1397 bytes --]

Re: [Qemu-devel] qcow2 snapshot + resize

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

On 01/05/2016 07:50 PM, lihuiba wrote:
> At 2016-01-05 21:55:56, "Eric Blake" <eblake@redhat.com> wrote:
>> On 01/05/2016 05:10 AM, lihuiba wrote:
>>
>>>>> In our production environment, we need to extend a qcow2 image with
>>>>> snapshots in it.
>>
>>>> The thing is that one would need to update all the inactive L1 tables. I
>>>> don't think it should be too difficult, it's just that apparently so far
>>>> nobody ever had the need for this feature.
>>
>> Is resizing a snapshot really what you want?  Ideally, a snapshot tracks
>> the data from a point in time, including the metadata of the size being
>> tracked at that time.  Extending the snapshots then reverting to that
>> snapshot means your guest would see a larger disk on revert than it did
>> at the time the snapshot was created, which guests might not handle very
>> well.
> I want to make resizing (extending only) and snapshot independent to each other,otherwise going back and forth in snapshots may cause the disk shrinked and extended. That would introduce some technical trouble, and possibly confuse user as well.

If I take a snapshot while the guest sees a 1G disk, then resize the
disk to 2G, then roll back to the point in time of the snapshot, I'd
expect the disk to roll back to 1G in size.  Anything else is likely to
confuse the guest.  And that's what current resize support already does
(it only resizes the active image, not the snapshots).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] qcow2 snapshot + resize

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]

On 06.01.2016 16:04, Eric Blake wrote:
> On 01/05/2016 07:50 PM, lihuiba wrote:
>> At 2016-01-05 21:55:56, "Eric Blake" <eblake@redhat.com> wrote:
>>> On 01/05/2016 05:10 AM, lihuiba wrote:
>>>
>>>>>> In our production environment, we need to extend a qcow2 image with
>>>>>> snapshots in it.
>>>
>>>>> The thing is that one would need to update all the inactive L1 tables. I
>>>>> don't think it should be too difficult, it's just that apparently so far
>>>>> nobody ever had the need for this feature.
>>>
>>> Is resizing a snapshot really what you want?  Ideally, a snapshot tracks
>>> the data from a point in time, including the metadata of the size being
>>> tracked at that time.  Extending the snapshots then reverting to that
>>> snapshot means your guest would see a larger disk on revert than it did
>>> at the time the snapshot was created, which guests might not handle very
>>> well.
>> I want to make resizing (extending only) and snapshot independent to each other,otherwise going back and forth in snapshots may cause the disk shrinked and extended. That would introduce some technical trouble, and possibly confuse user as well.
> 
> If I take a snapshot while the guest sees a 1G disk, then resize the
> disk to 2G, then roll back to the point in time of the snapshot, I'd
> expect the disk to roll back to 1G in size.  Anything else is likely to
> confuse the guest.  And that's what current resize support already does
> (it only resizes the active image, not the snapshots).

No, the current resize operation just refuses to resize the image if it
has any snapshots. Snapshots currently do not store the size of the
image when they were created.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] qcow2 snapshot + resize

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On 01/06/2016 09:20 AM, Max Reitz wrote:

>> If I take a snapshot while the guest sees a 1G disk, then resize the
>> disk to 2G, then roll back to the point in time of the snapshot, I'd
>> expect the disk to roll back to 1G in size.  Anything else is likely to
>> confuse the guest.  And that's what current resize support already does
>> (it only resizes the active image, not the snapshots).
> 
> No, the current resize operation just refuses to resize the image if it
> has any snapshots. Snapshots currently do not store the size of the
> image when they were created.

Huh? I thought that we specifically added bytes 48-55 per snapshot entry
in the qcow2v3 description specifically so that internal snapshots DO
record the size of the image when the snapshot was created.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] qcow2 snapshot + resize

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

On 06.01.2016 17:28, Eric Blake wrote:
> On 01/06/2016 09:20 AM, Max Reitz wrote:
> 
>>> If I take a snapshot while the guest sees a 1G disk, then resize the
>>> disk to 2G, then roll back to the point in time of the snapshot, I'd
>>> expect the disk to roll back to 1G in size.  Anything else is likely to
>>> confuse the guest.  And that's what current resize support already does
>>> (it only resizes the active image, not the snapshots).
>>
>> No, the current resize operation just refuses to resize the image if it
>> has any snapshots. Snapshots currently do not store the size of the
>> image when they were created.
> 
> Huh? I thought that we specifically added bytes 48-55 per snapshot entry
> in the qcow2v3 description specifically so that internal snapshots DO
> record the size of the image when the snapshot was created.

Oh, you're right! Well, then that was probably the intention, yes.
However, resizing an image with snapshots will still fail.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] qcow2 snapshot + resize

[Kevin Wolf]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

Am 06.01.2016 um 17:30 hat Max Reitz geschrieben:
> On 06.01.2016 17:28, Eric Blake wrote:
> > On 01/06/2016 09:20 AM, Max Reitz wrote:
> > 
> >>> If I take a snapshot while the guest sees a 1G disk, then resize the
> >>> disk to 2G, then roll back to the point in time of the snapshot, I'd
> >>> expect the disk to roll back to 1G in size.  Anything else is likely to
> >>> confuse the guest.  And that's what current resize support already does
> >>> (it only resizes the active image, not the snapshots).
> >>
> >> No, the current resize operation just refuses to resize the image if it
> >> has any snapshots. Snapshots currently do not store the size of the
> >> image when they were created.
> > 
> > Huh? I thought that we specifically added bytes 48-55 per snapshot entry
> > in the qcow2v3 description specifically so that internal snapshots DO
> > record the size of the image when the snapshot was created.
> 
> Oh, you're right! Well, then that was probably the intention, yes.
> However, resizing an image with snapshots will still fail.

I guess the only thing that would need to implement something new is
qcow2_snapshot_goto(), which currently refuses to load a snapshot that
has a different disk size.

Once this is done, just removing the check in qcow2_truncate() should be
okay.

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] qcow2 snapshot + resize

[lihuiba]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

>I guess the only thing that would need to implement something new is
>qcow2_snapshot_goto(), which currently refuses to load a snapshot that
>has a different disk size.
>Once this is done, just removing the check in qcow2_truncate() should be
>okay.
Thanks! I'll see what I can do, later.




[-- Attachment #2: Type: text/html, Size: 461 bytes --]

Re: [Qemu-devel] qcow2 snapshot + resize

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On 29.12.2015 10:38, lihuiba wrote:
> Hi,
> 
> In our production environment, we need to extend a qcow2 image with
> snapshots in it. This feature, however, is not implemented yet. 
> 
> So I want to ask, if this feature is under active development?

No, it is not.

> How can I
> help with this feature?

Well, you can implement it. ;-)

> It seems that, this feature is not too difficult as long as cluster_size
> is kept unchanged. Is this correct?

The thing is that one would need to update all the inactive L1 tables. I
don't think it should be too difficult, it's just that apparently so far
nobody ever had the need for this feature.

I can take a look, but I can't say anything about whether or when
anything will come out of it.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Qemu-devel] qcow2 snapshot + resize

[lihuiba]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

Hi,


In our production environment, we need to extend a qcow2 image with snapshots in it. This feature, however, is not implemented yet. 


So I want to ask, if this feature is under active development? How can I help with this feature?


It seems that, this feature is not too difficult as long as cluster_size is kept unchanged. Is this correct?




Thanks!

[-- Attachment #2: Type: text/html, Size: 563 bytes --]