You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Mice Xia <mi...@tcloudcomputing.com> on 2013/02/02 02:30:19 UTC
答复: [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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com> wrote:
> > >>
> > >> >On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
> > >> >
> > >
RE: [MERGE] Support VM Snapshot
Posted by Animesh Chaturvedi <an...@citrix.com>.
Mice can you review and respond to my comment below
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Thursday, March 07, 2013 5:54 PM
> To: cloudstack-dev@incubator.apache.org; 'Mice Xia'; Alex Huang; Mice Xia
> Cc: Sangeetha Hariharan
> Subject: RE: [MERGE] Support VM Snapshot
>
> Folks following up on this thread looks like support for XenServer is still not
> settled.
>
> 1. Mice can we make the feature configurable for each hypervisor to
> enable/disable the feature
2. Test the feature with XenServer thoroughly to
> check if Volume Snapshot is affected / degraded
>
> Thanks
> Animesh
>
>
> > -----Original Message-----
> > From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com>
> > wrote:
> > > > >>
> > > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> <mi...@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.
> > > > >> >
> > > > >
RE: [MERGE] Support VM Snapshot
Posted by Alex Huang <Al...@citrix.com>.
Anthony needs to make sure this doesn't break delta snapshot for XS.
--Alex
> -----Original Message-----
> From: Animesh Chaturvedi
> Sent: Thursday, March 7, 2013 5:54 PM
> To: cloudstack-dev@incubator.apache.org; 'Mice Xia'; Alex Huang; Mice Xia
> Cc: Sangeetha Hariharan
> Subject: RE: [MERGE] Support VM Snapshot
>
> Folks following up on this thread looks like support for XenServer is still not
> settled.
>
> 1. Mice can we make the feature configurable for each hypervisor to
> enable/disable the feature 2. Test the feature with XenServer thoroughly to
> check if Volume Snapshot is affected / degraded
>
> Thanks
> Animesh
>
>
> > -----Original Message-----
> > From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com>
> > wrote:
> > > > >>
> > > > >> >On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
> > > > >> >
> > > > >
RE: [MERGE] Support VM Snapshot
Posted by Mice Xia <mi...@tcloudcomputing.com>.
Hi, Chandan,
Not sure if you can see the screenshot,
in Xencenter, click a primary storage, click [Storage] on the right side, in the Virtual Disks list you can see the snapshot disk and snapshot memory image.
Regards
Mice
-----Original Message-----
From: Chandan Purushothama [mailto:Chandan.Purushothama@citrix.com]
Sent: Saturday, March 23, 2013 4:29 AM
To: Animesh Chaturvedi; Mice Xia; cloudstack-dev@incubator.apache.org
Cc: Anthony Xu; Hari Kannan
Subject: RE: [MERGE] Support VM Snapshot
Hello Mice,
I asked the following question on the community already. Since the following thread is active, I am reposting the question again in this email thread for answers that will help me work with the feature on XenServer,
Thank you,
Chandan.
-----Original Message-----
From: Chandan Purushothama [mailto:Chandan.Purushothama@citrix.com <ma...@citrix.com> ]
Sent: Tuesday, March 19, 2013 4:36 PM
To: cloudstack-dev@incubator.apache.org <ma...@incubator.apache.org>
Subject: Question pertaining to VMSnapshot Feature on XenServer
As per the Feature's Functional Specification Document at https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots <https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots> , I understand that the VMSnapshots are saved in the primary storage. I could observe this in the VMWare Setup. But I am unable to observe the presence of the VMsnapshots on a primary storage in a XenServer Setup. May I know where can I find the VMSnapshots in the case of XenServer,
Thank you,
Chandan.
-----Original Message-----
From: Animesh Chaturvedi
Sent: Thursday, March 21, 2013 2:09 PM
To: Mice Xia; cloudstack-dev@incubator.apache.org <ma...@incubator.apache.org>
Cc: Chandan Purushothama; Anthony Xu; Hari Kannan
Subject: RE: [MERGE] Support VM Snapshot
That's good, thanks for your response.
> -----Original Message-----
> From: Mice Xia [mailto:mice_xia@tcloudcomputing.com <ma...@tcloudcomputing.com> ]
> Sent: Wednesday, March 20, 2013 11:29 PM
> To: cloudstack-dev@incubator.apache.org <ma...@incubator.apache.org> ; Animesh Chaturvedi
> Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> Subject: RE: [MERGE] Support VM Snapshot
>
> I'd like to a hypervisor_capabilities based solution.
> The earliest time that I can start changing it is next week. I haven’t
> investigated the solution, let's roughly suppose this could be done
> before mid April.
>
> -Mice
>
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com <ma...@citrix.com> ]
> Sent: Thursday, March 21, 2013 12:58 AM
> To: cloudstack-dev@incubator.apache.org <ma...@incubator.apache.org>
> Cc: Chandan Purushothama; Anthony Xu
> Subject: RE: [MERGE] Support VM Snapshot
>
> Mice any updates, when can you provide a global enable/disable flag
> for the feature?
>
> Animesh
>
> > -----Original Message-----
> > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com <ma...@citrix.com> ]
> > Sent: Monday, March 18, 2013 10:44 PM
> > To: cloudstack-dev@incubator.apache.org <ma...@incubator.apache.org>
> > Cc: Chandan Purushothama; Anthony Xu
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > It would be best to enable/disable this feature on a per hypervisor
> > basis but if that's complicated adding a top level flag to
> > enable/disable the functionality is reasonable.
> >
> > > -----Original Message-----
> > > From: Mice Xia [mailto:mice_xia@tcloudcomputing.com <ma...@tcloudcomputing.com> ]
> > > Sent: Monday, March 18, 2013 9:59 PM
> > > To: cloudstack-dev@incubator.apache.org <ma...@incubator.apache.org>
> > > Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > Animesh,
> > >
> > > Do you mean limit the capability by adding global configurations
> > > or adding in [global-setting--> hypervisor capabilities] ?
> > >
> > > Mice
> > >
> > > -----Original Message-----
> > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com <ma...@citrix.com> ]
> > > Sent: Tuesday, March 19, 2013 9:47 AM
> > > To: cloudstack-dev@incubator.apache.org <ma...@incubator.apache.org> ; Mice Xia; Chandan
> > > Purushothama; Anthony Xu
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > Mice any comments to my email below.
> > >
> > > Animesh
> > >
> > > > -----Original Message-----
> > > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com <ma...@citrix.com> ]
> > > > Sent: Wednesday, March 13, 2013 6:03 PM
> > > > To: Mice Xia; cloudstack-dev@incubator.apache.org <ma...@incubator.apache.org> ; Chandan
> > > > Purushothama; Anthony Xu
> > > > Subject: RE: [MERGE] Support VM Snapshot
> > > >
> > > > Mice please see concerns from Anthony on Xenserver support., I
> > > > guess they can only be proved conclusively by testing with xenserver.
> > > > Chandan will test with xenserver.
> > > >
> > > > But given that there is some doubt on full support for xenserver
> > > > and kvm dependency on libvirt-java binding and I assume the
> > > > effort in making the capability configurable is trivial. In my
> > > > opinion we should make it configurable and turn on for xenserver
> > > > and kvm when support is
> > > clear.
> > > >
> > > >
> > > > Thanks
> > > > Animesh
> > > > > -----Original Message-----
> > > > > From: Mice Xia [mailto:weiran.xia1@gmail.com <ma...@gmail.com> ]
> > > > > Sent: Monday, March 11, 2013 2:49 AM
> > > > > To: cloudstack-dev@incubator.apache.org <ma...@incubator.apache.org>
> > > > > Cc: Animesh Chaturvedi
> > > > > Subject: Re: [MERGE] Support VM Snapshot
> > > > >
> > > > > Animesh,
> > > > >
> > > > > sorry for the late reply.
> > > > >
> > > > > 1. currently in master branch it supports both xenserver and
> > > > > vmware, for KVM it needs a new-versioned libvirt java binding,
> > > > > considering it's for 4.2, still three months away from the
> > > > > release date, we have big chance to ship the new libvirt
> > > > > binding. I dont see a strong need to make it configurable for
> > > > > hypervisors unless some functions do not work
> > > > at all..
> > > > >
> > > > > 2. now delta volume snapshot will become a full one. But I
> > > > > guess volume snapshot will be improved soon for xenserver.
> > > > > please correct me if we dont have this plan.
> > > > >
> > > > > Regards
> > > > > -Mice
> > > > >
> > > > > 2013/3/8 Animesh Chaturvedi <animesh.chaturvedi@citrix.com <ma...@citrix.com> >:
> > > > > > Folks following up on this thread looks like support for
> > > > > > XenServer is still not
> > > > > settled.
> > > > > >
> > > > > > 1. Mice can we make the feature configurable for each
> > > > > > hypervisor to enable/disable the feature 2. Test the feature
> > > > > > with XenServer thoroughly to check if Volume Snapshot is
> > > > > > affected / degraded
> > > > > >
> > > > > > Thanks
> > > > > > Animesh
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com <ma...@citrix.com> ]
> > > > > >> Sent: Friday, February 01, 2013 5:44 PM
> > > > > >> To: 'Mice Xia'; cloudstack-dev@incubator.apache.org <ma...@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_xia@tcloudcomputing.com <ma...@tcloudcomputing.com> ]
> > > > > >> Sent: Friday, February 01, 2013 5:30 PM
> > > > > >> To: cloudstack-dev@incubator.apache.org <ma...@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.Xu@citrix.com <ma...@citrix.com> ]
> > > > > >> Sent: 2013-2-2 (星期六) 4:05
> > > > > >> To: Alex Huang; Mice Xia;
> > > > > >> cloudstack-dev@incubator.apache.org <ma...@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 <ma...@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.xia1@gmail.com <ma...@gmail.com> ]
> > > > > >> > > Sent: Friday, February 01, 2013 8:53 AM
> > > > > >> > > To: cloudstack-dev@incubator.apache.org <ma...@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_xia@tcloudcomputing.com <ma...@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.Huang@citrix.com <ma...@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.Reddy@citrix.com <ma...@citrix.com> >
> > > > > >> wrote:
> > > > > >> > > >>
> > > > > >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> > > > > >> > > >> ><mice_xia@tcloudcomputing.com <ma...@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.
> > > > > >> > > >> >
> > > > > >> > > >
> > > > > >
RE: [MERGE] Support VM Snapshot
Posted by Chandan Purushothama <Ch...@citrix.com>.
Hello Mice,
I asked the following question on the community already. Since the following thread is active, I am reposting the question again in this email thread for answers that will help me work with the feature on XenServer,
Thank you,
Chandan.
-----Original Message-----
From: Chandan Purushothama [mailto:Chandan.Purushothama@citrix.com]
Sent: Tuesday, March 19, 2013 4:36 PM
To: cloudstack-dev@incubator.apache.org
Subject: Question pertaining to VMSnapshot Feature on XenServer
As per the Feature's Functional Specification Document at https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots , I understand that the VMSnapshots are saved in the primary storage. I could observe this in the VMWare Setup. But I am unable to observe the presence of the VMsnapshots on a primary storage in a XenServer Setup. May I know where can I find the VMSnapshots in the case of XenServer,
Thank you,
Chandan.
-----Original Message-----
From: Animesh Chaturvedi
Sent: Thursday, March 21, 2013 2:09 PM
To: Mice Xia; cloudstack-dev@incubator.apache.org
Cc: Chandan Purushothama; Anthony Xu; Hari Kannan
Subject: RE: [MERGE] Support VM Snapshot
That's good, thanks for your response.
> -----Original Message-----
> From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> Sent: Wednesday, March 20, 2013 11:29 PM
> To: cloudstack-dev@incubator.apache.org; Animesh Chaturvedi
> Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> Subject: RE: [MERGE] Support VM Snapshot
>
> I'd like to a hypervisor_capabilities based solution.
> The earliest time that I can start changing it is next week. I haven’t
> investigated the solution, let's roughly suppose this could be done
> before mid April.
>
> -Mice
>
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Thursday, March 21, 2013 12:58 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: Chandan Purushothama; Anthony Xu
> Subject: RE: [MERGE] Support VM Snapshot
>
> Mice any updates, when can you provide a global enable/disable flag
> for the feature?
>
> Animesh
>
> > -----Original Message-----
> > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > Sent: Monday, March 18, 2013 10:44 PM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Chandan Purushothama; Anthony Xu
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > It would be best to enable/disable this feature on a per hypervisor
> > basis but if that's complicated adding a top level flag to
> > enable/disable the functionality is reasonable.
> >
> > > -----Original Message-----
> > > From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> > > Sent: Monday, March 18, 2013 9:59 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > Animesh,
> > >
> > > Do you mean limit the capability by adding global configurations
> > > or adding in [global-setting--> hypervisor capabilities] ?
> > >
> > > Mice
> > >
> > > -----Original Message-----
> > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > Sent: Tuesday, March 19, 2013 9:47 AM
> > > To: cloudstack-dev@incubator.apache.org; Mice Xia; Chandan
> > > Purushothama; Anthony Xu
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > Mice any comments to my email below.
> > >
> > > Animesh
> > >
> > > > -----Original Message-----
> > > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > > Sent: Wednesday, March 13, 2013 6:03 PM
> > > > To: Mice Xia; cloudstack-dev@incubator.apache.org; Chandan
> > > > Purushothama; Anthony Xu
> > > > Subject: RE: [MERGE] Support VM Snapshot
> > > >
> > > > Mice please see concerns from Anthony on Xenserver support., I
> > > > guess they can only be proved conclusively by testing with xenserver.
> > > > Chandan will test with xenserver.
> > > >
> > > > But given that there is some doubt on full support for xenserver
> > > > and kvm dependency on libvirt-java binding and I assume the
> > > > effort in making the capability configurable is trivial. In my
> > > > opinion we should make it configurable and turn on for xenserver
> > > > and kvm when support is
> > > clear.
> > > >
> > > >
> > > > Thanks
> > > > Animesh
> > > > > -----Original Message-----
> > > > > From: Mice Xia [mailto:weiran.xia1@gmail.com]
> > > > > Sent: Monday, March 11, 2013 2:49 AM
> > > > > To: cloudstack-dev@incubator.apache.org
> > > > > Cc: Animesh Chaturvedi
> > > > > Subject: Re: [MERGE] Support VM Snapshot
> > > > >
> > > > > Animesh,
> > > > >
> > > > > sorry for the late reply.
> > > > >
> > > > > 1. currently in master branch it supports both xenserver and
> > > > > vmware, for KVM it needs a new-versioned libvirt java binding,
> > > > > considering it's for 4.2, still three months away from the
> > > > > release date, we have big chance to ship the new libvirt
> > > > > binding. I dont see a strong need to make it configurable for
> > > > > hypervisors unless some functions do not work
> > > > at all..
> > > > >
> > > > > 2. now delta volume snapshot will become a full one. But I
> > > > > guess volume snapshot will be improved soon for xenserver.
> > > > > please correct me if we dont have this plan.
> > > > >
> > > > > Regards
> > > > > -Mice
> > > > >
> > > > > 2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> > > > > > Folks following up on this thread looks like support for
> > > > > > XenServer is still not
> > > > > settled.
> > > > > >
> > > > > > 1. Mice can we make the feature configurable for each
> > > > > > hypervisor to enable/disable the feature 2. Test the feature
> > > > > > with XenServer thoroughly to check if Volume Snapshot is
> > > > > > affected / degraded
> > > > > >
> > > > > > Thanks
> > > > > > Animesh
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > > > > >> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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"
> > > > > >> > > >> <Mu...@citrix.com>
> > > > > >> wrote:
> > > > > >> > > >>
> > > > > >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> > > > > >> > > >> ><mi...@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.
> > > > > >> > > >> >
> > > > > >> > > >
> > > > > >
RE: [MERGE] Support VM Snapshot
Posted by Animesh Chaturvedi <an...@citrix.com>.
Mice thanks for taking care of this
Animesh
> -----Original Message-----
> From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> Sent: Wednesday, April 10, 2013 1:57 AM
> To: Animesh Chaturvedi; cloudstack-dev@incubator.apache.org
> Cc: Chandan Purushothama; Anthony Xu; Hari Kannan
> Subject: RE: [MERGE] Support VM Snapshot
>
> Update in master:
>
> Add vm_snapshot enable/disable by hypervisor_capabilities, Add a new
> column ` vm_snapshot_enabled` in table `hypervisor_capabilities`, and
> change related VO/Dao Set vm_snapshot_enabled = 1 for
> VMware/Xenserver Check hypervisor_capabilities when createVMSnapshot
>
> UI part was not implemented for hypervisor_capabilities because I noticed
> 'maxHostPerCluster' is also added to hypervisor_capabilities and not sure if
> there are more items will be there.
>
> -Mice
>
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Friday, March 22, 2013 5:09 AM
> To: Mice Xia; cloudstack-dev@incubator.apache.org
> Cc: Chandan Purushothama; Anthony Xu; Hari Kannan
> Subject: RE: [MERGE] Support VM Snapshot
>
> That's good, thanks for your response.
>
> > -----Original Message-----
> > From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> > Sent: Wednesday, March 20, 2013 11:29 PM
> > To: cloudstack-dev@incubator.apache.org; Animesh Chaturvedi
> > Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > I'd like to a hypervisor_capabilities based solution.
> > The earliest time that I can start changing it is next week. I haven’t
> > investigated the solution, let's roughly suppose this could be done
> > before mid April.
> >
> > -Mice
> >
> > -----Original Message-----
> > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > Sent: Thursday, March 21, 2013 12:58 AM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Chandan Purushothama; Anthony Xu
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > Mice any updates, when can you provide a global enable/disable flag
> > for the feature?
> >
> > Animesh
> >
> > > -----Original Message-----
> > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > Sent: Monday, March 18, 2013 10:44 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: Chandan Purushothama; Anthony Xu
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > It would be best to enable/disable this feature on a per hypervisor
> > > basis but if that's complicated adding a top level flag to
> > > enable/disable the functionality is reasonable.
> > >
> > > > -----Original Message-----
> > > > From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> > > > Sent: Monday, March 18, 2013 9:59 PM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> > > > Subject: RE: [MERGE] Support VM Snapshot
> > > >
> > > > Animesh,
> > > >
> > > > Do you mean limit the capability by adding global configurations
> > > > or adding in [global-setting--> hypervisor capabilities] ?
> > > >
> > > > Mice
> > > >
> > > > -----Original Message-----
> > > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > > Sent: Tuesday, March 19, 2013 9:47 AM
> > > > To: cloudstack-dev@incubator.apache.org; Mice Xia; Chandan
> > > > Purushothama; Anthony Xu
> > > > Subject: RE: [MERGE] Support VM Snapshot
> > > >
> > > > Mice any comments to my email below.
> > > >
> > > > Animesh
> > > >
> > > > > -----Original Message-----
> > > > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > > > Sent: Wednesday, March 13, 2013 6:03 PM
> > > > > To: Mice Xia; cloudstack-dev@incubator.apache.org; Chandan
> > > > > Purushothama; Anthony Xu
> > > > > Subject: RE: [MERGE] Support VM Snapshot
> > > > >
> > > > > Mice please see concerns from Anthony on Xenserver support., I
> > > > > guess they can only be proved conclusively by testing with xenserver.
> > > > > Chandan will test with xenserver.
> > > > >
> > > > > But given that there is some doubt on full support for xenserver
> > > > > and kvm dependency on libvirt-java binding and I assume the
> > > > > effort in making the capability configurable is trivial. In my
> > > > > opinion we should make it configurable and turn on for xenserver
> > > > > and kvm when support is
> > > > clear.
> > > > >
> > > > >
> > > > > Thanks
> > > > > Animesh
> > > > > > -----Original Message-----
> > > > > > From: Mice Xia [mailto:weiran.xia1@gmail.com]
> > > > > > Sent: Monday, March 11, 2013 2:49 AM
> > > > > > To: cloudstack-dev@incubator.apache.org
> > > > > > Cc: Animesh Chaturvedi
> > > > > > Subject: Re: [MERGE] Support VM Snapshot
> > > > > >
> > > > > > Animesh,
> > > > > >
> > > > > > sorry for the late reply.
> > > > > >
> > > > > > 1. currently in master branch it supports both xenserver and
> > > > > > vmware, for KVM it needs a new-versioned libvirt java binding,
> > > > > > considering it's for 4.2, still three months away from the
> > > > > > release date, we have big chance to ship the new libvirt
> > > > > > binding. I dont see a strong need to make it configurable for
> > > > > > hypervisors unless some functions do not work
> > > > > at all..
> > > > > >
> > > > > > 2. now delta volume snapshot will become a full one. But I
> > > > > > guess volume snapshot will be improved soon for xenserver.
> > > > > > please correct me if we dont have this plan.
> > > > > >
> > > > > > Regards
> > > > > > -Mice
> > > > > >
> > > > > > 2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> > > > > > > Folks following up on this thread looks like support for
> > > > > > > XenServer is still not
> > > > > > settled.
> > > > > > >
> > > > > > > 1. Mice can we make the feature configurable for each
> > > > > > > hypervisor to enable/disable the feature 2. Test the feature
> > > > > > > with XenServer thoroughly to check if Volume Snapshot is
> > > > > > > affected / degraded
> > > > > > >
> > > > > > > Thanks
> > > > > > > Animesh
> > > > > > >
> > > > > > >
> > > > > > >> -----Original Message-----
> > > > > > >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > > > > > >> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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"
> > > > > > >> > > >> <Mu...@citrix.com>
> > > > > > >> wrote:
> > > > > > >> > > >>
> > > > > > >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> > > > > > >> > > >> ><mi...@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.
> > > > > > >> > > >> >
> > > > > > >> > > >
> > > > > > >
RE: [MERGE] Support VM Snapshot
Posted by Mice Xia <mi...@tcloudcomputing.com>.
Update in master:
Add vm_snapshot enable/disable by hypervisor_capabilities,
Add a new column ` vm_snapshot_enabled` in table `hypervisor_capabilities`, and change related VO/Dao
Set vm_snapshot_enabled = 1 for VMware/Xenserver
Check hypervisor_capabilities when createVMSnapshot
UI part was not implemented for hypervisor_capabilities because I noticed 'maxHostPerCluster' is also added to hypervisor_capabilities and not sure if there are more items will be there.
-Mice
-----Original Message-----
From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
Sent: Friday, March 22, 2013 5:09 AM
To: Mice Xia; cloudstack-dev@incubator.apache.org
Cc: Chandan Purushothama; Anthony Xu; Hari Kannan
Subject: RE: [MERGE] Support VM Snapshot
That's good, thanks for your response.
> -----Original Message-----
> From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> Sent: Wednesday, March 20, 2013 11:29 PM
> To: cloudstack-dev@incubator.apache.org; Animesh Chaturvedi
> Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> Subject: RE: [MERGE] Support VM Snapshot
>
> I'd like to a hypervisor_capabilities based solution.
> The earliest time that I can start changing it is next week. I haven’t
> investigated the solution, let's roughly suppose this could be done
> before mid April.
>
> -Mice
>
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Thursday, March 21, 2013 12:58 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: Chandan Purushothama; Anthony Xu
> Subject: RE: [MERGE] Support VM Snapshot
>
> Mice any updates, when can you provide a global enable/disable flag
> for the feature?
>
> Animesh
>
> > -----Original Message-----
> > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > Sent: Monday, March 18, 2013 10:44 PM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Chandan Purushothama; Anthony Xu
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > It would be best to enable/disable this feature on a per hypervisor
> > basis but if that's complicated adding a top level flag to
> > enable/disable the functionality is reasonable.
> >
> > > -----Original Message-----
> > > From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> > > Sent: Monday, March 18, 2013 9:59 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > Animesh,
> > >
> > > Do you mean limit the capability by adding global configurations
> > > or adding in [global-setting--> hypervisor capabilities] ?
> > >
> > > Mice
> > >
> > > -----Original Message-----
> > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > Sent: Tuesday, March 19, 2013 9:47 AM
> > > To: cloudstack-dev@incubator.apache.org; Mice Xia; Chandan
> > > Purushothama; Anthony Xu
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > Mice any comments to my email below.
> > >
> > > Animesh
> > >
> > > > -----Original Message-----
> > > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > > Sent: Wednesday, March 13, 2013 6:03 PM
> > > > To: Mice Xia; cloudstack-dev@incubator.apache.org; Chandan
> > > > Purushothama; Anthony Xu
> > > > Subject: RE: [MERGE] Support VM Snapshot
> > > >
> > > > Mice please see concerns from Anthony on Xenserver support., I
> > > > guess they can only be proved conclusively by testing with xenserver.
> > > > Chandan will test with xenserver.
> > > >
> > > > But given that there is some doubt on full support for xenserver
> > > > and kvm dependency on libvirt-java binding and I assume the
> > > > effort in making the capability configurable is trivial. In my
> > > > opinion we should make it configurable and turn on for xenserver
> > > > and kvm when support is
> > > clear.
> > > >
> > > >
> > > > Thanks
> > > > Animesh
> > > > > -----Original Message-----
> > > > > From: Mice Xia [mailto:weiran.xia1@gmail.com]
> > > > > Sent: Monday, March 11, 2013 2:49 AM
> > > > > To: cloudstack-dev@incubator.apache.org
> > > > > Cc: Animesh Chaturvedi
> > > > > Subject: Re: [MERGE] Support VM Snapshot
> > > > >
> > > > > Animesh,
> > > > >
> > > > > sorry for the late reply.
> > > > >
> > > > > 1. currently in master branch it supports both xenserver and
> > > > > vmware, for KVM it needs a new-versioned libvirt java binding,
> > > > > considering it's for 4.2, still three months away from the
> > > > > release date, we have big chance to ship the new libvirt
> > > > > binding. I dont see a strong need to make it configurable for
> > > > > hypervisors unless some functions do not work
> > > > at all..
> > > > >
> > > > > 2. now delta volume snapshot will become a full one. But I
> > > > > guess volume snapshot will be improved soon for xenserver.
> > > > > please correct me if we dont have this plan.
> > > > >
> > > > > Regards
> > > > > -Mice
> > > > >
> > > > > 2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> > > > > > Folks following up on this thread looks like support for
> > > > > > XenServer is still not
> > > > > settled.
> > > > > >
> > > > > > 1. Mice can we make the feature configurable for each
> > > > > > hypervisor to enable/disable the feature 2. Test the feature
> > > > > > with XenServer thoroughly to check if Volume Snapshot is
> > > > > > affected / degraded
> > > > > >
> > > > > > Thanks
> > > > > > Animesh
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > > > > >> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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"
> > > > > >> > > >> <Mu...@citrix.com>
> > > > > >> wrote:
> > > > > >> > > >>
> > > > > >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> > > > > >> > > >> ><mi...@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.
> > > > > >> > > >> >
> > > > > >> > > >
> > > > > >
RE: [MERGE] Support VM Snapshot
Posted by Animesh Chaturvedi <an...@citrix.com>.
That's good, thanks for your response.
> -----Original Message-----
> From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> Sent: Wednesday, March 20, 2013 11:29 PM
> To: cloudstack-dev@incubator.apache.org; Animesh Chaturvedi
> Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> Subject: RE: [MERGE] Support VM Snapshot
>
> I'd like to a hypervisor_capabilities based solution.
> The earliest time that I can start changing it is next week. I haven’t
> investigated the solution, let's roughly suppose this could be done before
> mid April.
>
> -Mice
>
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Thursday, March 21, 2013 12:58 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: Chandan Purushothama; Anthony Xu
> Subject: RE: [MERGE] Support VM Snapshot
>
> Mice any updates, when can you provide a global enable/disable flag for the
> feature?
>
> Animesh
>
> > -----Original Message-----
> > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > Sent: Monday, March 18, 2013 10:44 PM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Chandan Purushothama; Anthony Xu
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > It would be best to enable/disable this feature on a per hypervisor
> > basis but if that's complicated adding a top level flag to
> > enable/disable the functionality is reasonable.
> >
> > > -----Original Message-----
> > > From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> > > Sent: Monday, March 18, 2013 9:59 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > Animesh,
> > >
> > > Do you mean limit the capability by adding global configurations or
> > > adding in [global-setting--> hypervisor capabilities] ?
> > >
> > > Mice
> > >
> > > -----Original Message-----
> > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > Sent: Tuesday, March 19, 2013 9:47 AM
> > > To: cloudstack-dev@incubator.apache.org; Mice Xia; Chandan
> > > Purushothama; Anthony Xu
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > Mice any comments to my email below.
> > >
> > > Animesh
> > >
> > > > -----Original Message-----
> > > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > > Sent: Wednesday, March 13, 2013 6:03 PM
> > > > To: Mice Xia; cloudstack-dev@incubator.apache.org; Chandan
> > > > Purushothama; Anthony Xu
> > > > Subject: RE: [MERGE] Support VM Snapshot
> > > >
> > > > Mice please see concerns from Anthony on Xenserver support., I
> > > > guess they can only be proved conclusively by testing with xenserver.
> > > > Chandan will test with xenserver.
> > > >
> > > > But given that there is some doubt on full support for xenserver
> > > > and kvm dependency on libvirt-java binding and I assume the
> > > > effort in making the capability configurable is trivial. In my
> > > > opinion we should make it configurable and turn on for xenserver
> > > > and kvm when support is
> > > clear.
> > > >
> > > >
> > > > Thanks
> > > > Animesh
> > > > > -----Original Message-----
> > > > > From: Mice Xia [mailto:weiran.xia1@gmail.com]
> > > > > Sent: Monday, March 11, 2013 2:49 AM
> > > > > To: cloudstack-dev@incubator.apache.org
> > > > > Cc: Animesh Chaturvedi
> > > > > Subject: Re: [MERGE] Support VM Snapshot
> > > > >
> > > > > Animesh,
> > > > >
> > > > > sorry for the late reply.
> > > > >
> > > > > 1. currently in master branch it supports both xenserver and
> > > > > vmware, for KVM it needs a new-versioned libvirt java binding,
> > > > > considering it's for 4.2, still three months away from the
> > > > > release date, we have big chance to ship the new libvirt
> > > > > binding. I dont see a strong need to make it configurable for
> > > > > hypervisors unless some functions do not work
> > > > at all..
> > > > >
> > > > > 2. now delta volume snapshot will become a full one. But I guess
> > > > > volume snapshot will be improved soon for xenserver. please
> > > > > correct me if we dont have this plan.
> > > > >
> > > > > Regards
> > > > > -Mice
> > > > >
> > > > > 2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> > > > > > Folks following up on this thread looks like support for
> > > > > > XenServer is still not
> > > > > settled.
> > > > > >
> > > > > > 1. Mice can we make the feature configurable for each
> > > > > > hypervisor to enable/disable the feature 2. Test the feature
> > > > > > with XenServer thoroughly to check if Volume Snapshot is
> > > > > > affected / degraded
> > > > > >
> > > > > > Thanks
> > > > > > Animesh
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > > > > >> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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"
> > > > > >> > > >> <Mu...@citrix.com>
> > > > > >> wrote:
> > > > > >> > > >>
> > > > > >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> > > > > >> > > >> ><mi...@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.
> > > > > >> > > >> >
> > > > > >> > > >
> > > > > >
RE: [MERGE] Support VM Snapshot
Posted by Mice Xia <mi...@tcloudcomputing.com>.
I'd like to a hypervisor_capabilities based solution.
The earliest time that I can start changing it is next week. I haven’t investigated the solution, let's roughly suppose this could be done before mid April.
-Mice
-----Original Message-----
From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
Sent: Thursday, March 21, 2013 12:58 AM
To: cloudstack-dev@incubator.apache.org
Cc: Chandan Purushothama; Anthony Xu
Subject: RE: [MERGE] Support VM Snapshot
Mice any updates, when can you provide a global enable/disable flag for the feature?
Animesh
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Monday, March 18, 2013 10:44 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Chandan Purushothama; Anthony Xu
> Subject: RE: [MERGE] Support VM Snapshot
>
> It would be best to enable/disable this feature on a per hypervisor
> basis but if that's complicated adding a top level flag to
> enable/disable the functionality is reasonable.
>
> > -----Original Message-----
> > From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> > Sent: Monday, March 18, 2013 9:59 PM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > Animesh,
> >
> > Do you mean limit the capability by adding global configurations or
> > adding in [global-setting--> hypervisor capabilities] ?
> >
> > Mice
> >
> > -----Original Message-----
> > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > Sent: Tuesday, March 19, 2013 9:47 AM
> > To: cloudstack-dev@incubator.apache.org; Mice Xia; Chandan
> > Purushothama; Anthony Xu
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > Mice any comments to my email below.
> >
> > Animesh
> >
> > > -----Original Message-----
> > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > Sent: Wednesday, March 13, 2013 6:03 PM
> > > To: Mice Xia; cloudstack-dev@incubator.apache.org; Chandan
> > > Purushothama; Anthony Xu
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > Mice please see concerns from Anthony on Xenserver support., I
> > > guess they can only be proved conclusively by testing with xenserver.
> > > Chandan will test with xenserver.
> > >
> > > But given that there is some doubt on full support for xenserver
> > > and kvm dependency on libvirt-java binding and I assume the
> > > effort in making the capability configurable is trivial. In my
> > > opinion we should make it configurable and turn on for xenserver
> > > and kvm when support is
> > clear.
> > >
> > >
> > > Thanks
> > > Animesh
> > > > -----Original Message-----
> > > > From: Mice Xia [mailto:weiran.xia1@gmail.com]
> > > > Sent: Monday, March 11, 2013 2:49 AM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Cc: Animesh Chaturvedi
> > > > Subject: Re: [MERGE] Support VM Snapshot
> > > >
> > > > Animesh,
> > > >
> > > > sorry for the late reply.
> > > >
> > > > 1. currently in master branch it supports both xenserver and
> > > > vmware, for KVM it needs a new-versioned libvirt java binding,
> > > > considering it's for 4.2, still three months away from the
> > > > release date, we have big chance to ship the new libvirt
> > > > binding. I dont see a strong need to make it configurable for
> > > > hypervisors unless some functions do not work
> > > at all..
> > > >
> > > > 2. now delta volume snapshot will become a full one. But I guess
> > > > volume snapshot will be improved soon for xenserver. please
> > > > correct me if we dont have this plan.
> > > >
> > > > Regards
> > > > -Mice
> > > >
> > > > 2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> > > > > Folks following up on this thread looks like support for
> > > > > XenServer is still not
> > > > settled.
> > > > >
> > > > > 1. Mice can we make the feature configurable for each
> > > > > hypervisor to enable/disable the feature 2. Test the feature
> > > > > with XenServer thoroughly to check if Volume Snapshot is
> > > > > affected / degraded
> > > > >
> > > > > Thanks
> > > > > Animesh
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > > > >> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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"
> > > > >> > > >> <Mu...@citrix.com>
> > > > >> wrote:
> > > > >> > > >>
> > > > >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> > > > >> > > >> ><mi...@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.
> > > > >> > > >> >
> > > > >> > > >
> > > > >
RE: [MERGE] Support VM Snapshot
Posted by Animesh Chaturvedi <an...@citrix.com>.
Mice any updates, when can you provide a global enable/disable flag for the feature?
Animesh
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Monday, March 18, 2013 10:44 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Chandan Purushothama; Anthony Xu
> Subject: RE: [MERGE] Support VM Snapshot
>
> It would be best to enable/disable this feature on a per hypervisor basis but
> if that's complicated adding a top level flag to enable/disable the functionality
> is reasonable.
>
> > -----Original Message-----
> > From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> > Sent: Monday, March 18, 2013 9:59 PM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > Animesh,
> >
> > Do you mean limit the capability by adding global configurations or
> > adding in [global-setting--> hypervisor capabilities] ?
> >
> > Mice
> >
> > -----Original Message-----
> > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > Sent: Tuesday, March 19, 2013 9:47 AM
> > To: cloudstack-dev@incubator.apache.org; Mice Xia; Chandan
> > Purushothama; Anthony Xu
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > Mice any comments to my email below.
> >
> > Animesh
> >
> > > -----Original Message-----
> > > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > > Sent: Wednesday, March 13, 2013 6:03 PM
> > > To: Mice Xia; cloudstack-dev@incubator.apache.org; Chandan
> > > Purushothama; Anthony Xu
> > > Subject: RE: [MERGE] Support VM Snapshot
> > >
> > > Mice please see concerns from Anthony on Xenserver support., I guess
> > > they can only be proved conclusively by testing with xenserver.
> > > Chandan will test with xenserver.
> > >
> > > But given that there is some doubt on full support for xenserver and
> > > kvm dependency on libvirt-java binding and I assume the effort in
> > > making the capability configurable is trivial. In my opinion we
> > > should make it configurable and turn on for xenserver and kvm when
> > > support is
> > clear.
> > >
> > >
> > > Thanks
> > > Animesh
> > > > -----Original Message-----
> > > > From: Mice Xia [mailto:weiran.xia1@gmail.com]
> > > > Sent: Monday, March 11, 2013 2:49 AM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Cc: Animesh Chaturvedi
> > > > Subject: Re: [MERGE] Support VM Snapshot
> > > >
> > > > Animesh,
> > > >
> > > > sorry for the late reply.
> > > >
> > > > 1. currently in master branch it supports both xenserver and
> > > > vmware, for KVM it needs a new-versioned libvirt java binding,
> > > > considering it's for 4.2, still three months away from the release
> > > > date, we have big chance to ship the new libvirt binding. I dont
> > > > see a strong need to make it configurable for hypervisors unless
> > > > some functions do not work
> > > at all..
> > > >
> > > > 2. now delta volume snapshot will become a full one. But I guess
> > > > volume snapshot will be improved soon for xenserver. please
> > > > correct me if we dont have this plan.
> > > >
> > > > Regards
> > > > -Mice
> > > >
> > > > 2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> > > > > Folks following up on this thread looks like support for
> > > > > XenServer is still not
> > > > settled.
> > > > >
> > > > > 1. Mice can we make the feature configurable for each hypervisor
> > > > > to enable/disable the feature 2. Test the feature with XenServer
> > > > > thoroughly to check if Volume Snapshot is affected / degraded
> > > > >
> > > > > Thanks
> > > > > Animesh
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > > > >> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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"
> > > > >> > > >> <Mu...@citrix.com>
> > > > >> wrote:
> > > > >> > > >>
> > > > >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> > > > >> > > >> ><mi...@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.
> > > > >> > > >> >
> > > > >> > > >
> > > > >
RE: [MERGE] Support VM Snapshot
Posted by Animesh Chaturvedi <an...@citrix.com>.
It would be best to enable/disable this feature on a per hypervisor basis but if that's complicated adding a top level flag to enable/disable the functionality is reasonable.
> -----Original Message-----
> From: Mice Xia [mailto:mice_xia@tcloudcomputing.com]
> Sent: Monday, March 18, 2013 9:59 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Chandan Purushothama; Anthony Xu; Mice Xia
> Subject: RE: [MERGE] Support VM Snapshot
>
> Animesh,
>
> Do you mean limit the capability by adding global configurations or adding in
> [global-setting--> hypervisor capabilities] ?
>
> Mice
>
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Tuesday, March 19, 2013 9:47 AM
> To: cloudstack-dev@incubator.apache.org; Mice Xia; Chandan
> Purushothama; Anthony Xu
> Subject: RE: [MERGE] Support VM Snapshot
>
> Mice any comments to my email below.
>
> Animesh
>
> > -----Original Message-----
> > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> > Sent: Wednesday, March 13, 2013 6:03 PM
> > To: Mice Xia; cloudstack-dev@incubator.apache.org; Chandan
> > Purushothama; Anthony Xu
> > Subject: RE: [MERGE] Support VM Snapshot
> >
> > Mice please see concerns from Anthony on Xenserver support., I guess
> > they can only be proved conclusively by testing with xenserver.
> > Chandan will test with xenserver.
> >
> > But given that there is some doubt on full support for xenserver and
> > kvm dependency on libvirt-java binding and I assume the effort in
> > making the capability configurable is trivial. In my opinion we should
> > make it configurable and turn on for xenserver and kvm when support is
> clear.
> >
> >
> > Thanks
> > Animesh
> > > -----Original Message-----
> > > From: Mice Xia [mailto:weiran.xia1@gmail.com]
> > > Sent: Monday, March 11, 2013 2:49 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: Animesh Chaturvedi
> > > Subject: Re: [MERGE] Support VM Snapshot
> > >
> > > Animesh,
> > >
> > > sorry for the late reply.
> > >
> > > 1. currently in master branch it supports both xenserver and vmware,
> > > for KVM it needs a new-versioned libvirt java binding, considering
> > > it's for 4.2, still three months away from the release date, we have
> > > big chance to ship the new libvirt binding. I dont see a strong need
> > > to make it configurable for hypervisors unless some functions do not
> > > work
> > at all..
> > >
> > > 2. now delta volume snapshot will become a full one. But I guess
> > > volume snapshot will be improved soon for xenserver. please correct
> > > me if we dont have this plan.
> > >
> > > Regards
> > > -Mice
> > >
> > > 2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> > > > Folks following up on this thread looks like support for XenServer
> > > > is still not
> > > settled.
> > > >
> > > > 1. Mice can we make the feature configurable for each hypervisor
> > > > to enable/disable the feature 2. Test the feature with XenServer
> > > > thoroughly to check if Volume Snapshot is affected / degraded
> > > >
> > > > Thanks
> > > > Animesh
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > > >> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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"
> > > >> > > >> <Mu...@citrix.com>
> > > >> wrote:
> > > >> > > >>
> > > >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> > > >> > > >> ><mi...@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.
> > > >> > > >> >
> > > >> > > >
> > > >
RE: [MERGE] Support VM Snapshot
Posted by Mice Xia <mi...@tcloudcomputing.com>.
Animesh,
Do you mean limit the capability by adding global configurations or adding in [global-setting--> hypervisor capabilities] ?
Mice
-----Original Message-----
From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
Sent: Tuesday, March 19, 2013 9:47 AM
To: cloudstack-dev@incubator.apache.org; Mice Xia; Chandan Purushothama; Anthony Xu
Subject: RE: [MERGE] Support VM Snapshot
Mice any comments to my email below.
Animesh
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Wednesday, March 13, 2013 6:03 PM
> To: Mice Xia; cloudstack-dev@incubator.apache.org; Chandan
> Purushothama; Anthony Xu
> Subject: RE: [MERGE] Support VM Snapshot
>
> Mice please see concerns from Anthony on Xenserver support., I guess
> they can only be proved conclusively by testing with xenserver.
> Chandan will test with xenserver.
>
> But given that there is some doubt on full support for xenserver and
> kvm dependency on libvirt-java binding and I assume the effort in
> making the capability configurable is trivial. In my opinion we should
> make it configurable and turn on for xenserver and kvm when support is clear.
>
>
> Thanks
> Animesh
> > -----Original Message-----
> > From: Mice Xia [mailto:weiran.xia1@gmail.com]
> > Sent: Monday, March 11, 2013 2:49 AM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Animesh Chaturvedi
> > Subject: Re: [MERGE] Support VM Snapshot
> >
> > Animesh,
> >
> > sorry for the late reply.
> >
> > 1. currently in master branch it supports both xenserver and vmware,
> > for KVM it needs a new-versioned libvirt java binding, considering
> > it's for 4.2, still three months away from the release date, we have
> > big chance to ship the new libvirt binding. I dont see a strong need
> > to make it configurable for hypervisors unless some functions do not
> > work
> at all..
> >
> > 2. now delta volume snapshot will become a full one. But I guess
> > volume snapshot will be improved soon for xenserver. please correct
> > me if we dont have this plan.
> >
> > Regards
> > -Mice
> >
> > 2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> > > Folks following up on this thread looks like support for XenServer
> > > is still not
> > settled.
> > >
> > > 1. Mice can we make the feature configurable for each hypervisor
> > > to enable/disable the feature 2. Test the feature with XenServer
> > > thoroughly to check if Volume Snapshot is affected / degraded
> > >
> > > Thanks
> > > Animesh
> > >
> > >
> > >> -----Original Message-----
> > >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > >> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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"
> > >> > > >> <Mu...@citrix.com>
> > >> wrote:
> > >> > > >>
> > >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> > >> > > >> ><mi...@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.
> > >> > > >> >
> > >> > > >
> > >
RE: [MERGE] Support VM Snapshot
Posted by Animesh Chaturvedi <an...@citrix.com>.
Mice any comments to my email below.
Animesh
> -----Original Message-----
> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
> Sent: Wednesday, March 13, 2013 6:03 PM
> To: Mice Xia; cloudstack-dev@incubator.apache.org; Chandan
> Purushothama; Anthony Xu
> Subject: RE: [MERGE] Support VM Snapshot
>
> Mice please see concerns from Anthony on Xenserver support., I guess they
> can only be proved conclusively by testing with xenserver. Chandan will test
> with xenserver.
>
> But given that there is some doubt on full support for xenserver and kvm
> dependency on libvirt-java binding and I assume the effort in making the
> capability configurable is trivial. In my opinion we should make it configurable
> and turn on for xenserver and kvm when support is clear.
>
>
> Thanks
> Animesh
> > -----Original Message-----
> > From: Mice Xia [mailto:weiran.xia1@gmail.com]
> > Sent: Monday, March 11, 2013 2:49 AM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Animesh Chaturvedi
> > Subject: Re: [MERGE] Support VM Snapshot
> >
> > Animesh,
> >
> > sorry for the late reply.
> >
> > 1. currently in master branch it supports both xenserver and vmware,
> > for KVM it needs a new-versioned libvirt java binding, considering
> > it's for 4.2, still three months away from the release date, we have
> > big chance to ship the new libvirt binding. I dont see a strong need
> > to make it configurable for hypervisors unless some functions do not work
> at all..
> >
> > 2. now delta volume snapshot will become a full one. But I guess
> > volume snapshot will be improved soon for xenserver. please correct me
> > if we dont have this plan.
> >
> > Regards
> > -Mice
> >
> > 2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> > > Folks following up on this thread looks like support for XenServer
> > > is still not
> > settled.
> > >
> > > 1. Mice can we make the feature configurable for each hypervisor to
> > > enable/disable the feature 2. Test the feature with XenServer
> > > thoroughly to check if Volume Snapshot is affected / degraded
> > >
> > > Thanks
> > > Animesh
> > >
> > >
> > >> -----Original Message-----
> > >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> > >> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com>
> > >> wrote:
> > >> > > >>
> > >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> > >> > > >> ><mi...@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.
> > >> > > >> >
> > >> > > >
> > >
RE: [MERGE] Support VM Snapshot
Posted by Animesh Chaturvedi <an...@citrix.com>.
Mice please see concerns from Anthony on Xenserver support., I guess they can only be proved conclusively by testing with xenserver. Chandan will test with xenserver.
But given that there is some doubt on full support for xenserver and kvm dependency on libvirt-java binding and I assume the effort in making the capability configurable is trivial. In my opinion we should make it configurable and turn on for xenserver and kvm when support is clear.
Thanks
Animesh
> -----Original Message-----
> From: Mice Xia [mailto:weiran.xia1@gmail.com]
> Sent: Monday, March 11, 2013 2:49 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: Animesh Chaturvedi
> Subject: Re: [MERGE] Support VM Snapshot
>
> Animesh,
>
> sorry for the late reply.
>
> 1. currently in master branch it supports both xenserver and vmware, for
> KVM it needs a new-versioned libvirt java binding, considering it's for 4.2, still
> three months away from the release date, we have big chance to ship the
> new libvirt binding. I dont see a strong need to make it configurable for
> hypervisors unless some functions do not work at all..
>
> 2. now delta volume snapshot will become a full one. But I guess volume
> snapshot will be improved soon for xenserver. please correct me if we dont
> have this plan.
>
> Regards
> -Mice
>
> 2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> > Folks following up on this thread looks like support for XenServer is still not
> settled.
> >
> > 1. Mice can we make the feature configurable for each hypervisor to
> > enable/disable the feature 2. Test the feature with XenServer
> > thoroughly to check if Volume Snapshot is affected / degraded
> >
> > Thanks
> > Animesh
> >
> >
> >> -----Original Message-----
> >> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> >> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com>
> >> wrote:
> >> > > >>
> >> > > >> >On 30/01/13 2:24 PM, "Mice Xia"
> >> > > >> ><mi...@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.
> >> > > >> >
> >> > > >
> >
Re: [MERGE] Support VM Snapshot
Posted by Mice Xia <we...@gmail.com>.
Animesh,
sorry for the late reply.
1. currently in master branch it supports both xenserver and vmware,
for KVM it needs a new-versioned libvirt java binding, considering
it's for 4.2, still three months away from the release date, we have
big chance to ship the new libvirt binding. I dont see a strong need
to make it configurable for hypervisors unless some functions do not
work at all..
2. now delta volume snapshot will become a full one. But I guess
volume snapshot will be improved soon for xenserver. please correct me
if we dont have this plan.
Regards
-Mice
2013/3/8 Animesh Chaturvedi <an...@citrix.com>:
> Folks following up on this thread looks like support for XenServer is still not settled.
>
> 1. Mice can we make the feature configurable for each hypervisor to enable/disable the feature
> 2. Test the feature with XenServer thoroughly to check if Volume Snapshot is affected / degraded
>
> Thanks
> Animesh
>
>
>> -----Original Message-----
>> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
>> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com>
>> wrote:
>> > > >>
>> > > >> >On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
>> > > >> >
>> > > >
>
RE: [MERGE] Support VM Snapshot
Posted by Animesh Chaturvedi <an...@citrix.com>.
Folks following up on this thread looks like support for XenServer is still not settled.
1. Mice can we make the feature configurable for each hypervisor to enable/disable the feature
2. Test the feature with XenServer thoroughly to check if Volume Snapshot is affected / degraded
Thanks
Animesh
> -----Original Message-----
> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> 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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com>
> wrote:
> > > >>
> > > >> >On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
> > > >> >
> > > >
RE: [MERGE] Support VM Snapshot
Posted by Sangeetha Hariharan <Sa...@citrix.com>.
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:wido@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:wido@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_xia@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.Huang@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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com> wrote:
>>>>>>
>>>>>>> On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
>>>>>>>
>>>>>
>>
>
Re: [MERGE] Support VM Snapshot
Posted by Wido den Hollander <wi...@widodh.nl>.
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:wido@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_xia@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.Huang@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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com> wrote:
>>>>>>
>>>>>>> On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
>>>>>>>
>>>>>
>>
>
RE: [MERGE] Support VM Snapshot
Posted by Sangeetha Hariharan <Sa...@citrix.com>.
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:wido@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_xia@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.Huang@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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com> wrote:
>>>>>
>>>>>> On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
>>>>>>
>>>>
>
Re: [MERGE] Support VM Snapshot
Posted by Wido den Hollander <wi...@widodh.nl>.
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_xia@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.Huang@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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com> wrote:
>>>>>
>>>>>> On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
>>>>>>
>>>>
>
RE: [MERGE] Support VM Snapshot
Posted by Mice Xia <mi...@tcloudcomputing.com>.
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.
-Mice
-----Original Message-----
From: Mice Xia [mailto:mice_xia@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.Huang@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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com> wrote:
> > >>
> > >> >On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
> > >> >
> > >
RE: [MERGE] Support VM Snapshot
Posted by Mice Xia <mi...@tcloudcomputing.com>.
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.Huang@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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com> wrote:
> > >>
> > >> >On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
> > >> >
> > >
RE: [MERGE] Support VM Snapshot
Posted by Alex Huang <Al...@citrix.com>.
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_xia@tcloudcomputing.com]
Sent: Friday, February 01, 2013 5:30 PM
To: cloudstack-dev@incubator.apache.org<ma...@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.Xu@citrix.com]
Sent: 2013-2-2 (星期六) 4:05
To: Alex Huang; Mice Xia; cloudstack-dev@incubator.apache.org<ma...@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<ma...@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.xia1@gmail.com]
> > Sent: Friday, February 01, 2013 8:53 AM
> > To: cloudstack-dev@incubator.apache.org<ma...@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 <mi...@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.Huang@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" <Mu...@citrix.com>> wrote:
> > >>
> > >> >On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
> > >> >
> > >
RE: [MERGE] Support VM Snapshot
Posted by Anthony Xu <Xu...@citrix.com>.
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_xia@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.Xu@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.xia1@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 <mi...@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.Huang@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" <Mu...@citrix.com> wrote:
> > >>
> > >> >On 30/01/13 2:24 PM, "Mice Xia" <mi...@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.
> > >> >
> > >