[libvirt-users] Help with understanding and solving snapshot problem

[Eric Blake]

On 04/10/2014 04:38 PM, rolf wrote:

>> [Can you convince your mailer to wrap long lines?  It makes it easier
>> for other readers]
> 
> I’ll try and keep the lines short. I don’t see any obvious setting to change the wrap.

Thanks for being accommodating; this was indeed easier to read (alas,
many web mailers these days lack settings for automatic wrap, so I end
up whacking the Enter key for manual wrap when I'm forced to use a web
mail interface for sending to a technical list)


>>> # virsh snapshot-info host1 --current
>>> Name:           snap1-host1
>>> Domain:         host1
>>> Current:        yes
>>> State:          shutoff
>>> Location:       internal
>>

> # virsh snapshot-dumpxml host1 snap1-host1
> <domainsnapshot>
>   <name>snap1-host1</name>
>   <description>After install completed</description>
>   <state>shutoff</state>
>   <creationTime>1390111150</creationTime>
>   <memory snapshot='no'/>
>   <disks>
>     <disk name='vda' snapshot='external'>

Okay, we've definitely demonstrated a bug in at least 'virsh
snapshot-list' for that particular build of libvirt; this proves that
the snapshot is definitely external, even though the info output claimed
it was internal.  I didn't search whether a bugzilla entry was already
tracking this for RHEL 6.5; it's not a crasher, so it probably won't get
fixed until RHEL 6.6.  If you'd like, you can open a BZ, (it might get
closed as a dup if someone else finds where it was already reported,
even though I didn't do that search), to make sure it doesn't get lost.

Meanwhile, creating external snapshots is supported in that version of
RHEL, but not deleting (at least not via virsh directly), so you'll have
to get your hands a bit dirty with qemu-img and virsh edit.

>       <driver type='qcow2'/>
>       <source file='/var/lib/libvirt/snap1-host1.qcow2'/>

This says that snap1-host1.qcow2 is the wrapper file created at the time
of the snapshot, and that...

>     </disk>
>     <disk name='vdb' snapshot='external'>
>       <driver type='qcow2'/>
>       <source file='/var/lib/libvirt/snap1-host1-db.qcow2'/>
>     </disk>
>     <disk name='hdc' snapshot='no'/>
>   </disks>
>   <domain type='kvm'>
...
>     <devices>
>       <emulator>/usr/libexec/qemu-kvm</emulator>
>       <disk type='file' device='disk'>
>         <driver name='qemu' type='raw' cache='none'/>
>         <source file='/var/lib/libvirt/images/host1.img'/>

it should have a backing file of /var/lib/libvirt/images/host1.img.
Wonder why your 'qemu-img info' output didn't show that fact?

>>
>> I don't quite have a full picture of how you got into the situation.  If
>> you are trying to just get rid of the snapshot, you could always try
>> 'virsh snapshot-delete --metadata host1 snap1-host1', to make libvirt
>> forget about the snapshot without cleaning up any actual data (leaving
>> any external backing chains intact, and not removing internal snapshots
>> from qcow2 files).
> 
> ok. What implications does this have long term?
> Is there then a related step to remove the data of the snapshot that is no longer referenced?
> Reclaiming the space would be handy.

Are you trying to revert to that state, or just forget that you ever
took the snapshot?  Are you okay keeping the two files as a backing
chain, or do you want to collapse it into one?  And if you DO want to
collapse into one file (so you can delete the other), do you want the
kept file to be snap1-host1.qcow2 (do a blockpull operation) or
host1.img (do a commit operation)?


> 
> And as before, given the structure of the VM and its two disks, how is a snapshot created
> excluding the second disk? vdb in the above xml output?

If you create the snapshot via command line, 'virsh snapshot-create-as
host1 --name ... --diskspec vda,file=/path/for/disk --diskspec
vdb,snapshot=no' should be sufficient to exclude vdb from the snapshot
(you can use the --print-xml option to see what those options would
actually pass to the virDomainSnapshotCreateXML command).

> 
> Many thanks for your help so far.

Glad to hear it, and hope we can continue to be helpful.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20140410/6c2bc055/attachment.sig>