Not totally unexpected Stratus compares its solution to vCenter Heartbeat, which they say is more expensive and more complicated to implement. The Stratus solution is roughly $ 6.5k (source), but keep in mind that this is for a 4u physical system and you will need to add the cost of power/cooling/rackspace on top of that, where of course you could run vCenter Heartbeat perfectly virtual. It is not difficult to compare the price, but I’d rather see a cost comparison. Anyway, lets look at the architecture used. The following diagram, created by Stratus, compares the two solutions. I guess it is obvious straight away what the main difference is:

The difference is that Heartbeat is two instances being kept in sync where Stratus is a single instance. Although Stratus takes the “simplicity” approach to compare both architectures, in my opinion this also shows the strength of vCenter Heartbeat. That second instance could be running in a different datacenter / location. I guess each of these have its advantages / disadvantages.

Both of the solutions are definitely worth looking in to when deploying critical environments, but before you make a decision list the benefits/ costs / complexity / resiliency and weight them against each other. Nevertheless it is great to see solutions like these being developed.

“An ESX/ESXi host requires connectivity to vCenter Server to make vDS operations, such as powering on a VM to attach that VM’s network interface.”

“The issue is that if vCenter is a VM and changes hosts during a disaster (like a total power outage) and then is unable to grant itself a port to come back online.”

I figured the best way to debunk all these myths was to test it myself. I am confident that it is no problem, but I wanted to make sure that I could convince you. So what will I be testing?

• Network connectivity after Powering-on a VM which is connected to a VDS while vCenter is down.
• Network connectivity restore of vCenter attached to a VDS after a host failure.
• Network connectivity restore of vCenter attached to a VDS after HA has moved the VM to a different host and restarted it.

Before we start I think it is useful to rehash something, which is different types of portgroups which is described in more depth in this KB:

• Static binding - Port is immediately assigned and reserved for it when VM is connected to the dvPortgroup through vCenter. This happens during the provisioning of the virtual machine!
• Dynamic binding - Port is assigned to a virtual machine only when the virtual machine is powered on and its NIC is in a connected state. The Port is disconnected when the virtual machine is powered off or the virtual machine’s NIC is disconnected. (Deprecated in 5.0)
• Ephemeral binding - Port is created and assigned to a virtual machine when the virtual machine is powered on and its NIC is in a connected state. The Port is deleted when the virtual machine is powered off or the virtual machine’s NIC is disconnected. Ephemeral Port assignments can be made through ESX/ESXi as well as vCenter.

Hopefully this makes it clear straight away that their should be no problem at all, “Static Binding” is the default and even when vCenter is down a VM which has been provisioned before vCenter went down can easily be powered on and will have network access. I don’t mind spending some lab hours on this, so lets put this to a test. Lets use the defaults and see what the results are.

First I made sure all VMs were connected to a dvSwitch. I powered of a VM and checked the “Network settings and this is what it revealed… a port already assigned even when powered off:

This is not the only place you can see port assignments, you can verify it on the VDS’s “ports” tab:

Now lets test this, as that is ultimately what it is all about. First test, Network connectivity after Powering-on a VM which is connected to a VDS while vCenter is down:

• Connected VM to dvPortgroup with static binding (is the default and best practice)
• Power off VM
• Power off vCenter VM
• Connect vSphere Client to host
• Power on VM
• Ping VM –> Positive result
• You can even see on the command line that this VM uses its assigned port:

  esxcli network vswitch dvs vmware list

  Client: w2k8-001.eth0

  DVPortgroup ID: dvportgroup-516

  In Use: true

  Port ID: 137

Second test, Network connectivity restore of vCenter attached to a VDS after a host failure:

• Connected vCenter VM to dvPortgroup with static binding (is the default and best practice)
• Power off vCenter VM
• Connect vSphere Client to host
• Power on vCenter VM
• Ping vCenter VM –> Positive result

Third test, Network connectivity restore of vCenter attached to a VDS after HA has moved the VM to a different host and restarted it.

• Connected vCenter VM to dvPortgroup with static binding (is the default and best practice)
• Yanked the cable out of the ESXi host on which vCenter was running
• Opened a ping to the vCenter VM
• HA re-registered the vCenter VM on a different host and powered it on
• The re-register / power-on took roughly 45 – 60 seconds
• Ping vCenter VM –> Positive result

I hope this debunks some of those myths floating around. I am the first to admit that there are still challenges out there, these will hopefully be addressed soon, but I can assure you that your virtual machines will regain connection as soon as they are powered on through HA or manually… yes even when your vCenter Server is down.

The vSphere Syslog Collector settings can be found under:

• Windows 2003 –> C:\Users\All Users\VMware\VMware Syslog Collector\vmconfig-syslog.xml
• Windows 2008 –> C:\ProgramData\VMware\VMware Syslog Collector\vmconfig-syslog.xml

If you open this file you can change all the settings you configured during the installation.

<defaultValues>
<port>514</port>
<protocol>TCP,UDP</protocol>
<maxSize>2</maxSize>
<rotate>8</rotate>
<sslPort>1514</sslPort>
</defaultValues>

You never know when you might need it

Deploy vSphere Web Client without Additional Windows Server License

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.

Increase vSphere Web Client Availability and Scalability for Enterprise Environments

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.

http://www.surveymethods.com/EndUser.aspx?D2F69A80D4988782D4

1. Add-EsxSoftwareDepot c:\tmp\VMware-Esxi-5.0.0-<buildnumber>-depot.zip
2. Add-EsxSoftwareDepot http://<vcenter server>/vSphere-HA-depot
3. New-EsxImageProfile -CloneProfile "ESXi-5.0.0-<buildnumber>-standard" -name "ESXiStatelessImage"
4. Add-EsxSoftwarePackage -ImageProfile "ESXiStatelessImage" -SoftwarePackage vmware-fdm
5. New-DeployRule -Name "FirstBoot" -Item "ESXiStatelessImage" -AllHosts
6. Add-DeployRule -DeployRule "FirstBoot"
7. Boot one of the hosts
8. Configure the host
9. Create Host Profile based on “first host” named “ESXiHostProfile”
10. New-DeployRule -name "ProductionBoot" -item "ESXiStatelessImage", ESXiHostProfile, <target_cluster> -Pattern "vendor=<unique hw identifier>"
11. Add-DeployRule -DeployRule "ProductionBoot"
12. Remove-DeployRule -DeployRule FirstBoot -delete
13. Boot all hosts
14. Assign Host Profiles to all hosts
15. Provide the “user input” aka create an Answer File per host
    
16. Reboot hosts –> done
17. Before you leave your PowerCLI session make sure you save your newly create image profile as a Software Depot so you can make changes later if and when needed! Otherwise the data will be saved in your image profile cache but you will not be able to make changes!
    Export-EsxImageProfile -ImageProfile "ESXiStatelessImage" -ExportToBundle -FilePath c:\tmp\ESXiStatelessImage.zip

That seems a bit more simplistic than my previous post doesn’t it.

** update: added step 17 **

• Download vCenter Server 5
• Download the ESXi 5.0 Offline Bundle
• Install vCenter Server 5
• Install Powershell 2.0 (installed it on the vCenter Server)
• Install PowerCLI (installed it on the vCenter Server)
• Install Auto-deploy (also located on vCenter iso) (installed it on the vCenter Server)
• Install TFTP Server (I used Solarwinds) (installed it on the vCenter Server)
  • Click “File” and “Configure” and start the TFTP Server
  • A folder C:\TFTP-Root will be created
  • Make sure if you are running this on Windows that the Firewall is open for TFTP
• Open up your vCenter Client
• Go to the Home screen and click “Auto Deploy”
• Click “Download TFTP Boot Zip”
  • I temporarily disabled IE ESC to be able to quickly download the zip file (Control Panel –> Add / Remove Programs –> Turn Windows Features On/Off –> Look for “Configure IE ESC in the Security Information section)
• Unzip the TFTP Boot Zip file in your TFTP-Root folder
• Copy the location of “BIOS DHCP File Name as mentioned in your Auto Deploy screen. This will be “undionly.kpxe.vmw-hardwired”.
• Go to your DHCP Server and add the filename and the ip address of the
  • In my case this is what I added to the advanced settings in my Tomato Router/DHCP server:
    dhcp-boot=undionly.kpxe.vmw-hardwired,,192.168.1.45
  • In the case of a MS DHCP Server you will need to follow this MS KB article. (#66 and #67 should be sufficient)
• Now it should be possible to boot your host, however you should see a screen that tells you that there no ESXi image associated yet. Now we need to do some PowerCLI magic…
• First of all we will need to set the execution policy to “remotesigned” if you haven’t done so already, in my case I haven’t as this is a brand new installed Windows VM:
  Set-ExecutionPolicy RemoteSigned
• Now you can open up PowerCLI and connect to your vCenter Server:
  Connect-VIServer <vcenter name>
• Next we will need to add a software depot, this is the Offline Bundle file you downloaded at the beginning:
  Add-EsxSoftwareDepot c:\tmp\VMware-ESXi-5.0.0-469512-depot.zip
• Now that you’ve added the depot you will need to identify the ImageProfile you wan to use. Run the following command to list the image profiles:
  Get-EsxImageProfile
• In my case it returns the following:
  Name
  ——-
  ESXi-5.0.0-469512-no-tools ….
  ESXi-5.0.0-469512-standard ….
• We will use the “Standard” image profile as we want to be able to install VMware Tools as well through vCenter. In order to use it we will need to define a rule. This basically tells the client which image it should pick up during the PXE Boot. No key thing with this command is the “-Pattern” as that basically defines which machines will get boot the image. In my case everything is running within VMware Workstation and the vendor will always be “VMware Virtual Platform” so I decided to use that is the identifier for this specific rule.
  New-DeployRule –Name “FirstTimeBoot” –Item “ESXi-5.0.0-469512-standard” –Pattern “model=VMware Virtual Platform”
• This will take a while as it is unzipping and uploading the required packages. When it has successfully completed we will need to make this deploy rule active:
  Add-DeployRule -DeployRule FirstTimeBoot
• That’s it, now the host should be able to boot up using the assigned image profile. See the screenshot below of my PXE booted ESXi host within VMware Workstation
  

Now if you would go to vCenter and check your Datacenter you will see a host appearing. This host however will still need to be configured and that is the second portion of this exercise…

What we creating here is a stateless configuration. That means we will need to use host profiles in order to configure this host correctly after reach reboot. These are the steps I took to create a host profile for my Lab hosts:

• Configure the host as needed. Don’t forget things like NTP, Storage, Networking, Scratch etc.
• Go to Host Profiles
• Create a New Profile from an existing host
• Select the host you just configured
• Give it a name that you will remember, I used “ESXiLabHostProfile”
• After creating the host profile you will need to attach the host to the profile and check for compliancy. This test should fail as you will need to create an answer file first.
  • Right click the host and select “Update Answer File”
  • Check all settings (ip-address etc) and when finished click “update”
  • Right click the host and select “Check Answer File”, result should be “x”
  • Select the host and click “Check Compliance”, result should be “compliant”
• Before we will create a new deploy rule we will want to add the HA depot and create a new image profile which includes the HA agent as we will want our hosts to be part of that. If you don’t add it the “new-deployrule” statement will throw a message that you will need to add it. First we will add the vSphere HA depot. The ip-address should of course be replace with the ip-address of your own vCenter server:
  Add-EsxSoftwareDepot http://192.168.1.45:80/vSphere-HA-depot
• Now we will need to clone the ESXi Standard depot and add the HA agent to it:
  New-EsxImageProfile -CloneProfile ESXi-5.0.0-469512-standard -name “ESXiHA”
  Add-EsxSoftwarePackage -ImageProfile “ESXiHA” -SoftwarePackage vmware-fdm
• Now we will create a new deploy rule and associate it with the just created host profile called “ESXiLabHostProfile”. We will also directly enable this new rule. Note that “HA-DRS” is the name of my cluster in this case. First we will remove the old rule to make sure we start with a clean slate:
  Remove-DeployRule -DeployRule FirstTimeBoot -delete
  New-DeployRule –Name “ProductionBootRule” –Item “ESXiHA”, ESXiLabHostProfile, HA-DRS –Pattern “model=VMware Virtual Platform”
  Add-DeployRule -DeployRule “ProductionBootRule”
• Now you can restart the ESXi host and it should end up in the cluster (HA-DRS) with the correct host profile (ESXiLabHostProfile) and completely configured ready for action! (Note that for the next host you will need to create the answer file as well initially for it to work correctly.)

That’s it for today… Hope it helps, I had a lot of fun exploring this cool new feature! I love it but boy do I feel like a n00b playing around with PowerCLI after having seen some of Alan‘s or Luc‘s magic. Gabe also has a nice article on this topic… check it out, worth reading!

Changelog:
Edit 1: Changed naming scheme

• VMware ESXi 5.0 (Build 469512)
• VMware vCenter 5.0 (Build 456005) (vCenter Server Appliance also available as of today (26/08))
• VMware Data Recovery 2.0 (Build 433157)
• vSphere Storage Appliance 1.0
• VMware vShield Zones for vSphere 5 (Build 216288)
• Documentation link (docs also available in epub and kindle format!)
  • What’s New in VMware vSphere 5.0
  • VMware vSphere 5.0 Release Notes
• Some tools which will come in handy:
  • VMware vSphere PowerCLI 5.0
  • VMware vCenter Update Manager PowerCLI
  • VMware GuestAppMonitor SDK (HA Application Monitoring)
  • VMware vSphere Management Assistant 5.0 (vMA)
  • VMware vSphere CLI
• vSphere 5 Compatible and Updated Products:
  • vCenter Operations 1.0.1 (release notes)
  • VMware vCenter Capacity IQ 1.5.2 (release notes)

Evaluation Guides:

• VMware vSphere 5 Evaluation Guide – Volume One
• VMware vSphere 5 Evaluation Guide – Volume Two – Advanced Storage Features
• VMware vSphere 5 Evaluation Guide – Volume Three – Advanced Networking Features
• VMware vSphere 5 Evaluation Guide – Volume Four – Auto Deploy
• VMware Data Recovery Evaluation Guide

What’s new whitepapers (release at launch last month):

• What’s New in vSphere 5.0
• What’s New in VMware vSphere 5.0: VMware vCenter
• What’s New in VMware vSphere 5.0: Platform Whitepaper
• What’s New in VMware vSphere 5.0: Performance Whitepaper
• What’s New in VMware vSphere 5.0: Storage Whitepaper
• What’s New in VMware vSphere 5.0: Networking Whitepaper
• What’s New in VMware vSphere 5.0: Availability Whitepaper
• What’s New in VMware Data Recovery 2.0 Technical Whitepaper
• VMware vSphere Storage Appliance Technical Whitepaper
• What’s New in VMware vCenter Site Recovery Manager 5 Technical Whitepaper
• What’s New in VMware vCloud Director 1.5 Technical Whitepaper

By the way, did you know there were over 140 new features in vSphere 5.0? Check out my article on the VMware vSphere Blog for a full list and for a nice contest / challenge!

Changelog:
edit 1 – added links to VSA, Zones and Data Recovery)
edit 2 -  added eval guide links
edit 3 – added different management tools etc
edit 4 – added a list with compatible and updated products

• No Update Manager
• No Linked-Mode
• No support for the VSA (vSphere Storage Appliance)
• Only support for Oracle as the external database
• Embedded database, DB2, only supports 5 hosts and 50 VMs
• No support for vCenter Heartbeat

Now that you’ve seen the limitations why would you even bother testing it? You will still need Windows if you are running VUM and you can only use Oracle for large environments… Those are probably the two biggest constraints for 80% of you reading this and I agree they are huge constraints. But I am not saying that you should go ahead and deploy this in production straight away, I do feel that the VCVA deserves to be tested as it is the way forward in my opinion! Why? Most importantly, it is very simple to implement… Seriously setting it up takes a couple of minutes. You just import the OVF, accept the EULA, select the correct database type and start the vCenter service. Without any hassle it also includes a Syslog Collector service, Autodeploy and the Webclient. But that’s not all… If you look at it from a strategic perspective this is the first step. A first step towards a possible distributed vCenter solution, and I know some of you have been waiting on that for a while, so why not get your hands dirty straight away and start testing it.

• What’s New in vSphere 5.0
• What’s New in VMware vSphere 5.0: VMware vCenter
• What’s New in VMware vSphere 5.0: Platform Whitepaper
• What’s New in VMware vSphere 5.0: Performance Whitepaper
• What’s New in VMware vSphere 5.0: Storage Whitepaper
• What’s New in VMware vSphere 5.0: Networking Whitepaper
• What’s New in VMware vSphere 5.0: Availability Whitepaper
• What’s New in VMware Data Recovery 2.0 Technical Whitepaper
• VMware vSphere Storage Appliance Technical Whitepaper
• What’s New in VMware vCenter Site Recovery Manager 5 Technical Whitepaper
• What’s New in VMware vCloud Director 1.5 Technical Whitepaper