After a long weekend of waiting for some cleanup scripts to run on the hosting end, the site is back up and operational. I have made some significant changes to the format and was looking for some feedback on the presentation. So, if you like the layout – please let me know.
After my last post, I decided to hang out in the vMA for a while to get acclimated with it. I’ve been using it off and on for quite a while now, but over the last few days I have been living in it. I found a few things that I think are pertinent to anyone who uses this.
First off, I should start with the basics. The vSphere Management Assistant comes from VMware in an OVF format for easy insertion to your virtual infrastructure. The management stations supports any version of ESX or ESXi from version 3.5 update 2 to present. It also consumes 512mb of memory from the host(s) and has a standard 5GB vDisk attached to it. It has two users that are already setup, one is the vi-admin account for administrative operations and the other the vi-user account with read-only rights to execute vCLI commands with. You can even join the vMA to an AD domain if you want to.
I’ve deployed about 5 of them so far and here are a few things that I do to these appliances:
1) Give it a static address and a proper DNS name so it is easy to get to and available when you need it. This can be done during the setup phase or you can run a pre-built script located in /opt/vmware/vma/bin/vmware-vma-netconf.pl – you will notice that you need to become root in order to run this, so see below to reset the password.
2) Change the root password of the appliance (since it is necessary to ‘su’ to run certain scripts on it). You can do this by running the following command: # sudo passwd root
Here are some handy commands and capabilities that you can use for the vMA:
- Scan for updates to the vMA: # vma-update scan
- Update the vMA (after you’ve scanned for updates): # vma-update update
- You can run custom code that force proprietary software or hardware components to work with ESXi.
- Developers can you the integrated API’s within the VmaTargetLib (library) to connect to vMA targets via Java or Perl.
- Administrators can add vCenter servers as well as ESX/ESXi nodes as potential “targets” to run scripts. This allows for a single sign on type of mechanism.
- You can even re-use your old service console scripts that you may have used on older ESX systems.
Well, I knew it was coming but I just didn’t want to believe it. VMware has officially taken down the download links to the ESX product from their website. I’ve heard that you can still get to it through some super-secret hyperlink, but I’m not 100% sure of that. This should come as no surprise to fellow VMware folks out there since they have been talking about this day for quite a while now.
One thing that I am going to miss (and maybe this is just a nostalgic thing for me) is that fact that I could immediately SSH to a node if there were any issues that popped up and I couldn’t get to it via vCenter or Virtual Center for the 3.x days. Oh sure, you can turn on “tech support mode” but then vCenter complains constantly that it is on and makes it look like you have all kinds of problems in your cluster with warning icons all over your hosts.
Being the sentimental guy that I am, part of me will be sad that there will be no service console anymore, but I am welcoming this change due to a number of reasons that are obvious:
1) The attack footprint of ESXi will be much smaller and therefore make it far more secure than ESX.
2) Deploying “diskless” nodes will contribute to a cost savings and allow for quick boot times via SD or other methods.
3) I will really not miss running out of local storage due to logs (something I haven’t seen since 3.x)
But for now, I bid you farewell ESX – you have served your purpose well and now I will have to live in the VMA appliance from here on out.