Uncategorized

You have a user on your machine and you only want to enable them to do things like rinv, rvitals, and nodels. You don’t want them to be able to provision nor power on/off and do all those other awesome things that xCAT can do.

So what do you do?

Suppose your user name is ‘foobar’.

You do this:
1. Set up the policy table so that it contains the following: (tabedit policy)

2. Set up the local cert for the user:

Any other commands you can add by adding another number, like 1.13, etc. The numbers are arbitrary, just make sure there is a unique number. They stand for the priority of access of how the commands are processed. (e.g: if two commands are received by the xCAT server at the same time.

I recently added the ESXi 4.1 base template kickstart file to xCAT.  The code is checked in here. We’ve had the ability to do stateless ESXi 4.1 since it came out and we’ve been doing stateless ESXi 4.0 as well.  But for some of our customers, we have needed a way to get the ESXi 4.1 server on the disk.  This seems to be the most common way people want to install VMware ESX(i) these days.  We hope in the future more people will go stateless.  But for now, here is our xCAT ESXi 4.1 base kickstart file:

Since this is an xCAT kickstart template then you see the #TABLE … # and #COMMAND ..# tags in there.  Basically these are just cues for xCAT to look up the different attributes for the nodes so that it can customize this one template to be used on the entire data center.  So the password, main HTTP server, and xCAT server are all stored in the xCAT database.

I have two scripts in here.  The first is the %post.  This script simply signals back to xCAT that it is done installing so that the next time it reboots, instead of reinstalling, xCAT will tell the node to boot to hard disk. This happens right after the install.

The second is the %firstboot script.  Notice that I added the –level 47 to the script.  This is important as it tells this script when to run.  If you look at /etc/vmware/init.d/init you’ll see the levels.  Level 48 starts the networking.  Before the networking starts, I want to enable SSH, so I just uncomment the section inside /etc/inetd.conf to allow SSH to happen on boot.  (Another thing you could do is just do an /etc/init.d/TSM-SSH start)

So this template is stored in xCAT in /opt/xcat/share/xcat/install/esx/.  You can have a node boot to it (provided the rest of xCAT is setup and copycds have been run) by doing the following:

nodeset <noderange> install=esxi4.1-x86_64-base
rpower <noderange> boot

or just:

rinstall <noderange>

Then the template is copied into the /install/autoinst/ directory and the name is changed to match the node and all variables are substituted in.  Then the PXE server and DHCP server are set to point to the file to grab and install the node.  This is in xCAT 2.5 which you can get now as the development release (make sure you grab the files at the bottom in the ‘Development Builds’ section)

Another thing that is fun to do with the ESXi kickstart file is to make a new VM as part of the kickstart install.  Generally I recommend using an NFS server to store your VMs on, but there are cases where you just want them on the local drive.  As part of the above kickstart file, the datastore1 partition is created.  This is a place where you could now run the vim-cmds during post to create machines.  This is easy to do during the firstboot section (you would probably do this at level 99) but not so easy to do in the %post section.

The problem with the %post section is that hostd isn’t running so none of the vim-cmds will work.  So you have to start it.   This can be done by running:

/etc/init.d/hostd start

But wait, there is another problem!  The hostd command doesn’t return and hangs!  So you have to use some magic (like creating a script to run it that forks off and returns) otherwise your %post hangs forever. (This is a total bug)

Anyway once you work around that then just running the commands like:

/bin/vim-cmd solo/registervm /vmfs/volumes/datastore1/vm01/vm01.vmx vm01
/bin/vim-cmd vmsvc/power.on 16

Seems to work.  But, during %firstboot, you’ll have to reregister them again.

I hope to put more information on this as we go forward with it.  I am happy that VMware has made this kickstart file for 4.1 and I can only see it improving over time.  The more automation the better and with kickstart we can really automate everything we need.

I’ve been getting back to playing with the VMware API and I’ve completely forgotten everything, so I’m starting off simple. Here is a simple script to connect to a host and to list the names of the VMs that are on it:

#!/usr/bin/perl

use Data::Dumper;
require VMware::VIRuntime;
VMware::VIRuntime->import();
1;

# try logging into a node:
my $conn;
my $hyp = 'vhost31'; # you can make this an option to pass in as well.
eval {  
 $conn = Vim->new(service_url=>"https://$hyp/sdk");
 $conn->login(user_name=>'root',password=>'cluster');  # here are some easy root password stuff you need to change.
};
# make sure the connection worked
if($@){
 print "Couldn't connect:  $@\n";
 exit 1;
}
my $entity_views = $conn->find_entity_views(view_type => 'VirtualMachine');
foreach my $ev (@$entity_views){
 print $ev->name . "\n";
}
$conn->logout();

That’s pretty much it.  Notice that I just printed the name.  There are a lot of other things you could print as well on it if you wanted to.  Just do a print Dumper($ev) and you’ll see the possibilities.