Hi Yehuda,
So I list a table which describe the VM status and time needed
during rbd snapshot operation:
operation | VM status | time needed
-----------------------------------------------------------------------------------------------------------------------
create | could be running | instant
delete | could be running | instant
rollback | need to be shutdown | needs to go through all the objects
list | could be running | instant
set | need to be shutdown | instant
Could you check this table, hope to get your correction or supplement.
Thx very much!
Simon
2011/6/14 Yehuda Sadeh Weinraub <[email protected]>:
> On Sun, Jun 12, 2011 at 10:43 PM, Simon Tian <[email protected]> wrote:
>> 2011/6/13 Yehuda Sadeh Weinraub <[email protected]>:
>>> Rollback is (currently) is in the order of the number of object of
>>> that image. It needs to go through all the objects and execute an
>>> explicit request of each. For very large images it can be quite long.
>>
>> When a VM is running based on rbd image, and need to rollback to S1.
>> During rollback, seem like that data written by the VM is not allowed?
>> Is there any way to rollback without affecting the user experience of the VM?
>>
> Data written by the vm to the image is not recommended as it'll most
> likely corrupt it. It is recommended that you unmount any relevant
> partition while doing it. Currently there's not much to do to avoid
> the relatively long rollback. We do have on our roadmap the layering
> feature that will allow having some sort of writable snapshots, but
> we're not there yet.
>
> Yehuda
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
