Hi,<br><br>I'm new to this ML, and very interested in this topic.<br>I'm going to  try to implement LVM snapshot feature using this framework.<br><br><div class="gmail_quote"><div>2011/6/16 Eric Blake <span dir="ltr"><<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>></span><br>


<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
/* Opaque type to manage a snapshot of a single storage volume.  */<br>
typedef virStorageVolSnapshotPtr;<br>
<br></blockquote></div><div><br>I'm just wondering how to detect storage type and to choose assosiate shapshot functionality.<br>Is there any idea about it?<br> <br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



<br>
/* Revert a volume back to the state of a snapshot, returning 0 on<br>
success.  Flags is 0 for now.  */<br>
int virStorageVolRevertToSnapsot(virStorageVolSnapshotPtr snapshot,<br>
unsigned int flags);<br>
[For qcow2, this would involve qemu-img snapshot -a.  Here, a useful<br>
flag might be whether to delete any changes made after the point of the<br>
snapshot; virDomainRevertToSnapshot should probably honor the same type<br>
of flag.]<br></blockquote><div> </div></div><div>For LVM, it may be lvconvert --merge , but requires recent version of lvm and linux kernel,<br>So, there are some failure reason (toolchain doesn't support it or toolchain supports, but failed)<br>


I don't know how to handle these case for now, but we may need to add some virErrorNumber <br>to indicate snapshot-related error.<br><br></div><div><div><span>- 元のメッセ・踉札犬鯢拾踉雑 -</span></div>
<div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
<br>
As for the XML changes, it makes sense to snapshot just a subset of<br>
disks when you only care about crash-consistent state or if you can rely<br>
on a guest agent to quiesce the subset of disk(s) you care about, so the<br>
existing <domainsnapshot> element needs a new optional subelement to<br>
control which disks are snapshotted; additionally, this subelement will<br>
be useful for disk image formats that require additional complexity<br>
(such as a secondary file name, rather than the inline snapshot feature<br>
of qcow2).  I'm envisioning something like the following:<br>
<br>
<domainsnapshot><br>
  <name>whatever</name><br>
  <disk name='/path/to/image1' snapshot='no'/><br>
  <disk name='/path/to/image2'><br>
    <volsnapshot>...</volsnapshot><br>
  </disk><br>
</domainsnapshot><br>
<br>
where there can be up to as many <disk> elements as there are disk<br>
<devices> in the domain xml; any domain disk not listed is given default<br>
treatment.  The name attribute of <disk> is mandatory, in order to match<br>
this disk element to one of the domain disks.  The snapshot='yes|no'<br>
attribute is optional, defaulting to yes, in order to skip a particular<br>
disk.  The <volsnapshot> subelement is optional, but if present, it<br>
would be the same XML as is provided to the<br>
virStorageVolSnapshotCreateXML.  [And since my first phase of<br>
implementation will be focused on inline qcow2 snapshots, I don't yet<br>
know what that XML will need to contain for any other type of snapshots,<br>
such as mapping out how the snapshot backing file will be named in<br>
relation to the possibly new live file.]<br></blockquote></div></div><div><br>In LVM case, taking snapshot(lvcreate)  needs at least snapshot volume size as an argument,<br>So, I think storage-specific element can be inserted in this XML format<br>


 </div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Any feedback on this approach?  Any other APIs that would be useful to<br>
add?  I'd like to get all the new APIs in place for 0.9.3 with minimal<br>
qcow2 functionality, then use the time before 0.9.4 to further enhance<br>
the APIs to cover more snapshot cases but without having to add any new<br>
APIs.<font color="#888888"><br></font></blockquote></div><div><br>LVM snapshot may become invalid in the case of running out the volume size,<br>So, adding an  API for checking whether snapshot is valid will be needed.<br>

 <font color="#888888"><br>
Regards,<br></font></div></div>