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

[Simon Boulet]

Hi Carlos, Ruben,

Thanks for the feedback!

That's not exactly what I was thinking.

Although I can see the advantage of the call taking a template ex. for
someone that want resize to handle more than CPU, VCPU and MEMORY, the
resize operation could be extended to more attributes later without
changing the API call (ex. here we use an IOPRIO attribute that sets an I/O
limit on the VM, BANDWIDTH to set a maximum network bandwidth in Mbps for
the VM). Perhaps later a VM_RESIZE_ATTR configuration option could be
available to allow the administrator to provide a list of the attributes to
me looked / updated on resize operation (ex. in our case that could include
IOPRIO and BANDWIDTH attributes).

My idea was the vm.resize option to be closer to template.instantiate. It
would take the ID of an existing template, and read the attributes to be
resized from there (as well as perhaps updating or logging the ID of the
new template for template ID accounting/billing purposes). In my case, we
enforce the user to choose from the list of template we provide (much like
the EC2 small / medium / large) and we bill them according to the template.
We have the CPU, VCPU and MEMORY attributes restricted (among others)
preventing our users from creating their own template.

Simon



On Mon, Mar 11, 2013 at 10:52 AM, Carlos Martín Sánchez <
cmartin at opennebula.org> wrote:

> 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/fd6574df/attachment-0002.htm>