[one-users] Info about one.vm.resize in upcoming 4.0

[Carlos Martín Sánchez]

Hi Simon,

We decided to implement your suggestion. The CLI command stays the same,
but internally the call is done with a template and the restricted
attributes are enforced.

It makes perfect sense and is consistent with the attach methods, that also
require a template.

Thanks for your feedback, keep it coming!

[1]
http://dev.opennebula.org/projects/opennebula/repository/revisions/e1e4eb34f5e5c813590a78f15e4a4da834faf9c5
--
Carlos Martín, MSc
Project Engineer
OpenNebula - The Open-source Solution for Data Center Virtualization
www.OpenNebula.org | cmartin at opennebula.org |
@OpenNebula<http://twitter.com/opennebula><cmartin at opennebula.org>


On Fri, Mar 8, 2013 at 11:38 PM, Ruben S. Montero
<rsmontero at opennebula.org>wrote:

> Hi Simon
>
> 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?
>>
>
> The process is described here:
>
> http://opennebula.org/documentation:rel4.0:vm_guide_2#resizing_a_vm
>
> let us know if you miss something...
>
> 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).
>>
>
> You can use the accounting data for this:
>
> http://opennebula.org/documentation:rel4.0:accounting
>
> It will account the capacity changes and how much time those changes were
> active...
>
> Note that the VM ID is not changed during the VM lifetime
>
>
>> 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?
>>
>
>  The template is updated, but the VM is not rescheduled. The operation can
> be made only in some states. This is a cold resize...
>
> 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.
>
>
>> 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.
>>
>
> 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:
>
> 1.- The user template with VM tags, can be freely updated
>
> 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...
>
> So we came out with two different methods to update this two different
> information:
>
> 1.- User template is updated using the standard update operation and may
> take a template.
>
> 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...
>
> Cheers
>
> Ruben
>
>
>>
>> Thanks
>>
>> Simon
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opennebula.org
>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>
>>
>
>
> --
> Ruben S. Montero, PhD
> Project co-Lead and Chief Architect
> OpenNebula - The Open Source Solution for Data Center Virtualization
> www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20130311/99ece0ce/attachment-0002.htm>