libvirt users - May 2018 - Re: Create qcow2 v3 volumes via libvirt

On 05/01/2018 03:11 PM, Gionatan Danti wrote:
> Il 01-05-2018 10:56 Daniel P. Berrangé ha scritto:
>> qcow2 is widely used in production at large scale in general. Just not
>> with internal snapshots - almost everything uses external snapshots,
>> aka backing file chains.
>>
>> The QEMU community still tends to discourage use of internal snapshots.
>> There are not even any QMP monitor commands to use them - you are
forced
>> to use the legacy HMP interface to QEMU for mgmt. All of the workaround
>> providing interesting block storage mgmt is focused on external
snapshots
>> (aka the backing_file option). There are some technical downsides to
>> internal snapshots IIUC, such as inability to free the space used by
the
>> internal snapshot when it is deleted, loading/saving snapshots blocks
>> execution of the guest OS, and probably more I've forgotten about.
>>
>> The only nice thing about internal snapshots is simplicity of mgmt, and
>> that is a very nice thing indeed, which is why virt-manager has code
>> to support that - it was much easier to add that code for external
>> snapshots. Just a shame about all the downsides :-(
> 
> So internal snapshots remain something very useful for lab/tests, but 
> are not recommended for regular use in production environment, right?
That's fairly accurate.  Also, mixing internal and external snapshots at 
the same time is likely to trigger some known data-loss problems, if you 
are not extremely careful, so for now, just pick one or the other and 
stick to it (I hope to someday enhance qemu to refuse operations that 
would risk data loss, or to perform a slower version of the operation 
with the same result instead of its current fast but wrong 
implementations, when dealing with mixed-internal/external backing chains).

https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg00865.html

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Il 01-05-2018 22:25 Eric Blake ha scritto:
> That's fairly accurate.  Also, mixing internal and external snapshots
> at the same time is likely to trigger some known data-loss problems,
> if you are not extremely careful, so for now, just pick one or the
> other and stick to it (I hope to someday enhance qemu to refuse
> operations that would risk data loss, or to perform a slower version
> of the operation with the same result instead of its current fast but
> wrong implementations, when dealing with mixed-internal/external
> backing chains).
> 
> https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg00865.html
Ok, I think I'll continue to use RAW images + filesystem snapshots + 
external snapshot when required.
It is unfortunate that we have no GUI to manage external snapshots. I 
even remember that external snapshot remove was not supported - I had to 
use the --metadata flag and a plain "rm" to remove them (or using 
--no-metadata in the first place)[1]. Does it remain the current 
behavior?

Thanks.

[1] 
https://www.redhat.com/archives/libvirt-users/2015-September/msg00037.html

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

On 01/05/2018 22:49, Gionatan Danti wrote:
> Ok, I think I'll continue to use RAW images + filesystem snapshots + 
> external snapshot when required.
> It is unfortunate that we have no GUI to manage external snapshots. I 
> even remember that external snapshot remove was not supported - I had to 
> use the --metadata flag and a plain "rm" to remove them (or using
> --no-metadata in the first place)[1]. Does it remain the current behavior?
> 
> Thanks.
> 
> [1] 
> https://www.redhat.com/archives/libvirt-users/2015-September/msg00037.html
Any hope to get virsh external snapshot creation/deletion fixed?
Or, even better, to have virt-manager support for external snapshots?
Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8