The VCL management node must be able to control the VM host and the VMs running on it. VMware provides several different ways of doing this. VCL currently supports the following methods for remote VM host management:
The vSphere SDK can only be used if management is not restricted due to the VMware license key installed on the host. This mainly affects hosts running the free version of ESXi. Remote management using any of the methods supported by VMware is restricted once a free license key is entered.
If remote management is restricted, the VM host can be managed if SSH is enabled on it. VCL will execute vim-cmd and other commands on the VM host via SSH.
Enable the SSH daemon and configure identity key authentication according to the underlying VM host OS
Beginning with ESXi 4.1, SSH can be enabled using the vSphere Client:
In the case of ESX 5.0:
SSH identity key authentication must be configured if SSH is used to manage the VM host.
Create an SSH key pair on the management node (or use a key you previously created):
ssh-keygen -t rsa -f /etc/vcl/vcl.key -N '' -b 1024 -C 'VCL root account'
Log into the ESX host via SSH (password authentication should work) and create the directory:
ssh <ESXi host> 'mkdir /.ssh'
Copy the public key to the ESXi host:
ESXi 4.x:
scp /etc/vcl/vcl.key.pub <ESXi host>:/.ssh/authorized_keys
ESXi 5.x:
scp /etc/vcl/vcl.key.pub <ESXi host>:/etc/ssh/keys-root/authorized_keys
Test making an SSH connection using the key:
ssh -i /etc/vcl/vcl.key <ESXi host>
IMPORTANT: Under ESXi 4.x, the authorized_keys file is erased when the ESXi VM host is rebooted. Complete the following steps to make the authorized_keys file persistent:
Note: VCL will perform these steps automatically when the 1st reservation assigned to the host is processed.
Create a compressed tarball file containing the /.ssh directory:
tar -C / -czf bootbank/vcl.tgz .ssh
Edit the /bootbank/boot.cfg file and append ' --- vcl.tgz' to modules line as shown in the following example:
kernel=b.z
kernelopt=
modules=k.z — s.z — c.z — oem.tgz — license.tgz — m.z — state.tgz — vcl.tgz
build=4.1.0-260247
updated=2
bootstate=0
Optionally you can run the following two commands:
tar -C / -czf vcl.tgz .ssh
BootModuleConfig.sh --add=vcl.tgz --verbose
Image (optional)
VCL hypervisor image installed on VM host computers using xCAT
xCAT is not required. VM host computers may be installed manually or by some other means.
Resource Path only needs to be configured if VMware vCenter is used. It defines the location where VMs will be created in the vCenter inventory tree. The inventory tree contains at least one Datacenter, and may also contain Folders, Clusters, and Resource Pools.
Example: /DatacenterA/Folder1/Cluster2/ResourcePool3
??
Virtual disk file format for images stored in the repository.
Disk files can be automatically converted between qcow2 and vmdk formats as reservations are deployed. (conversion from/to .vdi may also work)
Example: /vmfs/volumes/nfs-datastore1
For ESXi, the path configured in the profile may simply be the short datastore name as it appears in the vSphere Client: nfs-datastore1
Virtual disk file format for images stored in the virtual disk path.
The Virtual Disk Mode (VM Disk) parameter does not determine whether or not:
...images are copied from the datastore to the repository during image capture
...images are copied from the repository to the datastore during image load
These are determined by whether or not Repository Path is configured in the profile
The diagram above shows a simple VCL configuration with 1 management node and 2 VMware ESXi hosts. Network storage is not used.
The local disks on the VM hosts are used to store all of the files used by running VMs including the VM's working directory and the master vmdk image.
A directory on the local disk on the management node is used to as the image repository. This directory is exported via NFS. VM hosts mount this directory as a datastore named "repository". Mounting the repository directly on the VM hosts allows the vmkfstools utility to be used on the VM hosts to copy and convert images directly from the repository to the local datastore in a single step.
If an image is to be loaded on a VM host and that image does not already exist in the VM host's local datastore (Virtual Disk Path), it is automatically copied from the repository to the VM host's local datastore (Virtual Disk Path) at the beginning of the load process.
During image capture, images are automatically copied to from the VM host's local datastore (Virtual Disk Path) to the repository. This allows images captured on a VM host to be loaded on any other VM host.
The VM host profile Virtual Disk Mode parameter is set to dedicated. This indicates to the load process that the VM host's Virtual Disk Path is dedicated to the VM host and not shared by other VM hosts. This allows images to be deleted from the VM host's local datastore (Virtual Disk Path) if another image must be copied from the repository and not enough space is available.
This example is identical to the one above except that the repository located on the management node's local disk is not exported via NFS. Because of this, images must be transferred using SCP instead of vmkfstools. This is less desirable than mounting the repository directly on the VM hosts because images cannot be copied and converted in a single step. Images are stored in the repository in the 2GB sparse format. This allows the images to be copied via SCP while only transferring the data stored in the image, not the entire size of the hard drive stored in the image. VMware ESXi cannot run VMs using vmdk images stored in the 2GB sparse format. Images are converted to the vmfs thin format so that they can be loaded on VMware ESXi. This adds extra time to the load process if an image does not exist in the VM's local datastore (Virtual Disk Path) and must be copied from the repository. It also requires additional space in the VM host's local datastore (Virtual Disk Path) becuase 2 copies of the image exist while it is being converted.
Note that the VM host profile Repository Path parameter is set to the path on the management node's hard drive. The code first checks if the path exists on the VM host. If not, it assumes the repository is not mounted directly on the VM host and the Repository Path value refers to a location on the management node.
This is an example of a simple configuration where the network storage is used.
A repository is not used in this configuration. This implies that all VM hosts which will ever be added to this VCL environment will need to be able to connect to the network storage.
A datastore to be used as the Virtual Disk Path named "datastore" is mounted on every VM host. Each of these mounts points to the same location on the network storage. The datastore will contain the master vmdk images. VMs loaded on the VM hosts will read from these master vmdk images.
A datastore to be used as the VM Working Directory Path named "vmpath" is also mounted on each VM host. However, the location to which each VM host points should be different. In the example above, vmhost-a-01 points to th the /vmpath01 directory on the network storage and vmhost-a-02 points to the /vmpath02 directory. These locations may be different network storage filesystems or may be different directories on the same network filesystem. Even though the mounts on the VM hosts point to different locations, the datastore names configured under ESXi are identical. This allows you to use the same VCL VM host profile for all of the VM hosts.
The VM host profile Virtual Disk Mode parameter is set to shared. This indicates to the load process that the VM host's Virtual Disk Path is shared by other VM hosts.
1 Comment
Alex Patterson
IF anyone is setting up VMware ESXI 4.1 with network Storage
Make sure in your VMprofile in Phpmyadmin your set your
Here is an example of my VmProfile information
ID 5
profilename VMware ESX
Vmtypeid 1
imageid 4
Repositorypath null
Datastorepath (We are using a mapped, NFS FILE SHARE called 'vmfs/volumes/netappfiler02-sata1:
VMpath = /vmfs/volumes/netappfiler02-sata1 (yours will be different where you want to hold your VMware.vmx files
You want to match your configuration with the correct virtualswitch name virtualswitch1 VLAN10 (This is the name of our Private Network Label on ESXI 4.1 on our Blades)
virtualswitch0 VLAN56-57-58-59 (This is the name of our Public Network Label on ESXI 4.1 on our Blades)
I changed my profile to match the networking name. You want to make sure that you Network Adapter 1 = Your Private Network Label (Same Name info on EXI 4.1 VMware and your Phpmyadmin VMprofile table)
Network Adapter 2 = Your Public Network Label (Same Name info on EXI 4.1 VMware and your Phpmyadmin VMprofile table)
I had an issue with this and this helped me solve it