[one-users] one_vmm_xen driver (not) in 2.0

Jaime Melis j.melis at fdi.ucm.es
Mon Nov 15 10:40:25 PST 2010


Hi Tres,

You have actually pointed out the main reasons to change the structure
of the VMM (and IM) drivers:

> 1) ease of deployment and management -- one_vmm now works more like other parts of OpenNebula(?)

The actions to be executed by the VMM drivers are now detached from
the ruby VMM driver and placed in scripts which are called from the
main driver. This is a big improvement because:
- They are more readable and therefore more easily hacked (like the TM drivers)
- They can be written in whatever language the worker node supports
- There will be only one SSH connection per action
- With the new IM drivers adding IM probes is much easier
- Actions (scripts) can be changed during run-time, without the need
of restarting oned
- They are easier to debug

> 2) performance -- spawning a shell process to handle ssh interaction scales better than calling ssh from ruby(?)

The main reason to change the structure of the VMM and the IM scripts
was precisely the performance. At some point with the old drivers we
had to establish several SSH connections to execute a single action
causing unnecessary overhead. With the new system there is exactly one
and only one SSH connection per action.

Also, since the scripts are already in the worker nodes, you don't
have to encapsulate them in each SSH connection, reducing again
unnecessary overhead.

> 3) bug related issues with one_vmm_xen

The Xen VMM scripts of OpenNebula 2.0 are more up-to-date with newer
Xen versions.

AFAIK you can plug the old Xen driver to OpenNebula 2.0. You might
have some issues, since some XML-RPC methods now have a different
number of parameteres, although they are quite few and it shouldn't be
very hard to adapt them to the new XML-RPC wrapper methods.

In any case I encourage you to try out the new drivers, and to
re-implement your customizations, it will be definitely easier to do
it now than it was for OpenNebula 1.4. The new drivers are more
reliable and they have better performance.

Hope this helps.

Regards,
Jaime


On Sat, Nov 13, 2010 at 1:15 AM, Tres Wong-Godfrey <tres at blas.phemo.us> wrote:
>
> Hi,
>
> So I've got a bunch of custom extensions built into one_vmm_xen under 1.4 that I'm working on porting over to 2.0. The problem is, that one_vmm_xen.rb no longer exists. It looks like it's been replaced by a combination of one_vmm_sh.rb and vmm_mad/remotes/xen/[command].
>
> I see that VirtualMachineDriver is essentially the same, which means that one_vmm_xen.rb should still work.
>
>  I'm thinking that the easiest way to keep things working is to just continue using the xen vmm driver. I can pretty easily test out whether there are any problems with that, but I'd really like to know why the changes were made in vmm so I can make a good long term decision here.
>
> The only possible reasons I can think of that the changes were made are:
>
> 1) ease of deployment and management -- one_vmm now works more like other parts of OpenNebula(?)
>
> 2) performance -- spawning a shell process to handle ssh interaction scales better than calling ssh from ruby(?)
>
> 3) bug related issues with one_vmm_xen?
>
>
> Knowing whether the change was made for structural, performance or other reasons makes it easer for me to decide whether to re-implement the changes using the new driver schema or just try plugging in the old driver.
>
> Thanks so much for your time and any clarity you can give on this.
>
> And I do apologize if there is an RTFM answer for this; if there is, I haven't had much luck finding it.
>
> Regards,
> Tres
>
> Tres Wong-Godfrey
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org



More information about the Users mailing list