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
-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
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.
> 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
> 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.
> Aaron Coburn
> Systems Administrator and Programmer
> Academic Technology Services, Amherst College
> (413) 542-5451 acob...@amherst.edu