On 05/18/2014 07:59 PM, Thomas wrote:> Hello,
>
> I have a running transient domain with a storage volume that utilizes a
> backing file (both QCOW2 format).
>
> I'd like to capture the disk and memory state of the domain preferably
to
> external file(s) (which I understand is an 'external checkpoint'),
so that
> other independent domains can be instantiated and effectively
"resumed"
> from this point-in-time profile.
>
> My network configuration is such that domains are network-isolated at L2,
> so resolving MAC/IP address and similar conflicts within the guest are not
> of concern.
I hope you are also considering other effects. For example, running two
different guests starting from the same point in time means that both
guests share the same random pool seeds - an attacker observing the
random stream from one guest may be able to compromise the second guest.
In other words, you ABSOLUTELY must ensure that the two different
guests are COMPLETELY isolated, and that your clone is never operated in
a way that can be accessed by whatever can access the original.
On this list, we strongly recommend that you stick to offline cloning,
coupled with the virt-sysprep tool from libguestfs, to ensure that your
clones have been scrubbed to avoid unintended effects from running two
different guests from the same point in time of disk state.
>
> Is it possible to accomplish this? I've looked at both the
> snapshot/checkpoint and migration APIs and it appears as though the pieces
> are there, but am having difficulty defining the proper workflow.
>
> For instance, an external online checkpoint can be created using
> virDomainSnapshotCreateXML, but is it possible to disassociate the snapshot
> from the source domain (effectively returning it to its pre-snapshot state)
> and at a later time instantiate new domains using the the disk/memory data
> from the snapshot files?
>
> Any recommendations, insight, or guidance is appreciated.
By "returning [the original] to its pre-snapshot state", are you
talking
about collapsing a backing chain back into fewer files? Although this
is still a work in progress (for example, I'm currently working on
patches to make libvirt support 'active commit' that was added in qemu
2.0), there are indeed sequences you can perform given current libvirt
capabilities for shortening a backing chain of a running domain, to make
it appear as though the external snapshot had never been taken. This
list has had several threads on the topic in the past; or, if you can
demonstrate an actual scenario, I can help come up with the commands.
For example, going from 'base <- snap1 <- active' to 'base
<- active'
can be done with either 'virsh blockcommit' (commit snap1 into base;
snap1 is invalidated) or 'virsh blockpull' (pull snap1 into active;
snap1 is no longer part of the chain but still remains a valid point in
time for other uses).
Furthermore, it should be possible to use 'virsh save-image-edit' to
modify a memory image to behave as if it belonged to a different domain
name, in order to start up a new domain from the existing saved state
(although to be honest, I have not tried it, given my preference for
offline cloning).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org