Dear all, Sorry for the late response.Here is a simple update for this feature, commited in the branch 'vm-snapshot', feedbacks are welcomed.
[Progress] https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots finish major parts for xenserver/vmware run some simple tests on vmware/xenserver free ediiton/xenserver enterprise edition [ToDo] continue to enhance existing codes especially for exception handling. add capacity/limit/usage related codes unittest/full testing KVM support (TBD, needs patch libvirt java binding) Regards Mice 2012/8/10 Matthew Patton <mpat...@inforelay.com> > On Wed, 08 Aug 2012 21:51:50 -0400, Edison Su <edison...@citrix.com> > wrote: > > From: Mice Xia > [mailto:mice_xia@**tcloudcomputing.com<mice_...@tcloudcomputing.com> >>> ] >>> >> ... > > For following scenarios I need some suggestions: >>> a) 'vm snapshot, detach volume and attach it to another VM, rollback >>> snapshot', >>> >> > This is not a problem. A volume and it's (several) snapshots are described > in the HYPERVISOR's native metadata file closely associated with the > volume. If the hypervisor doesn't actually manage that relationship and > associated housekeeping tasks, CloudStack has no business trying to > implement it. The option is simply not available to the user. > > Cloud automation is NOT about inventing new things, it's about automating > what is currently possible within the capabilities of the particular > hypervisor and storage mixture at hand. Where cloud software goes wrong is > thinking it's the master of everything. It's NOT, and never will be. All > configuration and runtime state must be pulled from the actual devices > (hypervisors, storage arrays, network gear, etc.) because things will > change underneath it. It is unforgivably naive to assume there won't be > outside influence. Of course we'd all like to pretend that the cloud knows > all and that it is always authoritative, but if you write the software > under that assumption, the users will be mighty ticked off when it's not > the case and things break left and right. > > > b) 'vm snapshot, detach and destroy volume, rollback snapshot', >>> >> > That's not a valid operation. A snapshot is ALWAYS associated with it's > parent 'disk'. If you delete the parent, all snapshots are deleted with it. > > > Three candidate solutions that I can figure out now, >>> 1) disallow detach volumes if specified VM has VM snapshots. >>> >> > uh, no. > > > 2) allow to snapshot/rollback, for a), this will result in two volumes, >>> one attached to anther VM, one attached to VM that rollback from >>> snapshot; for >>> >> > This is a matter for the hypervisor or storage array. AFAIK even ESX > doesn't let you do this even if the parent disk is marked RO since it puts > an exclusive lock on the volume. Storage arrays pull this off by > thin-cloning the source so the VM thinks it has it's own disk even when it > didn't start out that way. > > Again, Cloudstack isn't about doing storage trickery. It's about making > the proper calls to the hypervisor or (maybe?) the storage array to do such > fancy cloning. So if you want to provision a VM and attach a particular > volume/snapshot sequence that isn't already locked for use, then no > problem; treat it like you own it outright and launch. Any successive > creation/destruction of snapshots is the purview of that one active VM and > doesn't require any fancy footwork. If on the other hand the source > volume+snapshot is already open for use, then you have to ask the storage > provider for a thick or thin clone and you lose the ability to go back in > time without trashing the private copy and re-attaching/re-cloning to the > original. > > The use case for cloud is 99.95% "dumb". Let's not complicate the > situation unnecessarily. If qcow/rbd/lvm can't do it with their standard > command set, then it's not available. If you're using 3par/emc/netapp as > the storage and they do have the proper calls, then you can permit such > things. Actually, let me rephrase that. Any fancy cloning or snapshotting > calls MUST be sent to the hypervisor only!! It is up to the hypervisor to > issue qcow/rbd/lvm/netapp/emc commands to get it done. Why? Hypervisor > vendors actually test this stuff and have the resources and incentive to > make sure it works. Cloud software again has no business trying to take > over the hypervisor's role. If KVM/Xen are deficient in some aspect, then > fix the hypervisor; do not try to use cloud software to band-aid the matter. > > This early in the CloudStack lifecycle, complicated or exotic operations > should probably require deliberate manual involvement anyhow. > > > For VM based snapshot, we should not allow user to dynamically >> change(attach or detach) VM's disks if there are VM-based snapshot taken on >> this VM. >> > > again, no. It is not up to the cloud to manage/track volume/snapshot > state. It instead queries the hypervisor for that information. > > > It seems to me (admittedly a very new member here) that there is enormous > feature creep being introduced. Cloud automation is really fairly > straightforward. > > for any hypervisor > where is it (IP, logical/physical location) > what flavor (KVM, Xen, ESX) and version - tells us which command set to > use > what network gear is attached and what ports need to be modified for to > add/drop vlan membership at the switch level > what is it's utilization > > for any storage provider > how to interface with it > what storage containers are defined > to which hypervisors should they be attached, and attachment parameters > > for any VM > to which account does it belong > which disks does it need and on what storage container to place them > where to find the master disk templates (if any) > what network bridge/portgroups it needs to have interfaces on > what MAC to assign the various interfaces (or have Hypervisor > auto-assign) > what VLANs to assign to interface or interface aliases > what IP address to assign to the interfaces > are there any locality or performance factors to influence selection of > deployment destination > > Basically all the cloud does is dynamically create what amounts to a > VMware .vmx file or a libvirt instantiation script and run it against the > chosen hypervisor host. And if needed prep the hypervisor with network > underpinnings and attach appropriate storage in order to run the guest. > Yes, I realize I simplified a bit but there isn't a whole lot more to it. >
