Hi Paul,<div><br></div><div>This is a very interesting feature. You should open a new ecosystem project [1] as soon as your code is usable, so others can test it. If you would like to see your code merged upstream once it gets to a mature enough state, make sure that whoever has to give the thumbs up in your company is aware of the License Agreement [2].</div>
<div><br></div><div>And now some quick comments to your questions:</div><div><br></div><div><br>On Mon, Feb 6, 2012 at 12:19 PM, Paul Grandperrin <span dir="ltr"><<a href="mailto:paul.grandperrin@alterway.fr" target="_blank">paul.grandperrin@alterway.fr</a>></span> wrote:<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>1. About VM memory scaling: Currently, AFAIK the vm.memory is used when deploying a VM to set it's initial memory and then is regularly updated via hypervisor polling.</div><div> ATM, i'm also using this attribute to change memory size. I think it's really not the best way thing to do. I'd like to separate theses different things in separate variables.</div>
<div> For exemple:</div><div> -memory: the same as of now.</div><div> -memory_target: the target amount of memory when scaling memory.</div><div><br></div><div> I could also use VM history but I'm not very familiar with this class.</div>
<div><br></div></blockquote><div><br></div><div>Each history entry represents a host change, so new ones are created only when the VM is deployed, migrated, or stopped + resumed. That's not the best place to log the scaling changes.</div>
<div><br></div><div>About storing the target amount of memory: VM::memory is the used memory, as reported by the polling. The memory definition, set by the user and used to create the deployment file, is taken from the MEMORY attribute of VM::obj_template. I think you should overwrite that attribute to store the target memory.</div>
<div><br></div><div>Before doing this scaling operation, you should check that the host has enough free memory. After the operation, the host share should be updated, take a look at Host::host_share, Host::add_capacity and Host::del_capacity. If you don't update the host share memory, when the VM is shutdown it will leave the host with a negative memory value.</div>
<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div></div><div>2. When scalling the number of VCPUs, should we also scale the VM's cpu share? If so, how to implement it?</div></blockquote><div><br></div><div>I'm not sure about the desirable behaviour. Maybe this should be decided by the user? If you are going to modify the CPU, and not only the VCPU, all the above comments about the MEMORY apply.</div>
<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
</div><div>3. In the case of a scalling failure (memory or vcpu), what should we do?</div>
<div> -Consider the VM failed and not usable anymore? (I think it's way too strict)</div><div> -Consider the VM still ACTIVE. However, how to inform the user about the failure (something else than writing in logs).</div>
<div> And then what should we do?</div><div> -immediatly throw a monitor request to update to the correct value?</div><div> -Consider the worst case: if scaling down the memory => consider the old value/ if scaling up the memory, consider the new value</div>
<div> -Other ideas?</div></blockquote><div><br></div><div>I've seen you are creating new LCM states. This can be very tricky, maybe you should just apply the action without moving from the RUNNING state, like the reboot action. And, if you are creating new states, at least try to keep it simple and merge those two new ones into just one. SCALING, or even a more generic... HOTPLUG?</div>
<div><br></div><div>I would always return to the RUNNING state, updating MEMORY and CPU (and Host:: host_share) in case of success.</div><div>The user will see that the operation finished, and will see if it succeeded taking a look at the VM template. You can also include an error message in the template if the operation failed.</div>
<div><br></div><div>If the scaling command returns success/failure immediately, I would not force a poll. As I said, the poll updates the used memory, not the amount set for the VM.</div><div><br></div></div><div><br></div>
<div>Regards... and good luck!</div><div><br></div><div>[1] <a href="http://opennebula.org/community:ecosystem" target="_blank">http://opennebula.org/community:ecosystem</a></div><div>[2] <a href="http://opennebula.org/community:contribute" target="_blank">http://opennebula.org/community:contribute</a></div>
<div><br clear="all"><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px">--<br>Carlos Martín, MSc<br>Project Engineer<br>OpenNebula - The Open Source Toolkit for Data Center Virtualization<br>
<a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:cmartin@opennebula.org" target="_blank">cmartin@opennebula.org</a> | <a href="http://twitter.com/opennebula" target="_blank">@OpenNebula</a></span><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px"><a href="mailto:cmartin@opennebula.org" style="color:rgb(42,93,176)" target="_blank"></a></span><br>
<br><br><div class="gmail_quote">On Mon, Feb 6, 2012 at 12:19 PM, Paul Grandperrin <span dir="ltr"><<a href="mailto:paul.grandperrin@alterway.fr" target="_blank">paul.grandperrin@alterway.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Hi all,</div><div><br></div><div>I'm implementing scale-in features in OpenNebula like live memory growth/shrinking and vcpus hotplugging/hotunplugging.</div><div><br></div><div>You can see my git there: <a href="http://paulg.fr/gitweb/?p=one.git;a=summary;js=1" target="_blank">http://paulg.fr/gitweb/?p=one.git;a=summary;js=1</a></div>
<div>My developement branch is feature-scalein. It's still very much a WIP most of the interesting code is there and basic features are functionnal on Xen at the moment.</div><div>My dev branch is based on one-3.2 but can easily be rebased on master.</div>
<div><br></div><div>Everything is meant to eventualy hit upstream, that why I'd like to get some advices and feedback from you.</div><div><br></div><div>Here are my questions:</div><div><br></div><div>1. About VM memory scaling: Currently, AFAIK the vm.memory is used when deploying a VM to set it's initial memory and then is regularly updated via hypervisor polling.</div>
<div> ATM, i'm also using this attribute to change memory size. I think it's really not the best way thing to do. I'd like to separate theses different things in separate variables.</div><div> For exemple:</div>
<div> -memory: the same as of now.</div><div> -memory_target: the target amount of memory when scaling memory.</div><div><br></div><div> I could also use VM history but I'm not very familiar with this class.</div>
<div><br></div><div>2. When scalling the number of VCPUs, should we also scale the VM's cpu share? If so, how to implement it?</div><div><br></div><div>3. In the case of a scalling failure (memory or vcpu), what should we do?</div>
<div> -Consider the VM failed and not usable anymore? (I think it's way too strict)</div><div> -Consider the VM still ACTIVE. However, how to inform the user about the failure (something else than writing in logs).</div>
<div> And then what should we do?</div><div> -immediatly throw a monitor request to update to the correct value?</div><div> -Consider the worst case: if scaling down the memory => consider the old value/ if scaling up the memory, consider the new value</div>
<div> -Other ideas?</div><div><br></div><div>Any suggestions about the code structure, writing style, naming conventions, whatever... are welcome :D</div><div><br></div><div>You can also see my TODO list here: <a href="http://paulg.fr/gitweb/?p=one.git;a=blob_plain;f=TODO;h=79c65a4a6eba19095a43191a75fc1e5d58d7e01a;hb=refs/heads/feature-scalein;js=1" target="_blank">http://paulg.fr/gitweb/?p=one.git;a=blob_plain;f=TODO;h=79c65a4a6eba19095a43191a75fc1e5d58d7e01a;hb=refs/heads/feature-scalein;js=1</a></div>
<div><br></div><div>What changed:</div><div><font face="'courier new', monospace">paulg@debian-pro:~/projects/one$ git diff one-3.2 --stat</font></div><div><font face="'courier new', monospace"> TODO | 12 ++</font></div>
<div><font face="'courier new', monospace"> include/DispatchManager.h | 20 +++</font></div><div><font face="'courier new', monospace"> include/LifeCycleManager.h | 20 +++-</font></div>
<div><font face="'courier new', monospace"> include/RequestManagerVirtualMachine.h | 36 +++++</font></div><div><font face="'courier new', monospace"> include/VirtualMachine.h | 43 +++++-</font></div>
<div><font face="'courier new', monospace"> include/VirtualMachineManager.h | 50 +++++--</font></div><div><font face="'courier new', monospace"> include/VirtualMachineManagerDriver.h | 50 +++++--</font></div>
<div><font face="'courier new', monospace"> install.sh | 4 +-</font></div><div><font face="'courier new', monospace"> share/man/onevm.1 | 60 ++++++++</font></div>
<div><font face="'courier new', monospace"> src/cli/one_helper.rb | 2 +-</font></div><div><font face="'courier new', monospace"> src/cli/one_helper/onevm_helper.rb | 24 +++</font></div>
<div><font face="'courier new', monospace"> src/cli/onevm | 32 ++++</font></div><div><font face="'courier new', monospace"> src/dm/DispatchManagerActions.cc | 90 +++++++++++</font></div>
<div><font face="'courier new', monospace"> src/lcm/LifeCycleActions.cc | 68 +++++++++-</font></div><div><font face="'courier new', monospace"> src/lcm/LifeCycleManager.cc | 48 ++++++</font></div>
<div><font face="'courier new', monospace"> src/lcm/LifeCycleStates.cc | 123 +++++++++++++++</font></div><div><font face="'courier new', monospace"> src/mad/ruby/VirtualMachineDriver.rb | 56 +++++--</font></div>
<div><font face="'courier new', monospace"> src/oca/ruby/OpenNebula/VirtualMachine.rb | 27 +++-</font></div><div><font face="'courier new', monospace"> src/rm/RequestManager.cc | 4 +</font></div>
<div><font face="'courier new', monospace"> src/rm/RequestManagerVirtualMachine.cc | 105 +++++++++++++-</font></div><div><font face="'courier new', monospace"> src/vm/VirtualMachine.cc | 3 +</font></div>
<div><font face="'courier new', monospace"> src/vmm/VirtualMachineManager.cc | 231 +++++++++++++++++++++++++++--</font></div><div><font face="'courier new', monospace"> src/vmm/VirtualMachineManagerDriver.cc | 72 +++++++++-</font></div>
<div><font face="'courier new', monospace"> src/vmm_mad/dummy/one_vmm_dummy.rb | 8 +</font></div><div><font face="'courier new', monospace"> src/vmm_mad/exec/one_vmm_exec.rb | 42 +++++-</font></div>
<div><font face="'courier new', monospace"> src/vmm_mad/exec/one_vmm_sh | 2 +-</font></div><div><font face="'courier new', monospace"> src/vmm_mad/remotes/xen/scale_memory | 26 ++++</font></div>
<div><font face="'courier new', monospace"> src/vmm_mad/remotes/xen/scale_vcpu | 26 ++++</font></div><div><font face="'courier new', monospace"> src/vmm_mad/remotes/xen/xenrc | 3 +-</font></div>
<div><font face="'courier new', monospace"> 29 files changed, 1204 insertions(+), 83 deletions(-)</font></div><div><br></div><div>Thank for your help,</div><span><font color="#888888"><div><br></div>
<div>Paul Grandperrin</div>
</font></span><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
<br></blockquote></div><br></div>