I am planning on testing this feature and wanted to know the list of hypervisors that support this feature.
When I refer to the design document - https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots , I see the support being extended for Vmware, Xenserver and KVM. From the discussions in the email thread , I see that KVM implementation has dependencies on libvirt-java and for Xenserver there is dependency on volume snapshot design being improved. Could you please confirm? -Thanks Sangeetha -----Original Message----- From: Wido den Hollander [mailto:w...@widodh.nl] Sent: Monday, February 04, 2013 3:39 AM To: cloudstack-dev@incubator.apache.org Subject: Re: [MERGE] Support VM Snapshot On 02/03/2013 03:09 AM, Mice Xia wrote: > So...it seems there are still some consensus to be reached and the codes were > not merged before 4.1 feature freeze. This will not be in 4.1 release. > That would also give the libvirt guys time to catch up and we can have full support through libvirt-java for 4.2 See these commits: * http://libvirt.org/git/?p=libvirt-java.git;a=commit;h=cd00a4b8f25944f6fe2ce3ecb2ac00cbcad8db8d * http://libvirt.org/git/?p=libvirt-java.git;a=commit;h=23a7750e4470ebce1c5b63b64a26be90057a79ae Wido > -Mice > > -----Original Message----- > From: Mice Xia [mailto:mice_...@tcloudcomputing.com] > Sent: Saturday, February 02, 2013 11:26 AM > To: Alex Huang; Anthony Xu; cloudstack-dev@incubator.apache.org > Subject: RE: [MERGE] Support VM Snapshot > > For now, Volume snapshot and VM snapshot cannot be taken at the same time, > i.e, it will check if there are active volume snapshots tasks when taking a > VM snapshot, and vice versa. > > > > Another way to clear any potential impacts is, making volume snapshot and VM > snapshot totally mutually exclusive, i.e. cannot take one VM snapshot if > there are existing volume snapshots, and vice versa. > > > > Regards > > Mice > > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: Saturday, February 02, 2013 10:57 AM > To: Anthony Xu; Mice Xia; cloudstack-dev@incubator.apache.org > Subject: RE: [MERGE] Support VM Snapshot > > > > Perhaps we should just say XenServer is not supported for VM Snapshot until > the volume snapshot design is fixed? I don’t think KVM and VmWare have this > problem given that it’s full snapshots each time. Although it might have the > same scheduling/locking race condition problems that you’re pointing out. > > > > --Alex > > > > From: Anthony Xu > Sent: Friday, February 01, 2013 5:44 PM > To: 'Mice Xia'; cloudstack-dev@incubator.apache.org; Alex Huang; Mice > Xia > Subject: RE: [MERGE] Support VM Snapshot > > > > I see, snapshot manager detected the change in primary storage, and create a > full snapshot instead, which is supposed to be a delta snapshot. > > It doesn’t break volume snapshot function, but this degrades the volume > snapshot performance. > > > > This is just a simple test, it cannot prove there is no impact to volume > snapshot. > > I’m not sure what will happen if execute these two commands at the same time, > is there any mechanism to sync/serialize these two operation? > > I’m not sure if revert VM has impact to volume snapshot. > > > > For now, it is better to have a global configuration to only choose one. > > later, we may support both of them in one setup. > > > > > > Anthony > > > > > > > > > > From: Mice Xia [mailto:mice_...@tcloudcomputing.com] > Sent: Friday, February 01, 2013 5:30 PM > To: cloudstack-dev@incubator.apache.org; Alex Huang; Mice Xia; Anthony > Xu > Subject: 答复: [MERGE] Support VM Snapshot > > > > Anthony, > > Thanks for your comments. > > Tested on a datadisk with steps you provide on xenserver, all the files > (test1, test2, test3) are present, the function is not affected. > But as i have replied, volume snapshot (s2) is not a delta snapshot, it is a > full one. Users need to be aware of this if they want to use both snapshots > simultaneously. > > Regards > Mice > > > -----Original Message----- > From: Anthony Xu [mailto:xuefei...@citrix.com] > Sent: 2013-2-2 (星期六) 4:05 > To: Alex Huang; Mice Xia; cloudstack-dev@incubator.apache.org > Subject: RE: [MERGE] Support VM Snapshot > > CS uses XenServer delta snapshot, snapshot manager records a VHD chain in > snapshot DB for each volume. VM snapshot creation/revert also operate on > volume snapshot, if snapshot manager doesn't know the VM snapshot , volume > snapshot might be broken. > > > You can try following test, > > 1. create a VM. > 2. create empty file test1 inside this VM. > 3. create a volume snapshot(s1) > 4. create empty file test2 inside this VM 5. create a VM snapshot (vm1) 6. > create empty file test3 inside this VM 7. create a volume snapshot (s2) 8. > create a volume from snapshot (s2) 9. attach this volume to a VM 10. if one > of test1, test2, test3 is missing in this volume, might mean volume snapshot > is broken. > > > It might be difficult to support both VM snapshot and volume snapshot in the > same time for hypervisor which supports delta snapshot. > Maybe we need to provide a zone level configuration for it, only one is > supported in a zone, volume snapshot or vm snapshot. > > > > Anthony > > > > > >> -----Original Message----- >> From: Alex Huang >> Sent: Friday, February 01, 2013 10:54 AM >> To: Mice Xia; cloudstack-dev@incubator.apache.org >> Cc: Anthony Xu >> Subject: RE: [MERGE] Support VM Snapshot >> >> Mice, >> >> Thanks! >> >> Anthony, >> >> Can you comment on whether VM Snapshot breaks volume snapshot? >> >> --Alex >> >>> -----Original Message----- >>> From: Mice Xia [mailto:weiran.x...@gmail.com] >>> Sent: Friday, February 01, 2013 8:53 AM >>> To: cloudstack-dev@incubator.apache.org; Alex Huang >>> Subject: Re: [MERGE] Support VM Snapshot >>> >>> as Alex suggested >>> updated vm-snapshot branch, commit ebca6890fd >>> >>> 1. remove snapshotting/revertting state from VM state machine >>> 2 prevent VM state change if there are active vm snapshot tasks >>> 3 change VMSnapshotService interface, except for ListVMSnapshotCmd, >>> need some time to replace it in QueryService, maybe after merging to >>> master >>> 4 remove unused methods and fix some typos >>> >>> Regards >>> Mice >>> >>> 2013/2/1 Mice Xia <mice_...@tcloudcomputing.com>: >>>> Hi, Alex, >>>> >>>> Thanks for your feedbacks, please see my comments inline. >>>> >>>> - VM states is designed for VM lifecycle. Snapshot is not part of >> VM life >>> cycle so therefore the state should not be there. I think it make >> sense to add >>> attributes to VM that says "Do Not Change State" and who changed >>> the >> VM >>> to that state. Then virtualmachinemanager must obey that until the >> external >>> caller changes the attribute to now you can change state. The would >> make >>> more sense and decouples snapshotting from vm lifecycle management. >>> Snapshotting then has it's own state (which I see it does already). >> If we want >>> to reflect that a vm snapshot is being taken of a VM, that's a >> function of the >>> apiresponse module that gathers up everything about a vm but it >> shouldn't >>> be changed in the vm states. >>>> >>>> [mice] the reason that I added snapshotting/reverting state is that >> VM >>> could be in suspend/pause state during snapshoting/reverting, which >> is >>> difficult to be categorized into existing states; and during the >> process, VM >>> should not be allowed to take any operations; and by adding new >> states to >>> VM, the implementation seems more 'natural' and only minimum codes >> are >>> changed to virtualmachinemanager. >>>> Of course there are some other ways to prevent operations, such as >> check >>> if associated snapshots are in snapshotting/reverting states either >> in each >>> method (start/stop/migrate/delete...) or hook stateTransitTo(), but >> in this >>> way, it does not reflect VM's real state in hypervisor and more >> existing codes >>> will be touched. >>>> >>>> - Does VM Revert operation work in the following way: Stop VM, >> restore >>> to snapshot, and run VM? Shouldn't this be orchestration inside >> snapshot >>> manager? >>>> >>>> [mice] if a running VM is reverted to a memory enabled snapshot, >> current >>> implementation is running--> reverting-->running >>>> If a stopped VM is reverted to memory disabled snapshot: stopped-- >>>> reverting->stopped >>>> If a running VM is reverted to a memory disabled snapshot: >>>> running- >> -(Stop >>> VM)-->stopped-->reverting--> stopped >>>> If a stopped VM is reverted to a memory enabled snapshot: >>>> stopped-- >>> (Start VM)-->running->reverting-->running >>>> >>>> These logics are implemented in snapshot manager. >>>> >>>> - Does VM snapshot interfere with volume snapshot? Volume snapshot >>> today makes the assumption that it is the only code that's making >> snapshots >>> and can break if there are additional snapshots in between. This is >> bad >>> design in volume snapshot but unfortunately that's how it's design. >>>> >>>> [mice] about volume snapshot, for xensever, if parent VHD cannot be >>> found, it will take a full volume snapshot (this indeed break >>> current semantics but it still works) >>>> For vmware, the volume snapshot is always a full one. >>>> >>>> - VMSnapshotService follows the other services in passing the cmds >> to the >>> service. That's really a bad practice that we should stop. Cmds >>> are >> really >>> translations between over-the-wire api and java interface. They >> shouldn't >>> have been passed to down to the java interface. >>>> [ >>>> mice] I'll change it >>>> >>>> A small note: Would it be better to call it VM restore than VM >> revert? >>> Revert really should be RevertTo which I think is in the code but is >> not >>> consistent. Some places it's just REVERT (for example, the event is >> just >>> revert). >>>> >>>> [mice] there is already RESTORE, which is restoring a destroyed VM >> to >>> stopped. RevertTo is fine with me. >>>> >>>> -Mice >>>> >>>> >>>> -----Original Message----- >>>> From: Alex Huang [mailto:alex.hu...@citrix.com] >>>> Sent: Friday, February 01, 2013 9:24 AM >>>> To: CloudStack DeveloperList >>>> Cc: Mice Xia >>>> Subject: RE: [MERGE] Support VM Snapshot >>>> >>>> Hi Mice, >>>> >>>> Sorry it took so long to review this. Wanted to as soon as I saw >> it on the list >>> but was sick and didn't get a chance. In general, I think the code >> is excellent. >>> I'm impressed how much Cloudstack internal code in touch and how >>> comfortable the changes look. Nicely done! >>>> >>>> I have a few comments: >>>> - VM states is designed for VM lifecycle. Snapshot is not part of >> VM life >>> cycle so therefore the state should not be there. I think it make >> sense to add >>> attributes to VM that says "Do Not Change State" and who changed >>> the >> VM >>> to that state. Then virtualmachinemanager must obey that until the >> external >>> caller changes the attribute to now you can change state. The would >> make >>> more sense and decouples snapshotting from vm lifecycle management. >>> Snapshotting then has it's own state (which I see it does already). >> If we want >>> to reflect that a vm snapshot is being taken of a VM, that's a >> function of the >>> apiresponse module that gathers up everything about a vm but it >> shouldn't >>> be changed in the vm states. >>>> - Does VM Revert operation work in the following way: Stop VM, >> restore >>> to snapshot, and run VM? Shouldn't this be orchestration inside >> snapshot >>> manager? >>>> - Does VM snapshot interfere with volume snapshot? Volume snapshot >>> today makes the assumption that it is the only code that's making >> snapshots >>> and can break if there are additional snapshots in between. This is >> bad >>> design in volume snapshot but unfortunately that's how it's design. >>>> - VMSnapshotService follows the other services in passing the cmds >> to the >>> service. That's really a bad practice that we should stop. Cmds >>> are >> really >>> translations between over-the-wire api and java interface. They >> shouldn't >>> have been passed to down to the java interface. >>>> >>>> A small note: Would it be better to call it VM restore than VM >> revert? >>> Revert really should be RevertTo which I think is in the code but is >> not >>> consistent. Some places it's just REVERT (for example, the event is >> just >>> revert). >>>> >>>> --Alex >>>> >>>>> -----Original Message----- >>>>> From: Chiradeep Vittal >>>>> Sent: Wednesday, January 30, 2013 4:44 PM >>>>> To: CloudStack DeveloperList >>>>> Cc: Alex Huang >>>>> Subject: Re: [MERGE] Support VM Snapshot >>>>> >>>>> Can we get Alex to review this? He is the designer of the state >> machine. >>>>> >>>>> On 1/30/13 5:26 AM, "Murali Reddy" <murali.re...@citrix.com> wrote: >>>>> >>>>>> On 30/01/13 2:24 PM, "Mice Xia" <mice_...@tcloudcomputing.com> >>> wrote: >>>>>> >>>>>>> Agreed. >>>>>>> Adding VM states are likely to have some side-effects, but for >>>>>>> moveVMToUser case, does it explicitly reject other transient >> states >>>>>>> such as stating/stopping/migrating? >>>>>>> >>>>>>> -Mice >>>>>> >>>>>> No, it just accepts any state other than 'Running' (though it >> should >>>>>> have checked for the valid states in which VM can move to other >> user). >>>>>> >>>>>> I am just saying, there could such VM state based assumptions, >> you >>>>>> might want to check. >>>>>> >>>> >
