2011年6月21日7:52 Eric Blake <eblake@xxxxxxxxxx>:
I understand.
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.
I worried about the case I mensioned above (snapshot size is smaller case)
Regards,
>Yes, we can add new virError values as we come across situations where
> 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.
such operations are unsupported, but which don't fit well into any
existing error values.
I understand.
Wouldn't the snapshot volume size always be equal to the volume size of
>> 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
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 toI'm not quite sure I follow the scenario you are envisioning here.
>> 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.
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,
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list