ESX provisioning module

[Brian Bouterse <bm...@ncsu.edu>]

Centennial Networking Lab has started writing an ESX provisioning  
module for VCL, and we have proof-of-concept VCL module code that is  
doing successful deployments of virtual machines to an ESX 3i  
hypervisors.

We have a few questions:

1)  Where does the responsibility of the provisioning module stop.   
Right now we have the module copying the files, registering the VM,  
and turning it on.  Do we need to do anything else, or is that too  
much?  (such as waiting for the machine to boot before returning)

2)  How do we deal with cleaning a hypervisor up after the reservation  
is complete?  With the current architecture, there is no  
deprovisioning API for the modules, which VCL could call when a  
reservation is done, so we can unregister and clean up the VM. That  
would seem like the best way to do this, but until then, we need to  
find a workaround. Since VMs are currently based on slots, we can  
identify them by their slot name/number and clean them up when the  
next provisioning load event happens for that slot.  Does this sound  
like an appropriate solution for now?

3)  What variable is the slot name/number in the datastructure handed  
to the module?

4)  How should the virtual machines users get setup with our module?   
Are the OS module components functional enough, or do we need to add  
code in our provisioning module for this?

Thanks!
Brian & Andrew

Brian Bouterse
Secure Open Systems Initiative
919.698.8796

Re: ESX provisioning module

[Aaron Peeler <aa...@ncsu.edu>]

You probably want to trace through vmware.pm and xCAT.pm - if you haven't 
already, but I'll summarize below.

At a minimum you should have these routines:

node_status - checks/confirms status of node - returns ready or reload
does_image_exist - checks image repos - for image files/templates, etc 
calls retrieve_image if needed
load - loads the vm
capture - image creation

These routines are internal to vmware.pm
retrieve_image - in a multiple management node/image library setup - 
fetches image files via scp
control_VM - sort of your de-provisioning , turns off removes vms
get_image_size - for recording in the database image/imagerevision table

>
> We have a few questions:
>
> 1)  Where does the responsibility of the provisioning module stop.  Right
> now we have the module copying the files, registering the VM, and turning
> it on.  Do we need to do anything else, or is that too much?  (such as
> waiting for the machine to boot before returning)
>

The provisioning module is responsible for making sure the node is up, 
running and accessible.

Then returning success/failure to the new module.

So it would need to:
* setup any files - copy, register
* start the load - turn on
* make sure it's loading - checking the vm state, checking any log files, 
etc and recording the state via using the insertloadlog routine.
* wait until the vm is ready for use - perform any post actions, make sure 
firewall settings are right, randomize the passwords for the admin 
accounts(root[if being used],administrator). In the xCAT.pm and vmware.pm 
this a loop with counters to prevent any infinite loop scenarios
* return success/failure to the calling state(new/reclaim)

Then new.pm will proceed to either add users, create image, or mark node as 
available depending on the requested state (new,reload,image)

> 2)  How do we deal with cleaning a hypervisor up after the reservation is
> complete?  With the current architecture, there is no deprovisioning API
> for the modules, which VCL could call when a reservation is done, so we
> can unregister and clean up the VM. That would seem like the best way to
> do this, but until then, we need to find a workaround. Since VMs are
> currently based on slots, we can identify them by their slot name/number
> and clean them up when the next provisioning load event happens for that
> slot.  Does this sound like an appropriate solution for now?

This is initiated through reclaim - by inserting a reload request.

The logic in vmware.pm load routine is to first call control_VM("remove")

load is only called if it needs to be loaded - either new load or reload 
after a reservation, or wrong image is loaded. Whether it needs to be 
loaded/reloaded determined by node_status

>
> 3)  What variable is the slot name/number in the datastructure handed to
> the module?

not sure I understand, are you referring to the node name and it's details?

by using
$self->data->get_<some_variable>

you can get pretty much any variable in the data hash. Look in 
lib/VCL/DataStructure.pm for the list of variables that can be  retrieved

>
> 4)  How should the virtual machines users get setup with our module?  Are
> the OS module components functional enough, or do we need to add code in
> our provisioning module for this?

This is split up right now and we should probably make this more generic.

In new.pm
- for new requests, once a node is ready(vm,blade,standalone lab machine)
If it is windows OS - the add_user routine is called, this adds a user to 
the windows OS.
If it is Linux OS - add_user is called in reserved.pm when user 
acknowledges reservation

In reserved. two methods new and old
once the user hits the "connect" button (acknowledges the reservation)
if ($self->os->can("grant_access"))

Andy add more if I'm missing something
grant_access comes from the os module - this routines opens the firewall 
with the users incoming src IP

Hope this helps.

If you can send the code chunk in (maybe in a sandbox branch) - we can look 
over it.

Aaron