Posted on

vCloud Automation Center vCAC 6.0 – Using Linux Kickstart to Provision to Physical HP Server over iLo

That big ole title pretty much says it all. In this article I’m going to walk through how to deploy RHEL (Centos) Linux onto a Physical HP Server over the iLo interface using Kickstart. When provisioning to Physical servers such as an HP Proliant DL360 there are two methods built into vCAC. One is the use of PXE boot, and the other is via the iLo interface.

There are pro and cons to both PXE and remote mounting an ISO over the iLo interface. PXE has the obvious cons of the network requirements, having a PXE server available and if you want true flexibility you will need to do a little custom work. ISO mount over iLo tend to be a bit slower due to the over head of remote mounting a ISO and the speed of the iLo interface. In this article I will be covering remote mounting an ISO over iLo, but I will be covering PXE is a later article.

What do we need

To start we need the Physical HP server to be racked and cabled up. It’s iLo interface should be configured and licensed, the network interfaces should be cabled in and the switches should be configured for the appropriate Vlans etc. The drives in the server should also be initialized. vCAC will not create any raid groups etc for you, you must do this manually. My examples also requires a web server that can be utilized to store the needed files on the network.

Continue reading “vCloud Automation Center vCAC 6.0 – Using Linux Kickstart to Provision to Physical HP Server over iLo”

Posted on

DailyHypervisor Forums are online.

We have just launched our DailyHypervisor Forum located at http://www.dailyhypervisor.com/forum. Stop by, contribute and be a part of our community. The DH Forum is intended to be for all things cloud. Currently we have forums created for vCAC, vCD, vCO, Cloud General, and Openstack. More forum categories will be coming based on demand. If you have a category you would like to see shoot us a note and let us know.

Our goal is to create a common place where anyone can come to learn, get help, share ideas, or just about anything that will help foster knowledge regarding cloud computing. Considering this very blog is the announcement of our forum you could image there isn’t a whole lot happening yet so what are you waiting for, be the first. Go ask a question, post an issue, share a thought and let’s get things rolling.

Posted on

vSphere Service Console and Disk Partitioning

Everyone at this point should be aware that the Service Console is now located in a vmdk on a VMFS partition.  The Service Console vmdk must be stored on a vmfs datastore and the datastore must either be local stoage or SAN storage that is only presented to the one host.  So I guess no shared vmfs datastores to house all the Service Consoles…….  The next question I had about the new service console was the /boot partition.  Where is it and how is the server bootstrapping?  Well I can’t say I have totally gotten to the bottom of this yet but I have discovered a few things.  When digging into scripting installations of vSphere I first looked at the disk partitioning which sheds a little light on the boot process.  Here is what the disk partitioning portion of the script looks like:

part /boot –fstype=ext3 –size= –onfirstdisk
part storage1 –fstype=vmfs3 –size=30000 –grow –onfirstdisk
part None –fstype=vmkcore –size=100 –onfirstdisk
# Create the vmdk on the cos vmfs partition.
virtualdisk cos –size=8000 –onvmfs=storage1
# Partition the virtual disk.
part / –fstype=ext3 –size=0 –grow –onvirtualdisk=cos
part swap –fstype=swap –size=1600 –onvirtualdisk=cos

Notice the “onfirstdisk” switch at the end of the first three partitions.  The /boot, a vmfs partition, and a vmkcore partition are all on the physical disk.  Notice the swap for the service console is located inside the vmdk.  Notice the creation of the service console vmdk disk.  “virtualdisk cos –size=5000 –onvmfs=storage1”.  To account for this change VMware has added some new configuration option for scripting the installation of the COS.  Next you’ll notice the  the creation of the / and swap partitions fort the COS utilizing the “onvirtualdisk=cos” switch.

I’m still working on and discovering some of the new ways to do scripted installation with vSphere 4.0.  I though this little tid bit would be helpful to those of you wondering how the COS ties in to the whole mix.  A few interesting things about this new method.

No need to specify the actual device, however I would be very cautious about the –onfirstdisk switch if SAN LUNs are present on the server.  I would take extra precautions to ensure that no SAN LUNs are connected.  There really are not any best practices around this configuration yet so there are a few things that I think need to be determined.  If you were planning on running VM’s from the local VMFS should you create multiple VMFS partitions and have one solely for the COS.  I almost think it would be beneficial just for the logical separation.  Well I will be digging a bit deeper into this but would love to hear others views on the COS and how they plan to deploy and why.  So please comment and let me know what you think.

Posted on

ESX automated deployment email completion notification

How would you like to kick off your ESX installation, then go have some coffee, go for a jog, or just hang out by the water cooler until it is finished without worrying if you’re wasting time while it’s waiting done and waiting for you. Well you can with this ESX email script. Incorporating this script as part of your ESX automated deployment script allows you to configure your server to email you once the post installation configuration is finished.

So what do you need to do? It simple you can get the mail_notify script that I found on yellow-bricks.com from our downloads page. Once you have the script you will need to get it on to your server along with the MIME Lite.pm file that you can download here. Once you download and extract the package you can find the Lite.pm file under /lib/MIME/ folder.

The take the Lite.pm file and the mail_notify.pl file and tar them together for easy retrieval. Then upload the mail_notify.tar file to your web server. Next include the following in your automated deployment script.

##### Setting up Mail Notification ########
echo Setting up mail notification
echo Setting up mail notification >> /var/log/post_install.log

cd /tmp
lwp-download http://[server ip]/path/mail_notify.tar
tar xvf mail_notify.tar
mkdir /usr/lib/perl5/5.8.0/MIME
mv Lite.pm /usr/lib/perl5/5.8.0/MIME/

##### Move the files to where they belong #######
mv mail_notify.pl /usr/local/bin/
chmod +x /usr/local/bin/mail_notify.pl

####### Let’s send an email that the install is finished #####
/usr/local/bin/mail_notify.pl -t youremail@yourdomain.com -s “Server installation complete” -a /var/log/post_install.log -m “Server Installation complete please review the attached log file to verify your server installed correctly” -r [your smtp server]

Optionally you could set the smtp server in the mail_notify.pl script and not have to specify when sending a mail message.

if you include this at the end of your post installation portion part of your script but before the EOF line you will get a nice email notification informing you that your installation has finished with the post_install.log file attached.

Posted on

Network configuration for automated ESX deployment

I have been asked this question a few times so I thought it would be wise to post an article on it. When deploying an automated build script with the kickstart and/or installation files located on http, ftp, or nfs there are network configuration dependencies that you need to be aware of.

The ESX installer is a modified version of anaconda which is the same installer used for RedHat and a few or Linux variants. Anaconda is what allows for the kickstart portion of the automated build script. Anaconda itself has some limitations as far as what it supports.

Anaconda does not support 802.1q VLAN tagging. If you plan on tagging the service console network traffic this will affect your kickstart installation. The anaconda installer will not tag the vlan id to the traffic and therefor will not be able to perform the installation. You have a few options on how to handle this.

  1. Don’t have the networking folks tag the vlan until after the install finished.  However this can cause problems if your post installation script needs to grab some files from across the network so be aware of what you are doing during your post installation.

  2. Use a dedicated deployment network.  If you use this option take a look at my ESX 3.x Deployment script #2 located on our download page.

  3. Don’t tag the service console traffic.  If you share vSwitch0 with both the vmkernel(vMotion) interface and the service console only tag the vmkernel traffic.  This still allows for isolation of the traffic.  Have your network guys set the service console vlan as the native(untagged)vlan.

  4. Create a custom installation CD with all the necessary files located on the CD.
Posted on

ESX local disk partitioning

I had a conversation with some colleagues of mine about ESX local disk partitioning and some interesting questions were raised.

How many are creating local vmfs storage on their ESX servers?
How many actually use that local vmfs storage?

Typically it is frowned upon to store vm’s on local vmfs because you loose the advances features of ESX such as vMotion, DRS, and HA. So if you don’t run vm’s from the local vmfs, then why create it? Creating this local datastore promotes it’s use just by being there. If you’re short on SAN space and need to deploy a vm and can’t wait for the SAN admins to present you more storage, what do you do? I’m sure more frequently than not you deploy to the local storage to fill the need for the vm. I’m also sure that those at least 20% of the time those vm’s continue to live there.

Is the answer to not utilize local vmfs storage? If you don’t what do you do with the left over space? Not all servers are created equal, sometimes servers have different size local drives so you have a few options. Do you create standards for your partitioning and set a partition such as / to grow and have varying configurations amongst your hosts? Or do you create a standard for all partition sizes and leave the rest of the space raw?

Typically this is the partition scheme I use for all deployments I do.

Boot = 250 (Primary)
Swap = 1600 (Primary)
/ = Fill (Primary)
/var = 4096 (Extended)
/opt = 4096 (Extended)
/tmp =4096 (Extended)
/home =4096 (Extended)
vmkcore = 100 (Extended)

This configuration will create inconsistencies amongst hosts with varying drive sizes. To maintain consistency I could do something like the following and leave the rest of the space raw.

Boot = 250 (Primary)
Swap = 1600 (Primary)
/ = 8192 (Primary)
/var = 4096 (Extended)
/opt = 4096 (Extended)
/tmp =4096 (Extended)
/home =4096 (Extended)
vmkcore = 100 (Extended)

I’m a fan for utilizing all the space you have available, but others like consistency. What is your preference? Weight in an let us know.

Posted on

Using the Ultimate Deployment Appliance to test ESX kickstart scripts – Part II

In Part 2 of this series we are going to deploy our virtual ESX host in a VMware Workstation 6.5 virtual machine. We will utilize the UDA setup that we created in the first part to this series. If you haven’t setup your UDA you will want to do so before proceeding. Make sure you check out the sample deployment scripts available on our download page. In this example I am deploying VMware ESX 3.5 Update 4 in VMware Workstation 6.5 build 126130.



Posted on

Using the Ultimate Deployment Appliance to test ESX kickstart scripts – Part I

In this series I am going to walk you through setting up the Ultimate Deployment Appliance (UDA) and VMware Workstation 6.5 to test Automated ESX Deployment Scripts (kickstart).  The same principals that you will learn in this video also apply to using the UDA in a physical environment. The UDA is a very powerful appliance and I have found many uses for it. Using it as a medium to quickly and effectively test deployment scripts that I develop is just one.

Even in environments where the UDA is not allowed it can still be utilized. I regularly carry a 5 port gigabit switch which I can use to connect to my laptop to up to (4) servers to quickly deploy up to (4) ESX hosts at a time.



Posted on

Deploying Automted Kickstart Scripts Over HTTP

Originally I was going to cover all the various options for initiating your automated kickstart installation as “Automated Deployment of ESX Hosts Part IV”, but I have since decided to cover each method individually as there is a lot to cover and it makes more sense to break them out.

In this post I am going to cover deploying your servers over the network utilizing HTTP. To begin you will need a few things in place for this to work.  Below is a list of what you will need:

  • Web Server to hosts the kickstart files and optionally your ESX installation.
  • ESX Installation media or ISO’s for all versions of ESX you plan to deploy
  • Your kickstart script

The first thing we need to do is setup our web server so we can host our kickstart files and optionally our installation files.  You can utilize apache, IIS, or whatever your favorite web server is for hosting HTTP.  You will need to configure a folder under your web server root for the files to be stored.  Below is my recommended structure.

-webroot
—deployment
——ESX35U1
——ESX35U2
——ESX35U3
——ESX35U4
——kickstart

Once the folder structure is created we need to copy the contents of the installation media to the respective folder. To do this you will literally copy everything on the CD and place it in the folder. Then next you will need to copy your kickstart.cfg files to the kickstart folder.

Once you have all the files uploaded to the web server it is a good idea to use your web browser to test that you are able to access them.

As part of our kickstart we define where we are going to be installing from with the following line replacing server_IP with your server IP address and ESX25U4 with the version you would like to install.

url –url http://server_IP/deployment/ESX35U4

If you wanted to pull just your kickstart.cfg files form the http server but install from the local CD media you would replace the above string with “cdrom” to let the kickstart know to look to the cdrom drive for the installation media.

Now that we have our web server up, our installation copied to our webserver, and our kickstart.cfg files on the server we can kick off our kickstart installation.

To do this we need to boot the server from the installation CD. You can boot from the CD in the cdrom drive or remote mounted over a lights out port like iLo, DRAC, or RSA. If you are going to remote mount the CD over a lights out connection you can use a much smaller portion of the ESX CD.

On your ESX installation media there is an iso file named boot.iso located under the “images” folder on the CD. You can extract that ISO image which is roughly 4mb and remote mount that to your server for the boot process if you intend to install over HTTP.

OK so now we boot off of our media either the full ESX CD or the boot.iso image and when the ESX installation screen appears we need to tell the installation where to find the kickstart file. There are a couple of options for this which are below:

If you are using dhcp then your installation string will look similar to the below string:

esx append ip=dhcp ksdevice=eth0 network ks=http://server_name/deployment/kickstart/kickstart.cfg

If you are not using dhcp it would like similar to the follow string:

esx append ip=192.168.1.2 netmask=255.255.255.0 gateway=192.168.1.1 ksdevice=eth0 network ks=http://Server_IP/deployment/kickstart/kickstart.cfg

The statement ksdevice=eth0 tells anaconda (the installer) to use the eth0 interface for the install. I recommend always using eth0 for your installs. ESX will by default make the install interface the Service Console interface. So it will become the interface that is assigned to vSwitch0.

If you are using a seperate kickstart file for each server then you can call each one by name. If you are using a script like the one I discuss here then you will only need to have one kickstart file.

Posted on

ESX 3.x Deployment Script # 3

This script is very similar to ESX 3.x Deployment Script #1, but I made a handy change. I built this script to allow for easier modification for each ESX host you want to deploy. Once you change all the settings you need changed there is one important area where you will add information about all your ESX hosts.

Below if the area that you will need to be concerned with:

if ['hostname -s' == "esxhost1" ] ; then
esxcfg-vswif -i [Service_Console_IP] -n [Service_Console_Netmask] vswif0
esxcfg-vmknic -a -i [VMKernel_IP] -n [VMKernel_Netmask] "vMotion"
fi

You will create this if statement for each of your esxhosts you want to deploy. Once you setup each servers information in this area all you need to do is change the hostname to match the server you are deploying and that is it. If you use dhcp to set the initial installation IP and it is able to resolve to the appropriate hostname then you won’t even have to change the script.

For example if you change this line:

network --device eth0 --bootproto static --ip [SC IP ADDRESS] --netmask [SC NETMASK] --gateway [SC GATEWAY] --nameserver [NAMESERVERS comma serperated] --hostname [HOSTNAME] --addvmportgroup=0

to the following:

network --device eth0 --bootproto dhcp

and then add the following setting the appropriate IP addresses and hostnames:

if ['hostname -s' == "esxhost1" ] ; then
esxcfg-vswif -i [Service_Console_IP] -n [Service_Console_Netmask] vswif0
esxcfg-vmknic -a -i [VMKernel_IP] -n [VMKernel_Netmask] "vMotion"
fi

if ['hostname -s' == "esxhost2" ] ; then
esxcfg-vswif -i [Service_Console_IP] -n [Service_Console_Netmask] vswif0
esxcfg-vmknic -a -i [VMKernel_IP] -n [VMKernel_Netmask] "vMotion"
fi

and you setup each ESX server in dhcp and DNS you will never need to modify this script. You need to ensure that the DNS and gateway that the server initially get’s from DHCP are correct. If you are doing this on a different subnet then what you will be running your ESX server on then you will need to do this a little differently. This can be done with my ESX 3.x Deployment Script #2.

I have included a script with this code included in our download section.