On 06/20/2011 04:22 PM, Motonobu Ichimura wrote: >> /* Opaque type to manage a snapshot of a single storage volume. */ >> typedef virStorageVolSnapshotPtr; >> >> > I'm just wondering how to detect storage type and to choose assosiate > shapshot functionality. > Is there any idea about it? I'm not yet convinced we need storage-type-specific functionality; the XML elements can be optional, and if a particular element is not needed by a particular storage driver, then that driver can ignore the element (that is, the point of the snapshot XML on the create API is to provide details like name or description where the default is not good enough, and on dumpxml it will be the minimum xml for what was actually used in creating the snapshot). I believe that libvirt already has code for distinguishing between different storage types (directory vs. block device), and can therefore already tell whether a block device is an LVM partition. It also shouldn't be too hard to tell whether a disk image belongs to a btrfs mount point, for using btrfs copy-on-write cloning (if nothing else, coreutils' cp has already done this, so I have examples to copy from). But I'll probably have to get more familiar with that code as I expand this API beyond qcow2, and it certainly makes sense to consider whether 'virsh vol-info' should be expanded to display information already known by libvirt (whether the volume is file- or block-based; if block-based whether the partition is LVM, and if file-based what file system the containing mount point appears to be). That may indeed involve adding more APIs beyond this proposal, but I think that this proposal will work for 0.9.3 even if such new APIs are delayed until after the release. >> /* Revert a volume back to the state of a snapshot, returning 0 on >> success. Flags is 0 for now. */ >> int virStorageVolRevertToSnapsot(virStorageVolSnapshotPtr snapshot, >> unsigned int flags); >> [For qcow2, this would involve qemu-img snapshot -a. Here, a useful >> flag might be whether to delete any changes made after the point of the >> snapshot; virDomainRevertToSnapshot should probably honor the same type >> of flag.] >> > > For LVM, it may be lvconvert --merge , but requires recent version of lvm > and linux kernel, > So, there are some failure reason (toolchain doesn't support it or toolchain > supports, but failed) > I don't know how to handle these case for now, but we may need to add some > virErrorNumber > to indicate snapshot-related error. Yes, we can add new virError values as we come across situations where such operations are unsupported, but which don't fit well into any existing error values. >> virStorageVolSnapshotCreateXML. [And since my first phase of >> implementation will be focused on inline qcow2 snapshots, I don't yet >> know what that XML will need to contain for any other type of snapshots, >> such as mapping out how the snapshot backing file will be named in >> relation to the possibly new live file.] >> > > In LVM case, taking snapshot(lvcreate) needs at least snapshot volume size > as an argument, > So, I think storage-specific element can be inserted in this XML format Wouldn't the snapshot volume size always be equal to the volume size of the original? Or is there really value in allowing the snapshot size to be configured to something different (and if different, must it always be <= original, or does a larger snapshot than the original make sense)? >> Any feedback on this approach? Any other APIs that would be useful to >> add? I'd like to get all the new APIs in place for 0.9.3 with minimal >> qcow2 functionality, then use the time before 0.9.4 to further enhance >> the APIs to cover more snapshot cases but without having to add any new >> APIs. >> > > LVM snapshot may become invalid in the case of running out the volume size, > So, adding an API for checking whether snapshot is valid will be needed. I'm not quite sure I follow the scenario you are envisioning here. Would you mind stepping through an example (mapping [proposed] libvirt API calls to lvm commands would be helpful), on how an original lvm partition is created, then a snapshot partition, then how you run out of volume size in that snapshot? It sounds like you are saying that there is a way to create an lvm snapshot that is valid at the time that is created, but later on, subsequent actions cause the snapshot to run out of space and no longer be valid. But my understanding is that a snapshot is a constant size (it represents a known state of the disk at a fixed point in time), only the deltas to that snapshot (aka the live disk) ever have the potential to grow beyond the amount of storage used by the snapshot. Or are you worried about creating an lvm snapshot by libvirt, but then a third party program changes the property of the lvm snapshot volume to change its size? -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list