Hi, I'm new to this ML, and very interested in this topic. I'm going to try to implement LVM snapshot feature using this framework. 2011/6/16 Eric Blake <eblake@xxxxxxxxxx> > > > /* 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? > > /* 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. - 元のメッセージを表示 - > > > As for the XML changes, it makes sense to snapshot just a subset of > disks when you only care about crash-consistent state or if you can rely > on a guest agent to quiesce the subset of disk(s) you care about, so the > existing <domainsnapshot> element needs a new optional subelement to > control which disks are snapshotted; additionally, this subelement will > be useful for disk image formats that require additional complexity > (such as a secondary file name, rather than the inline snapshot feature > of qcow2). I'm envisioning something like the following: > > <domainsnapshot> > <name>whatever</name> > <disk name='/path/to/image1' snapshot='no'/> > <disk name='/path/to/image2'> > <volsnapshot>...</volsnapshot> > </disk> > </domainsnapshot> > > where there can be up to as many <disk> elements as there are disk > <devices> in the domain xml; any domain disk not listed is given default > treatment. The name attribute of <disk> is mandatory, in order to match > this disk element to one of the domain disks. The snapshot='yes|no' > attribute is optional, defaulting to yes, in order to skip a particular > disk. The <volsnapshot> subelement is optional, but if present, it > would be the same XML as is provided to the > 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 > > 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. Regards,
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list