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.

The Auto-Deploy GUI fling is an 8MB download and allows you to configure auto-deploy without the need to use PowerCLI. It comes with a practical deployment guide which is easy to follow and should allow all of you to test this in your labs! Download it it now and get started!

source
The Auto Deploy GUI is a vSphere plug-in for the VMware vSphere Auto Deploy component. The GUI plug-in allows a user to easily manage the setup and deployment requirements in a stateless environment managed by Auto Deploy. Some of the features provided through the GUI include the ability to add/remove Depots, list/create/modify Image Profiles, list VIB details, create/modify rules to map hosts to Image Profiles, check compliance of hosts against these rules and re-mediate hosts.

“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.

I figured it should be possible to achieve this using a CNAME but also recalled something around vCenter screwing this up again. I tested it anyway and with success. This is what I did:

• Added both NFS servers to DNS
• Create a CNAME (DNS Alias) and pointed to the “active” NFS server
• I used the name “nasdr” to make it obvious what it is used for
• Created an NFS share (drtest) on the NFS server
• Mount the NFS export using vCenter or though the CLI
• esxcfg-nas -a -o nasdr -s /drtest drtest
• Check the UUID using vCenter or through the CLI
• ls -lah /vmfs/volumes
• example output:
  lrwxr-xr-x    1 root     root           17 Feb  6 10:56 drtest -> e9f77a89-7b01e9fd
• Created a virtual machine on the nfsdatastore
• Enabled replication to my “standby” NFS server
• I killed my “active” NFS server environment (after validating it had completed replication)
• Changed the CNAME to point to the secondary NFS server
• Unmounted the volume old volume
• esxcfg-nas -d drtest
• I did a vmkping to “nasdr” just to validate the destination IP had changed
• Rescanned my storage using “esxcfg-rescan -A”
• Mounted the new volume
• esxcfg-nas -a -o nasdr -s /drtest drtest
• Checked the UUID using the CLI
• ls -lah /vmfs/volumes
• example output:
  lrwxr-xr-x    1 root     root           17 Feb  6 13:09 drtest -> e9f77a89-7b01e9fd
• Powered on the virtual machine now running on the secondary NFS server

As you can see, both volumes had the exact same UUID. After the fail-over I could power-on the virtual machine. No need to re-register the virtual machines within vCenter first. Before I wanted to share it with the world I reached out to my friends at NetApp. Vaughn Stewart connected me with Peter Learmonth who validated my findings and actually pointed me to a blog article he wrote about this topic. I suggest to head-over to Peter’s article for more details on this.

But, just like Rob, you might not agree with this and rather have SDRS handling balancing on a file per file basis. That is possible and we documented this procedure in our book. I was under the impression that I blogged this, but just noticed that somehow I never did. Here is how you change the affinity rule for the current provisioned VMs in a datastore cluster:

1. Go to Datastores and Datastore Clusters
2. Right click a datastore cluster and select “edit settings”
3. Click “Virtual machine settings”
4. Deselect “Keep VMDKs together”
1. For virtual machines that need to stick together you can override the default by ticking the tick box next to the VM

Also check out this article by Frank about DRS/SDRS affinity rules, useful to know!

And the actually migrations being spawned:

Yes, this is the true value of Storage DRS… initial placement recommendations!

Cannot initialize property ‘vami.netmask0.VM_1′ since network ‘VM Network’ has no associated IP Pools configuration.

I figured this would be simple so I jumped back to “home” and went to the network section… Nothing around IP Pools. Even on a host or cluster layer there was nothing. Luckily my colleague Cormac jumped in and said check the “Datacenter” object, there should be an IP Pool tab there. He was right. Weird place and definitely something that needs to be improved. Anyway, configuring an IP Pool itself, now that I found it, was easy:

1. Click your Datacenter object
2. Go to the “IP Pools” tab
3. Click “Add”
4. Fill out the details:
1. Subnet: which network will be used and what is the mask? (You can use a subnet calculator if you don’t know…)
2. Enter the details of the gateway
3. Specify a range, the format is “10.1.1.10#10″, this would result in a range from 10.1.1.10 until 10.1.1.19 (10 addresses counting from .10)
4. Don’t forget to tick the “Enable IP Pool” check box
5. Click on the “Associations” Tab and associate it to a network!
6. Also, fill out the DNS and proxy details if and when required.
5. This is what it should look like:
   

It is as simple as that, but indeed not easy to find hence the reason I figured a short article was in place.

PS: Creating a range and enabling the “IP Pool” is not required. “Enable IP Pool” enables the use of the Range. In this example I had to use a range as I could only use a specific range of this subnet.

Don’t miss VMworld 2012!
Barcelona October 9-11

Learn about the latest virtualization technologies and strategies which can help your organization realize its’ vision for a cloud computing approach to IT.

So you guys might want to update your calendar!

Allocation Pool

No changes have been introduced with vCloud Director 1.5 compared to 1.0 for the “Allocation Pool” allocation model. Below are the characteristics of this allocation model and the resource pool / vm construct used on the vSphere layer:

• Pool of resources of which a percentage will be guaranteed
  • A reservation will be set to guarantee resources on a resource pool level
  • By default the resource pool reservations on CPU is 0% and memory 100%
  • Tenant has a guaranteed set of resources and has the ability to burst to the upper limit
  • The resource pool is not expandable!
• VM Level characteristics
  • No reservations or limits set on a per VM level for CPU
  • Reservations set on a per VM level for memory. This reservation is based on the percentage of guaranteed resources.

Pay-As-You-Go

Nothing has changed for Pay-As-You-Go either. I slightly changed the wording though to make it more obvious what happens on a vSphere layer:

• Percentage of resources guaranteed on a per VM level
  • A reservation and a limit will be set on a VM level
  • By default the VM reservation on CPU is 0% and memory 100%
  • By default the vCPU speed is set to 0.26GHz, which means you vCPU will be limited to 0.26GHz
• The Org vDC resource pool is just an accumulation of all reservations set on a per VM level
• Note that this will include the memory overhead per VM!
• The resource pool is set to expandable

Reservation Pool

When looking at the vSphere layer it appears that not much has changed. The characteristics are still the same from a Resource Pool and virtual machine perspective… However I spotted something which was apparently already part of vCoud Director 1.0 but somehow I missed this. vCloud Director 1.x offers you the capability to add a reservation for CPU and memory and even allows you customize the shares! None of the other allocation models allow you to do this!

• Fully guaranteed pool of resources
  • A reservation will be set to guarantee resources on a resource pool level
• No reservations or limits set on a per VM level for CPU
• Note that is is possible to set a reservation/limit for CPU or Memory with vCloud Director 1.x on a per VM level. See screenshot below, this is configurable on a per virtual machine basis!

• VMware vCloud Director Appliance:
  username = root
  password = Default0
• VMware vCloud Director Appliance/Oracle Database 11g R2 XE instance:
  username = vcloud
  password = VCloud