On 6/10/19 5:47 PM, Gary Dale wrote: >>> >>> Since blockcommit would make it impossible for me to revert to an >>> earlier state (because I'm committing the oldest snapshot, if it screws >>> up, I can't undo within virsh), I need to make sure this command is >>> correct. >>> >>> > Interesting. Your comments are quite different from what the Redhat It's "Red Hat", two words :) > online documentation suggests. It spends some time talking about > flattening the chains (e.g. > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_administration_guide/sub-sect-domain_commands-using_blockcommit_to_shorten_a_backing_chain) That is all about external snapshot file chains (Red Hat specifically discourages the use of internal snapshots). > while you are saying the chains don't exist. I gather this is because > Redhat doesn't like internal snapshots, so they focus purely on > documenting external ones. > > It does strike me as a little bizarre to handle internal and external > snapshots differently since the essential difference only seems to be > where the data is stored. Using chains for one and reference counts for > the other sounds like a recipe for for things not working right. If nothing else, it's a reason WHY Red Hat discourages the use of internal snapshots. > > Anyway, if I understand what you are saying, with internal snapshots, i > can simply delete old ones and create new ones without worrying about > there being any performance penalty. All internal snapshots are one hop > away from the base image. Still not quite right. All internal snapshots ARE a complete base image, they do not track a delta from any other point in time, but rather the complete disk contents of the point in time in question. Yes, you can delete internal snapshots at will, because nothing else depends on them. We don't yet have good code for compacting unused portions of a qcow2 image, though, so your file size may still appear larger than necessary (hopefully it's sparse, though, so not actually consuming extra storage). Also, don't try to mix-and-match internal and external snapshots on a single guest image - once you've used one style, trying to switch to the other can cause data loss if you aren't precise about which files require which clusters to stick around. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature