Aaron Peeler wrote:


--On October 9, 2009 12:07:54 PM -0400 Sean Dilda <s...@duke.edu> wrote:

1. Use API calls instead of provided perl scripts -  My experience
writing cacti and nagios checks with the VIPerl Toolkit has shown that
there's a heavy CPU hit for a few seconds while perl processes all of the
VIPerl libraries.  Calling those scripts several times in the loading can
cause problems with larger VCL deployements.  Rewriting it to use the API
calls should reduce that CPU hit to once per reservation.


Is it a REST or xmlrpc api? There's an xmlrpc_call routine in utils.pm that could be used, for REST calls another one would need to be added.


Its SOAP, but I'll be using the VMware provided libraries to access it. When you download the VIPerl Toolkit from VMware, it gives you perl libraries for writing code to talk to VMware, as well as a few small scripts using those libraries to do some basic actions. Those scripts are used by the current esx.pm (and a small bit of the library for some MAC address stuff). My code does everything through the VMware-provided perl libraries.


2. Base the new vmx on the image's vmx.  This allows the image creator to
customize the VM hardware and we will carry those settings along.

3. Remove dependency on ssh/scp to ESX host.  This will make it easier to
setup for ESXi, as well as allowing deployments to use vCenter and deploy
to a cluster instead of to an individual host.

Sounds like a good approach. We may need to make #3 optional depending on the different storage options being used as a datastore, etc.

Just to be clear, by removing the dependency on ssh/scp, I'm doing all the file I/O through VMware instead of connecting to the host underneath. This means any backend datastore VMware talks to can be used with this method.


I also looked through the vmware.pm and had a question that I'm hoping
someone can answer.  In the load() subroutine, the module checks through
/var/log/messages for dhcpd responses before checking on ssh.  What is
gained by doing this?  It seems this could be cleaned up by just checking
with pings and ssh attempts.  This would simply the code, as well as
removing the dependency of running dhcpd on your management node.  We're
planning on using our campus DHCP servers for our VCL environment, so
avoiding that dependency would be a big plus for us.


Correct these could be changed. Source the messages log is a left-over logic from xCAT1.3 that got ported into the vmware.pm. We'd need to check, but I think some of those checks correspond loading status window. But it can definitely be cleaned up.


That sounds good.


Thanks,


Sean

Reply via email to