This isn't something that you have to do unless you have implemented LUN Masking at the ESX host level. That's a relatively uncommon technique - LUN presentation should be handled at the array level and in my experience it almost always is. I can't see why it would ever be used in an iSCSI environment but there might be some odd hardware out there that required it. If you are concerned then check to see if LUN masking is configured on your hosts before you upgrade.
The risk is that you might have an environment where your SAN presents all, or some, of it's LUNs\Volumes in an uncontrolled fashion and relies on the hosts to be selective about the volumes they will actually interact with. For example, if you have a scenario where an NTFS volume that technically belongs to a Windows host is also visible to an ESX host then you could use LUN masking to prevent the ESX host corrupting that volume. This is a fairly fragile setup and that is why it is generally avoided.
Even if you have to do this that doesn't mean you will need to use the VMA. The vSphere CLI can be installed on Windows XP\2K3\2K8-64\Vista and RHEL 5.1, SLES 10\11 & Ubuntu 9.04 to allow access to most of the commands that would need to be run directly on the Service Console in older ESX versions. The VMA is handy because it's a fully self contained and preconfigured CentOS Virtual Appliance that includes the vSphere CLI, amongst other things. As JakeRobinson pointed out the Busybox CLI on ESX 4.1 can be used because it supports the ESXCLI commands so you don't actually need to install anything else if you have to do this.