I like the idea.  Other tests which would be useful:

-check VM host license expiration dates
-check if the network names defined in the VM profile are available on
the VM hosts
-check amount of space available for VM host datastores, management
node repository, and management node volume where vcld.log is being
-make sure required attributes are defined for VMs such as MAC
addresses if they are not auto-generated
-check if time is sychronized on VM hosts, management node, and the
database server
-send a test sysadmin email message

The architecture of 'vcld -setup' hasn't been discussed on this list
so now is a good time to begin.  The idea is for vcld to handle all of
the details so that any module just needs to implement a subroutine
named 'setup' and it automatically gets added to the menu.  This
allows any module to contain options specific to itself but results in
a somewhat clunky menu system.

It would be good to have a single menu option where all of the tests
appear yet still allow each module to implement it's own test code.
In order to do this, the setup_management_node sub in vcld will need
to be extended.  I had thought about adding something like this in the
past but never completed it.  I was thinking of adding code to vcld to
look for modules which implement a 'setup_check' subroutine (the same
way it looks for 'setup') and then put all of these under a single
menu option.

There are a few bits and pieces to look at in the current code.  There
is a setup_check subroutine in Windows.pm.  It simply gets called by
Windows.pm::setup every time it is run.  It only checks if product
keys have been configured.  The Module.pm::setup_test_rpc_xml
subroutine would be another one that would be part of this.


On Thu, Jan 12, 2012 at 9:45 AM, Aaron Coburn <acob...@amherst.edu> wrote:
> Hi, Guys,
> The web front-end to the VCL has a "testsetup.php" script that tests a 
> variety of server settings so that the web code is easier to install.
> I am wondering if there might be interest in building a similar facility into 
> the vcld -setup script. It seems that many of the questions posed on this 
> (and the users') list relate to misconfigured networks and/or provisioning 
> module components. Clearly, the vcld logfile captures all of this, but even 
> that is often turned over to the list for interpretation. This could be a 
> sort of 'dry run' image capture.
> So here is a stab at what might be useful for such a script to check. My list 
> will be biased heavily in favor of the VMware provisioning modules, because 
> that's what we use in our installation. And I am assuming that the output 
> would be something easy to understand.
> Network:
> 1. can vcld get an IP address from a vmhost 'short name'
> 2. can vcld get an IP address from a given computer 'short name'
> 3. can vcld reach to the running VM(s)
> 4. can vcld reach to the VM host
> 5. can vcld transfer a file to/from the vm host
> 6. if the image library is enabled, is that accessible
> Computer:
> 1. is cygwin installed and sshd running (for Windows)
> 2. can vcld login successfully
> 3. does the computer have network access
> 4. do the computer's MAC addresses match what is expected in the database
> VM Host:
> 1. can vcld login to the vm host
> 2. are the paths listed in vmprofile available in the vmhost infrastructure
> 3. are certain utilities and/or commands available to vcld from inside the 
> vmhost (i.e. copy virtual disk, create a vm, etc.)
> etc, etc.
> Thoughts?
> Aaron
> --
> Aaron Coburn
> Systems Administrator and Programmer
> Academic Technology Services, Amherst College
> (413) 542-5451 acob...@amherst.edu

Reply via email to