Hi Mice Thanks for the comments - please see some more feedback inline below
Hari -----Original Message----- From: Mice Xia [mailto:weiran.x...@gmail.com] Sent: Monday, November 19, 2012 5:52 PM To: cloudstack-dev@incubator.apache.org Subject: VM Snapshot progress update Hi, Hari, changing service offering will probably change vm's memory size, if there are some memory snapshots associated with this vm, they should not be allowed to revert. we can loose up the restriction by allowing offering change when this vm has only disk snapshots. Hari: I agree with your rationale, however, what I was suggesting is to allow an offering to be changed with a warning that they may lose the snapshots (and internally deleting them) - here is the use case I visualize - an end user has been using a 1CPU 1GB VM with a few disks and assume has some snapshots (including memory) - after a while, he wants to make it a 2vCPU and 2 GB VM as his needs have changed. Instead of forcing him to recreate a brand new VM just because he has a few snapshots, I'm suggesting that we allow him to "upgrade" his VM (like we do today), but he has no access to the snapshots any more - does it make sense? when a volume/vm snapshot is creating, the disk chain of this vm may have been changed during the operation, to keep it simple and race condition free, when a volume snapshot is taking, vm snapshot ops are not allowed, and vise versa. Hari: OK, understand, perhaps the wording is misleading - what you meant is as long as VM snapshot and volume snapshot are not required to run CONCURRENTLY, the same VM can have VM as well as volume snapshot - right? thanks for ur suggestion and i will elaborate. sent from phone, sorry for any typos. > Hello Mice, > > Thanks for this feature! After reading your document, I have a couple > of questions: > > Under the limitations section, can you please elaborate, in general, > why those limitations arise - is it because they are not implemented (in phase 1, for example due to lack of time etc.) or they don't make sense > > Specifically, the limitation " VM's service offering is not allowed to change if there are VM snapshots " - I wonder if we should allow this with a warning that the existing snapshots are invalidated (for example) > Also, the limitation " Volume snapshot operations are mutually > exclusive to VM snapshot operation " - why? > > Thank you! > > Hari Kannan > > -----Original Message----- > From: Mice Xia [mailto:mice_...@tcloudcomputing.com] > Sent: Sunday, November 18, 2012 7:23 PM > To: cloudstack-dev@incubator.apache.org > Subject: VM Snapshot progress update > > Hi, Folks, > > Sorry for the late update. I have been busy recently and haven't > updated this for awhile. > Yesterday I re-created vm-snapshot branch based on 4.0 branch and submitted refactorred codes with KVM support. > Now the major parts have been done, and because this touches CS core, > I would like to welcome any suggestion, design/code review, tests and feedbacks of all forms. > > [Document] > For a complete updated spec/design document, please see https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots > > [Progress] (tested with simple scenario) Xenserver Free/Enterprise support VMware support KVM support UI > > [TBD] > Resource Limit > VM snapshot allocation size stat > Usage > > [How to test] > 1.please notice KVM needs a modified libvirt.jar (thanks Wido for providing it), to make KVM VM snapshot work properly, it is required to replace the old libvirt-0.4.9.jar with this one. > http://people.apache.org/~mice/libvirt-0.4.9.jar > > 2.to test VMware support, apply Rohit's 4.0 nonoss patch before compile/build http://bhaisaab.org/patches/cloudstack/0001-BUILD-Make-CloudStack-buildable-with-nonoss-libs.patch > http://bhaisaab.org/patches/cloudstack/0002-BUILD-nonoss-libs-for-CloudStack.patch > > 3.use Ant/Maven to build/debug, same with 4.0. > > Regards > Mice > -- Sent from Gmail Mobile
