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 written -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. -Andy 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 > > > > >
