[libvirt] RFC: API additions for enhanced snapshot support

[Motonobu Ichimura]

Hi,

2011年6月21日7:52 Eric Blake <eblake at redhat.com>:

>
> >
> > 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.
>

I understand.


>
> >> 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)?
>

My concern senario is

1.  creaing a snapshot through libvirt,
2.  take a backup from snapshot,
3.  remove a snapshot.

case.

In this case, I think sys-admin may want to create a snapshot size  smaller
than original size.
But this senario seems to make another problem (snapshot becomes invalid,
described below).
so assuming that the snapshot volume size always be equal to the volume size
of
the original is better for us.

>> 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?
>
>
I worried about the case I mensioned above (snapshot size is smaller case)


Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110621/77f02ca1/attachment-0001.htm>