“Call HostServiceSystem.Start for object XX on vCenter Server YY failed” when starting snmpd on ESXi 5.1

SSH into the host and run these:

~ # esxcli system snmp set --communities 
~ # esxcli system snmp set --enable true

After that, make sure you have the port (161/udp) open in the firewall config and it should start up ok. (The root problem is the file /etc/vmware/snmp.xml – those commands fix it).

Advertisements

VMWare Tools Compatibility Matrix

Question: If I install the latest version of VMWare Tools on a guest, what kind of compatibility do I get when I vMotion to an older version of ESX? In other words, is VMware Tools backwards compatible with older versions of ESX/ESXi?

Answer: Yes, it’s backwards compatible. From this tool:

vmware-tools-compat

Upgrading ESX 4.0 to ESX 4.1 with Update Manager

This turned out to be so ridiculously easy I probably shouldn’t even mention it, but only because I remembered that Update Manager exists. I thought I was going to have to burn an ISO, go to the datacenter, pop the disc in, etc. But with Update Manager this is all handled remotely. Just download the files from vmware.com and upload them to your vCenter server through the client. This YouTube video by VMware walks you through the procedure:

Continue reading “Upgrading ESX 4.0 to ESX 4.1 with Update Manager”

The VMware datastore LUN 2TB (well, 1.99999 TB) size limit

I started migrating our physical machines to VMs using VMware a few years ago and the first problem I ran into is still the most annoying one: the size limit for LUNs is, per VMware’s docs, (2TB – 512B). That’s 512 bytes shy of 2TB, so basically 1.99999 TB, or 2047.999 GB. So when I create a new LUN for a datastore in the SAN the max size is 2047 GB. Now, as the VMware KB article states, this is a limitation of SCSI, not VMware per se, but that doesn’t make it any less annoying. When I first setup ESX, I created a 5 TB LUN for the datastore. It showed up in vCenter as 1 TB. After some Googling I learned of the 2 TB limit — the usable space is basically usable space = (size of lun) % 2TB, where % is the modulo operator — and found something suggesting using extents to expand the datastore across luns. I did that, but I later learned that there seems to be a consensus that extents should be avoided.

There are other things I learned along the way – that you want to limit the number of vmdks per datastore anyway, for example, due to the risk of SCSI reservation errors and IO contention, but these are all things that it feels like we shouldn’t have to worry about. I can see having separate LUNs/datastores for different logical groupings of disks, allowing you to have different snapshot schedules for each datastore, or allowing you to put an entire datastore in Tier 1 or Tier 3 (to use Compellent parlance) based on its value to you. But having to segregate stuff for technical reasons seems like a problem that should already be solved.

And maybe it is… I’ve never tried NFS datastores, but if I created an 8TB LUN, mapped it to a physical box (skirting the 2TB limit imposed by VMware), export the volume from the host over NFS and use that as the datastore, I guess I’d be able to do all the things I want. Hmm. I’ll have to think about that. I guess I’d still keep the ESX host local luns on iSCSI so they could boot from SAN, though I suppose when we move to ESXi that won’t be much of an issue anyway.

Hmm… Well, I started writing this as a rant but I think I just morphed it into a new research project.