Re: RFCv2: virDomainSnapshotCreateXML enhancements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/10/2011 04:08 PM, Eric Blake wrote:
The <disks> element has an optional number of <disk> subelements; at
most one per <disk> in the <devices> section of <domain>. Each <disk>
element has a mandatory attribute name='name', which must match the
<target dev='name'/> of the <domain> xml, as a way of getting 1:1
correspondence between domainsnapshot/disks/disk and domain/devices/disk
while using names that should already be unique. Each <disk> also has an
optional snapshot='no|internal|external' attribute, similar to the
proposal for <domain>/<devices>/<disk>; if not provided, the attribute
defaults to the one from the <domain>. If snapshot=external, then there
may be an optional subelement <source file='path'/>, which gives the
desired new file name. If external is requested, but the <source>
subelement is not present, then libvirt will generate a suitable
filename, probably by concatenating the existing name with the snapshot
name, and remembering that the snapshot name is generated as a timestamp
if not specified. Also, for external snapshots, the <disk> element may
have an optional sub-element specifying the driver (useful for selecting
qcow2 vs. qed in the qemu 'snapshot_blkdev' monitor command); again,
this can normally be generated by default.

I realized I never had an example of this last sentence, and almost omitted it from my xml parser. It will look like:

<domainsnapshot>
  <disks>
    <disk name='vda'>
      <driver type='qcow2'/>
      <source file='path'/>
    </disk>
  </disks>
</domainsnapshot>

Quick Summary
=============

Status update: more than a week later, and patches have been flying - I'm now at patch 34/26 in my v2 series (don't you love it when a patch series grows after the first send?), not counting some of the other prereq patches I have submitted and pushed in the meantime.

https://www.redhat.com/archives/libvir-list/2011-August/msg00620.html

Anyone up for code reviews?  :)

For convenience, I've pushed things to my git repo, so you can:

git fetch git://repo.or.cz/libvirt/ericb.git snapshot

or browse online at:

http://repo.or.cz/w/libvirt/ericb.git/shortlog/refs/heads/snapshot


These are the changes I plan on making soon; I mentioned other possible
future changes above that would depend on these being complete first, or
which involve creation of new API.

The following API patterns currently "succeed", but risk data loss or
other bugs that can get libvirt into an inconsistent state; they will
now fail by default:

virDomainRevertToSnapshot to go from a running VM to a stopped
checkpoint will now fail by default. Justification: stopping a running
domain is a form of data loss. Mitigation: use
VIR_DOMAIN_SNAPSHOT_REVERT_FORCE for old behavior.

Still needs to be implemented.


virDomainRevertToSnapshot to go from a running VM to a live checkpoint
with an ABI-incompatible <domain> will now fail by default.
Justification: qemu does not handle ABI incompatibilities, and even if
the 'loadvm' may have succeeded, this generally resulted in fullscale
guest corruption. Mitigation: use VIR_DOMAIN_SNAPSHOT_REVERT_FORCE to
start a new qemu process that properly conforms to the snapshot's ABI.

ABI incompatibilities are detected, but VIR_DOMAIN_SNAPSHOT_REVERT_FORCE still needs to be implemented.


virDomainUndefine will now fail to undefine a domain with any snapshots.
Justification: leaving behind libvirt metadata can corrupt future
defines, comparable to recent managed save changes, plus it is a form of
data loss. Mitigation: use virDomainUndefineFlags.

Done.


virDomainUndefineFlags will now default to failing an undefine of a
domain with any snapshots. Justification: leaving behind libvirt
metadata can corrupt future defines, comparable to recent managed save
changes, plus it is a form of data loss. Mitigation: separately delete
all snapshots (or at least all snapshot metadata) first, or use
VIR_DOMAIN_UNDEFINE_SNAPSHOTS.

Done.


virDomainMigrate/virDomainMigrate2 will now default to fail if the
source has any snapshots. Justification: metadata must be transferred
along with the domain for the migration to be complete. Mitigation:
until an improved migration protocol can automatically do the
handshaking necessary to migrate all the snapshot metadata, a user can
manually loop over each snapshot prior to migration, using
virDomainSnapshotCreateXML with VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE on
the destination, then virDomainSnapshotDelete with
VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY on the source.

Migration is forbidden with snapshots, but VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE still needs to be implemented.


Add the following XML:
in <domain>/<devices>/<disk>:
add optional attribute snapshot='no|internal|external'
add optional attribute persistent='yes|no'

XML parsing done (persistent='yes|no' got renamed to an optional sub-element <transient/>). Qemu support for <transient/> is missing.

in <domainsnapshot>:
expand <domainsnapshot>/<domain> to be full domain, not just uuid

Done.

add <state>disk-snapshot</state>

Done.

add optional <disks>/<disk>, where each <disk> maps back to
<domain>/<devices>/<disk> and controls how to do external disk snapshots

XML parsing done, but no hypervisor is yet taking advantage of the new domain_conf fields.


Add the following flags to existing API:

virDomainSnapshotCreateXML:
VIR_DOMAIN_SNAPSHOT_CREATE_HALT

Done.

VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY

Not done - next on my list (and nearly there!)

VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE

Not done, further out.


virDomainSnapshotGetXMLDesc
VIR_DOMAIN_XML_SECURE

Done.


virDomainRevertToSnapshot
VIR_DOMAIN_SNAPSHOT_REVERT_START
VIR_DOMAIN_SNAPSHOT_REVERT_PAUSE
VIR_DOMAIN_SNAPSHOT_REVERT_FORCE

Not done.

VIR_DOMAIN_SNAPSHOT_REVERT_DELETE_CHILDREN
VIR_DOMAIN_SNAPSHOT_REVERT_DISCARD

Done.


virDomainSnapshotDelete
VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY
VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY

Done.


virDomainUndefineFlags
VIR_DOMAIN_UNDEFINE_SNAPSHOTS

Done.

--
Eric Blake   eblake@xxxxxxxxxx    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]