Posts Tagged ‘VirtualCenter’

I recently finished reading the book VMware VI3 Implementation and Administration by Eric Siebert (ISBN-13: 978-0-13-700703-5). VMware VI3 Implementation and Administration was a very enjoyable read. I don’t mean to sound cliché but for me it was one of those books that is hard to put down. Released in May of 2009, along with the next generation of VMware IV (vSphere), the timing of its arrival to market probably could have been better, but better late than never. Datacenters will be running on VI3 for quite some time. With that in mind, this book provides a tremendous amount of value and insight. I can tell that Eric put a lot of time and research into this book; the quality of the content shows. Much of the book was review for me, but I was still able to pick up bits and pieces here and there I wasn’t aware of, as well as some fresh perspective and new approaches to design, administration, and support.

To be honest and objective, I felt that Chapter 9, “Backing Up Your Virtual Environment”, lacked the completeness which all other chapters were given. A single page was dedicated to VMware Consolidated Backup with no detailed examples or demonstrations of how to use it, which would have been found throughout other chapters. To add, there was only a few sentences covering Replication which is a required component in many environments. Eric likes to discuss 3rd party solutions and this would have been a great opportunity to go into more detail or at least mention some products affordable to businesses of any size which could leverage replication solutions.

Overall, this is a great book. Eric has a no-nonsense writing style backed by decades of in the trench experience. Along with the print copy, you get a free electronic online edition as well allowing you to access the book anywhere where there is internet connectivity. Pick up your copy today! I thank you Eric and look forward to your upcoming vSphere book!

A few nights ago, I began the VI3 to vSphere upgrade in my home lab and I thought I would share a few experiences. This day 1 post will cover vSphere management tools (vCenter, Update Manager, etc.) and not the hypervisor itself (ESX or ESXi).

My VI3 environment has been through some wear and tear over the years, including a few unexpected power outages which could have caused corruption on the vCenter server or the back end databases. Although the part of me which desires peace of mind wanted to start “clean” with an empty database, I knew that I must go the upgrade route, maintaining my existing data because frankly this is the method I will likely be using to deploy most vSphere installations.

I run a lot of what I would consider “production workloads” on my home lab, including domain controllers, messaging servers for registered domains, web servers, Citrix servers, this blog, etc. Failure is an option as well as a good learning experience (after all, this is a lab), however, long term outage of my production workloads is not an option. My vCenter server is virtualized on VMware Server 2.x so I started out by shutting down its OS and taking a VMware snapshot. After the vCenter shutdown, I also captured a full backup of my SQL server databases (both the vCenter database as well as the Update Manager database). I now have a solid backout plan which does not incorporate crash consistent data.

I powered the vCenter VM back up. I then copied over the vCenter 4.0 .zip package and extracted it into a temp directory on the vCenter server. This was the first mistake I made. Not thinking clearly about my snapshotted VM, I had just inflated the VM’s delta file by a few GB. What I should have done is to perform the vCenter copy and extraction before the snapshot. This is not the end of the world. After the installation of vCenter 4 and Update Manager, the snapshot would have grown by several hundred MBs if not a few GBs anyway. The .zip file and extracted contents were just a lot of extra non-contiguous I/O baggage.

I’m going to perform an upgrade of the databases, but I don’t care to actually “upgrade” vCenter and all of its components from 2.5 Update 4 to version 4.0. I’ve never ever had good luck with vCenter upgrades. My method, therefore, is complete uninstall of vCenter and all components, then a new installation of vCenter while attaching to the existing database which will in turn be upgraded. During the uninstall of vCenter, I typically find that the vCenter uninstall routine leaves bits and pieces behind in folder structures as well as the registry. I manually deleted the remaining pieces and rebooted the vCenter server for good measure and a clean start for the vCenter 4.0 installation. In retrospect, the manual deletion of left over files and uninstall of the vCenter license server will turn out to be my second and third mistakes which I’ll talk about shortly.

After the reboot, I began the vCenter 4.0 installation. I also made sure my vCenter SQL account had DBO rights to the MSDB database, the vCenter database, and the Update Manager database. This is a new requirement during the installation of vSphere. I wasn’t too far into the installation when I ran into failure and the installation routine rolled back. The error message was rather cryptic and I’m sorry I don’t have a screenshot but it had to do with the installer’s inability to properly install and configure the local ADAM instance which I believe is used for vCenter federation (linked vCenter servers). I quickly found a long thread on the VMTN forums which pointed me to the solution in VMware’s knowledgebase. KB1010938 talks about NETWORK SERVICE NTFS directory permissions (READ) that are required on the root of the drive where vCenter is being installed. A quick check showed I lacked the necessary permissions. I resolved this quickly and re-ran the installation.

During the re-installation, I ran into my second problem (self inflicted). Way back when, I had set up SSL certificates for VI3. The certificate files are required to be present during the database upgrade because the certs are tattooed to the database as well. During my “cleanup” process I spoke about above, I had deleted the SSL folder containing the certificate files VMware had left behind. Turns out this was by design. Thankfully when I performed the cleanup, all files and folders went to the recycle bin and I was able to quickly retrieve them. Without the certificate files, I would have been looking at a new database installation which would have deleted all vCenter data including performance history.

After restoring the certificate files, I reran the installation a third time. The installation of vCenter Server and all of its components was successful. I was able to open the vSphere client and connect to the vCenter server. My hosts, VMs, and all data was present. All looked to be successful until I tried a VMotion. The ESX hosts which were still on VI3 were no longer licensed. Refer to my comment further up about uninstalling the license server being a mistake. vCenter 4.0 license keys do not license VI3 legacy hosts. A VI3 license server or host based license keys must be plugged into vCenter 4.0 in order to properly license VI3 legacy hosts. I resolved the issue by re-installing the VI3 license server on some junk VM in the interim and then plugged the license server name into vCenter 4.0’s licensing configuration. Viola! The ESX3 and ESXi3 hosts are now licensed and everything is working properly. After feeling confident in the installation, I removed the vCenter snapshot.

This was enough change for one night. The ESX host upgrades (rebuilds) will come a few days later. If I uncover any gotchas during host installations, I’ll be sure to share but I expect those to be fairly uneventful. I’ve installed a lot of ESX4/ESXi4 hosts during the vSphere beta and it’s straight forward, not unlike ESX3 /ESXi3 installations. Most of the ~150 changes in vSphere will be evident in vCenter and the various components. There’s a few enhancements in the hypervisor installation but nothing that hasn’t already been pointed out in various other blogs and installation videos.

Virtual infrastructure administrators may edit a VM’s .vmx configuration file by hand with vi or nano (my favorite) for a variety of reasons. Efficiency through bulk changes via scripting, troubleshooting a problem, adding unsupported/undocumented .vmx parameters, or a higher comfort level with command line interfaces to name just a few.

Modifying .vmx files by hand is all well and good. Administrators have been doing since since for as far back as I can remember with VMware products. There is an annoying caveat with VMware vCenter Server however. Changes made by hand in the .vmx file may take a while to show up in the Virtual Infrastructure Client. For example, if I’m looking at a VM’s configuration summary in the VIC, and then modify the .vmx file to change the memory configuration from 256MB to 512MB, save and exit, nothing seems to happen in the VIC. I’m looking at the VIC and configured memory of 256MB is staring back at me. It may end up staying this way for quite some time. Removing the VM from inventory and re-adding it to inventory will resolve the issue but that’s drastic, annoying, and it presents the opportunity for more problems. For instance, what if during the import of the VM it lands in the wrong resource pool or VM folder? Suddenly you’re exposed to potential resource contention issues impacting SLAs and incorrect permissions or patch management baselines on the VM.

There’s an easier way that involves a lot less risk using two vimsh commands at the service console. Here are the steps:

Log on to the service console on the host that the VM is registered on.

In the service console, make the configuration change in the .vmx file and save it.

In the service console, run the command vimsh -ne “vmsvc/getallvms” |grep <vmname> to obtain the VmID of the VM. The VmID will be the first number displayed on the left. Excluding the |grep <vmname> portion of the command will display all VMs registered on the ESX host.
Example:vimsh -ne “vmsvc/getallvms” |grep knoppixReturns:
80 knoppix [msa1000_lun3] knoppix/knoppix.vmx otherLinuxGuest vmx-04 Veeam Backup: Time [4/30/2009 5:46:41 AM], Backup host [SKYWALKER], Backup file [V:\VeeamBackups\Galleon Cluster Backup.vbk]

In the service console, run the command vimsh -ne “vmsvc/reload <VmID>” using the VmID obtained in the previous step.
Example:vimsh -ne “vmsvc/reload 80”

After a few seconds, the configuration change will be received by the vCenter Server and will be reflected in the VIC.

A new license tier for Mid to Enterprise size businesses has been added called Enterprise Plus. This is the premier and most feature rich tier available.

Two new licensing tiers have been added tailored to the needs of Small Business (SMB):

vSphere Essentials

vSphere Essentials Plus

Surely because of the advancements and popularity of multicore processors, host licensing is no longer sold in pairs of sockets, rather by the single socket.

To my surprise, FT (Fault Tolerance) is not licensed per VM. Rather, it is included in all of the Mid to Enterprise class licensing tiers except for Standard. Wow. Given the added protection level, this could be the best bang for the buck (from a licensing standpoint anyway, extra infrastructure needed is a different discussion). It is not included in the SMB tiers.

Pluggable Storage Architecture (PSA) was added to the new Enterprise Plus tier. One new feature PSA will offer is 3rd party storage multipathing.

Zero adjustments in vCenter Server pricing (as well as SnS). The high cost vCenter perception debate will continue although personally I think it’s worth every penny.

Enterprise customers with current support will receive the following new feature entitlements:

I’ve been testing vSphere for a few months and have collected various samples of new and different management interfaces. VMware has informed me that I am no longer under vSphere NDA and bloggers are welcomed to help showcase VMware’s new vSphere product. In no particular order, here are some of my observations. By the way, the very first thing I noticed out of the gate when installing vSphere (other than I needed 64 bit hardware) was that although ESXi4 is small enough to fit on a CD, ESX4 is now a DVD. For those who install from physical media, you’ll want to be sure you’ve got a DVD-ROM reader in your host.

The VIC now has integrated authentication built into the GUI. We had this in VI3 but through command line parameters that launched the client:

A Hyper9-like quick search in the top right area of the vSphere Client:

Complete license management overhaul evident in many areas:

An improved Plug-in Manager:

Host Profiles will assist us with automated configuration and consistency. This may sunset much of the deployment scripting you have in place today and I think it’s especially helpful for ESXi users as it offers yet another option for automating the configuration of VMware’s console-less hypervisor. Along with being responsible for making configuration changes across a container, it can also be used to verify compliance of host configurations. It works similar to VMware Update Manager and remediation:

vCenter Server configuration Advanced Settings. Take a look at what’s highlighted: VMotion encryption. Those worried about vampire taps on their VMotion network can sleep better at night:

My favorite and most used – the Home button, which brings you back to the “root” of all configurable items in vCenter Server. This feature alone will reduce VI Administrator mousing carpel tunnel by 20%:

vCenter Service Status. Keeping vCenter Server healthy is becoming increasingly important in vSphere. This tool helps us keep tabs on it:

Resource Allocation at the VM level. The bar graphs look similar to the old ESX or GSX MUI, I forget which:

That’s all for now. I wanted to get into vNDS (vNetwork Distributed Switch) but that in and of itself is about 35 screenshots. Good material for later. vSphere looks and feels very promising. I like most of the changes but there are still some lingering enhancements that I will continue to pester VMware about.

Quick note: In case you missed it (like I did), VMware has updated most of their VMware Infrastructure 3 documentation. If you’re a documentation junkie (like me), you’ll want to re-download all of VMware’s VI3 documentation. About 75% of the documents have new file names as well.

Oh. What does it do? Remember VMware GSX Server and the web MUI where VMs were graphically represented by the guest OS thumbnail? That’s what it does, but now for ESX and ESXi. One thing you’ll notice is that in the Hosts and Clusters view, it displays the thumbnail in the left column, but not the main window pane on the right side of the screen. Same behavior in the Virtual Machines and Templates view. Maybe in the next version. Thanks a lot Andrew and keep up the great work! I can absolutely say that we live in a better VMware world with you in it.