I thought that most people would have seen this awesome fling by now, but I received a couple of questions if it was already possible to migrate from the Windows vCenter Server to the vCenter Server Appliance. Surprisingly enough as William Lam wrote an excellent blog post on this subject. Anyway, this blog is just a simple short pointer to the Windows vCenter to vCenter Appliance migration tool and to William blog post. Read it, and go for it!
I was reviewing a paper on vCenter availability for 6.0 and it listed a watchdog service which monitors “VPXD” (the vCenter Server service) on the vCenter Server Appliance. I had seen the service before but never really looked in to it. With 5.5 the watchdog service (/usr/bin/vmware-watchdog) was only used to monitor vpxd and tomcat but in 6.0 the watchdog service seems to monitor some more services. I did a “grep” of vmware-watchdog within the 6.0 appliance and the below is the outcome, it shows the services which are being watched:
ps -ef | grep vmware-watchdog root 7398 1 0 Mar27 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -s rhttpproxy -u 30 -q 5 /usr/sbin/rhttpproxy -r /etc/vmware-rhttpproxy/config.xml -d /etc/vmware-rhttpproxy root 11187 1 0 Mar27 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vws -u 30 -q 5 /usr/lib/vmware-vws/bin/vws.sh root 12041 1 0 Mar27 ? 00:09:58 /bin/sh /usr/bin/vmware-watchdog -s syslog -u 30 -q 5 -b /var/run/rsyslogd.pid /sbin/rsyslogd -c 5 -f /etc/vmware-rsyslog.conf root 12520 1 0 Mar27 ? 00:09:56 /bin/sh /usr/bin/vmware-watchdog -b /storage/db/vpostgres/postmaster.pid -u 300 -q 2 -s vmware-vpostgres su -s /bin/bash vpostgres root 29201 1 0 Mar27 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -a -s vpxd -u 3600 -q 2 /usr/sbin/vpxd
As you can see vmware-watchdog is ran with a couple of parameters, which seem to different for some services. As it is the most important service, lets have a look at VPXD. It shows the following parameters:
What the above parameters result in is the following: the service, named vpxd (-s vpxd), is monitored for failures and will be restarted twice (-q 2) at most. If it fails for a third time within 3600 seconds/one hour (-u 3600) the guest OS will be restarted (-a).
Note that the guest OS will only be restarted when vpxd has failed multiple times. With other services this is not the case as the “grep” above shows. There are some more watchdog related processes, but I am not going to discuss those at this point as the white paper which is being worked on by Technical Marketing will discuss these in a bit more depth and should be the authoritative resource.
** Please do not make changes to ANY of the above parameters as this is totally unsupported, I am mere showing the details for educational purposes and to provide a better insight around vCenter availability when it comes to the VCSA. **
Today an awesome appliance called the vCenter Support Assistant was made available to the world. I have seen some screenshots and a demo and feel that this appliance is a MUST HAVE for anyone who files Support Requests. Just the fact that you can do that from a single interface, which also allows you to upload the support bundle just makes life a whole lot easier.
Ryan Johnson wrote an excellent article on this topic… and I am going to steal his thunder so I suggest you head over to the VMware TAM Program blog (open to everyone) and read up on this excellent Appliance.
I am going to do a couple of blogposts with “basic” workflows using the Web Client. Let me know if you find this useful or not… I will start with deploying the vCenter Server appliance and will assume you all know how to install ESXi. I prefer using the vCenter Server appliance in my lab as I can deploy it in minutes without the need to pre-install an OS etc.
The following steps outline the import process of the vCenter Server appliance.
- Open the vSphere Client
- Click “File – Deploy OVF Template”
- Browse for the OVA file
- Provide a name for the to be imported virtual machine, in our case “vCenter-01”
- Select a datastore where this virtual machine should be stored
- Use the default Disk Format
- Provide the networking details like IP address, DNS, netmask etc.
- Finish the wizard
During the reinstallation of my lab environment I ran in to this issue a couple of times. In my environment when I deploy the vCenter Server Virtual Appliance (VCVA) I always got the following error on the remote console:
No Networking Detected
This seems to happen when I point my vSphere Client directly to a host and import the OVA. When you point your vSphere Client directly at a host you do not have the option to fill out the networking details in the OVF wizard. (At least I don’t…) When I point my vSphere Client to a vCenter Server and import the OVA I get the option to fill out the networking details.
You can configure networking fairly simple. Just login to the console and type the following:
Make sure to fill out the following sections:
2) Default Gateway
6) IP Address Allocation for eth0
After this has been done type 1 to exit the configuration tool. Now the VCVA should be configured. In some cases I noticed that the “default gateway” setting did not stick. I would suggest validating this on the network tab of your management console, which can be found here: https://<IP address or DNS name of your vCenter instance>:5480.
Now that you have successfully deployed the vCenter Server appliance you can start exploring the new vCenter Web Client: https://<IP address or DNS name of your vCenter instance>:9443/vsphere-client/
Today on twitter there was a discussion around having an appliance for the vSphere Web Client. I didn’t get the question as there’s already a vCenter Appliance out there. Apparently not everyone realised that the Web Client is part of the vCenter Appliance. On top of that you could even split out the components and use the vCenter Appliance just for Web Client functionality. I remembered seeing an article from one of my colleagues not too long ago. I dug up the links and here they are. I included a short snippet so you know what to expect. These articles are by Michael Webster so all credits go to him:
Prior to running through the steps below you should have downloaded and deployed the vCenter Server Virtual Appliance (VCVA) from the VMware web site. This process assumes you already have the VCVA connected to the network and configured with the correct timezone already. To de-register the local embedded vCenter System and to register an existing vCenter Server with the vSphere Web Client do the following….
This is the first step you can take to get the vSphere Web Client up and running. But what if you want to provide some additional redundancy. Or what if you have dozens of people literally using the Web Client and want to add some load balancing? Well Michael thought about that as well and came up with a cool solution for this.
In the above design I’ve chosen to use the vCenter Virtual Appliance with the vCenter Services disabled to act as the vSphere Web Client Servers. I’ve used a F5 BIG-IP LTM VE to provide load balancing for the vSphere Web Client User access to the vSphere Web Client Servers, as well as for the vCenter Servers to access the vSphere License Plug-in. You can use any load balancer that will successfully load balance HTTPS traffic on port 9443, which is the port the vSphere Web Client uses.
I think this is a cool solution, and considering the Web Client is the way forward it is definitely an option exploring. I do want to point out that this has more than likely not been explicitly tested by VMware and I am uncertain if it is supported. I have reached out to our vCenter experts however to comment on it.