New week, new lessons learned… You can find part 1 here.
When Jumbo Frames were introduced in ESX 3.5 a lot of people were interested but it wasn’t supported for the VMkernel which is were most people want to use it as it reduces CPU cycles used due to iSCSI/NFS traffic. When vSphere was released it was one of the things I noticed first. Full support for Jumbo Frames… however:
- Jumbo frames are not supported for VMkernel networking interfaces in ESXi. (page 54)
Although obvious in my opinion it wasn’t obvious for one of my customers:
- VMware ESXi does not support web access at this time.
Although I personally usually disable web access as it a security risk this customer had specific operational procedures around vCenter failures which included web access. It’s not a huge problem as the vSphere/vCenter Client can directly connect to an ESXi host, but it is something you will need to keep in mind when implementing ESXi.
Another thing I discovered today is that scripted/unattended installations of ESXi are not currently supported which makes deploying difficult. (Not only unsupported but also not easily set up) I am currently investigating the option to at least install it with default settings and without manual intervention… If I am successful I will post it in the next “lessons learned”.
Alan Renouf says
Most of the config can be done via PowerCLI, the install however is a pain in the ****
NiTRo says
I found something that can help you Duncan : http://www.hypervisor.fr/?p=1519
Justin Grote says
That’s interesting about the jumbo frames vmkernel support in ESXi. I had missed that tidbit and was mostly going by iSCSI configuration guide, however looking deeper, it never specifically says ESXi, just ESX.
I’ve implemented it in production with jumbo frames in several sites now and haven’t had any problems, but now I’ll probably be a little more hesitant since it is explicity not supported on ESXi.
Tom says
The hypervisor.fr item is all in French. ๐
Are there any alternatives to the web access for ESXi?? — besides the VIC Client??
Reason I ask is suppose someone other than the VMware admin (non-admin person) must restart VMs on short notice etc., in a business continuity situation where VMs must for whatever reason be started manually??
AFidel says
An alternative to VIC is the vcenter mobile access appliance, it can target individual hosts as well as vcenter and works well from iphone, blackberry and probably just about anything else =)
As to the ESXi scripted install, just use host profiles if you have Enterprise Plus =)
Henk says
Deployment of ESXi is a pain indeed. Would be nice to do it via Altiris/RDP
Interesting links voor PXE installing ESXi:
http://www.cyclelicio.us/2009/03/howto-network-install-vmware-esxi-from.html
http://www.chriswolf.com/?p=182
Matt says
Re: Web Access. You can embed the mks plug-in in your own home made web page and provide some limited admin functionality that way.
Doug says
I’ve used the Ultimate Deployment Appliance (2.0b5) to install ESXi with the default settings then configure it with the PowerCLI or host profiles.
Getting a true hands-off scripted install that can be pushed down to a box with all configs is a little trickier with ESXi, but a quick way uses the vMA/vCLI:
Capture the configuration with ‘vicfg-cfgbackup.pl –server -s ‘ once you have it configured the way you want it.
Once you have the default image pushed back onto it, you can use ‘vicfg-cfgbackup.pl –server -l ‘ to drop the saved config back onto it.
The drawback is that vicfg-cfgbackup only likes to drop the config back onto the SAME version of ESXi that it captured the config from. The reasoning is pretty clear, but there is a -f (force) option if you’d like to use it. ๐
Doug says
Weird. The post mangled the commands.
The correct commands are (with double en-dashes, not a single em-dash):
vicfg-cfgbackup.pl –server (server_name) -s (backup_file_name)
vicfg-cfgbackup.pl –server (server_name) -l (backup_file_name)