Thanks Wido. So we will not include KVM in the scope for now. Can someone confirm the support for Xenserver?
-Thanks Sangeetha -----Original Message----- From: Wido den Hollander [mailto:w...@widodh.nl] Sent: Wednesday, February 13, 2013 5:35 AM To: cloudstack-dev@incubator.apache.org Subject: Re: [MERGE] Support VM Snapshot On 02/13/2013 01:44 AM, Sangeetha Hariharan wrote: > 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. > For KVM that is correct. The patches are in upstream libvirt-java, but no release is out there with the patches in it. Wido > 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=cd00a4b8f25944f6 > fe2ce3ecb2ac00cbcad8db8d > * > http://libvirt.org/git/?p=libvirt-java.git;a=commit;h=23a7750e4470ebce > 1c5b63b64a26be90057a79ae > > 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. >>>>>>> >>>>> >> >
