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

[Ruben S. Montero]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20130308/e5705690/attachment-0002.htm>