<div dir="ltr">Hi Simon<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>I noticed the one.vm.resize call in the upcoming 4.0. Can you provide a little more information about how this is going to work?</div></div></blockquote><div><br></div><div style>The process is described here:</div>
<div style><br></div><div style><a href="http://opennebula.org/documentation:rel4.0:vm_guide_2#resizing_a_vm">http://opennebula.org/documentation:rel4.0:vm_guide_2#resizing_a_vm</a><br></div><div style><br></div><div style>
let us know if you miss something...</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>Currently I am relying on the VM ID to account my clients for each of their VM usages (according to the CPU, MEMORY, VCPU). Those attributes are checked only the first time I am seeing a new VM ID cause I assume that this information will not change for the lifetime of the VM (the lifetime of that VM ID).</div>
</div></blockquote><div><br></div><div style>You can use the accounting data for this:</div><div style><br></div><div style><a href="http://opennebula.org/documentation:rel4.0:accounting">http://opennebula.org/documentation:rel4.0:accounting</a><br>
</div><div style><br></div><div style>It will account the capacity changes and how much time those changes were active... </div><div style><br></div><div style>Note that the VM ID is not changed during the VM lifetime</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>When the user submit a one.vm.resize call, the information is updated in the template and the VM rescheduled? The VM will be rescheduled with the same VM ID?</div></div></blockquote><div><br></div><div style>
The template is updated, but the VM is not rescheduled. The operation can be made only in some states. This is a cold resize...</div><div><br></div><div style>Regular users need to add --enforce to the resize request, so the capacity of the target host is checked and no over-commitment occur. If you want to resize a VM and over-commit host resources you require admin privileges.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>
Another thought, why doesn't the one.vm.resize call takes a template ID as parameter instead of explicit CPU, MEMORY and VCPU? In my case the CPU, MEMORY and VCPU are restricted attributes, I want my users to conform to the templates I provide.</div>
</div></blockquote><div><br></div><div style>We have also added VM tags for OpenNebula 4.0, so users can tag VMs with custom data (e.g. description of the VM, last update... whatever). So we have two templates:</div><div style>
<br></div><div style>1.- The user template with VM tags, can be freely updated</div><div style><br></div><div style>2.- The vm template with runtime information (disk sources, mac addresses....) This information is kept and updated by OpenNebula. Restricted attributes apply when the VM Template is created to check for potential dangerous attributes like VLAN_IDs...</div>
<div style><br></div><div style>So we came out with two different methods to update this two different information:</div><div style><br></div><div style>1.- User template is updated using the standard update operation and may take a template.</div>
<div style><br></div><div style>2.- Runtime VM information is updated by specialized operations (attach/detach disk for DISK, attach/detach nic for NICs, resize for CPU/MEMORY/VCPU...) note that these operations usually require additional actions on the hypervisor, e.g. regenerate deployment files, disk image transfers...</div>
<div><br></div><div style>Cheers</div><div style><br></div><div style>Ruben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>Thanks</div><span class=""><font color="#888888"><div><br></div><div>Simon</div></font></span></div>
<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org">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><br clear="all"><div><br></div>-- <br>Ruben S. Montero, PhD<br>Project co-Lead and Chief Architect<br>OpenNebula - The Open Source Solution for Data Center Virtualization<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:rsmontero@opennebula.org" target="_blank">rsmontero@opennebula.org</a> | @OpenNebula
</div></div></div>