After running the “Private Investigator” design, a film noir theme, for almost 2 years, it was time for a redesign. I asked my good twitter friend Jenneke van Wijngaarden (@JennekePenneke) for help and ideas. Jenneke is well known for her graffiti art on walls and paintings, but she had never before created a design for a website. Nevertheless she took her pencil and drew a few designs and after looking at the beautiful curves of the lady in red, I just had to choose for the design you’re currently looking at.

See full post at: New design for GabesVirtualWorld

(Copied from the Veeam announcement)

Need to change your disaster recovery practices?

Join VMware vExpert Gabrie van Zanten, a principal consultant at Open Line for this LIVE webinar and discover how a strong replication strategy will improve your DR practices.

	Gabrie van Zanten is a VMware virtualization expert, the author on his ownweblog
	Rick Vanover, Veeam Product Strategy Specialist with extensive virtualization expertise
	Steven Duckaert, Veeam System Engineer with a focus on VMware and Microsoft technologies

22 May 2012 at 16:00 CEST / 10:00 EDT / 15:00 BST

Topics include:

• Your replication jobs
• Bandwidth throttling
• Replication in combination with backups
• Real-life replication challenges
• Veeam replication functionalities, such as replication mapping, replication seeding and more.

See full post at: Discover game changing replication for vSphere VMs

Did you know about VMware HA admission control coupled to VM reservations? To be honest I thought I knew, but recently I was pointed to some details that showed me I was wrong.

What I’m talking about is the cluster setting of “HA Admission Control” and how “Percentage of cluster resources reserved as failover spare capacity” and “Host failures the cluster tolerates” are related to the CPU and memory reservations at VM level. These settings will make sure that your HA cluster will reserve enough resources to recover from host failures, depending on how high you set the % of resources to be reserved, more host failures can be tolerated.

Where did I go wrong? Well I thought vCenter made the calculations for the HA spare capacity based on real usage, using 5min interval. But I was wrong. These calculations are not based on real life numbers but on the reservations you set at the VM level. Same goes for the “Host failures the cluster tolerates” setting, the slot size is based on the reservations being used per VM.

Auch, I felt a little embarrassed being wrong in this. Especially since I normally checked on reservations of VMs being set to zero if there was no special need for a reservation. But as I started asking around to people on what they used for their VM reservations, I learned that not many were using these VM reservations and more people then I expected also had the wrong idea about this.

So, to be clear once and for all:

The values used in calculations for “Host failures the cluster tolerates” and “Percentage of cluster resources reserved as failover spare capacity” are based on the CPU and memory reservations set at VM level.

And to proof that setting no reservations can overload your cluster, have a look at my lab environment where I have set NO reservations on any of the VMs. My three hosts have 8GB of RAM each and when you look at the current load, you can see that my current memory usage is 52%, 52% and 92% which makes a total of 15.7 GB of RAM in use of the 24GB I have in my lab. Which is 65%. Now the vSphere HA status box on the summary page of the cluster shows that I have a “Current Memory Failover Capacity” of 81%. Anyone can see that’s not right. If you’re asking why the 81% and not a full 100%, those 19% are lost on VM memory overhead. But it might be clear that I can’t power on another 81% of 24GB = 19GB of VMs and still have 25% spare HA failover capacity.

For details on how the calculations are made, check Duncan’s VMware HA DeepDive Guide, a must read.

Now I have two questions for you, please respond in the comments:

• The “make me feel a little better” question: Did you know about this?
• What is the default reservation on CPU and RAM you are using in your environment. Of course, special VMs will have different requirements, but as a ‘rule of thumb’ what is the % of reservation you set?

Update:

• Frank Denneman responded to my post on his blog: THE ADMISSION CONTROL FAMILY
• Chris Colotti also responded to my post on his blog: Bad Idea: Disabling HA Admission Control With vCloud.
• My colleague Menno De Liege wrote a post on how to easily change the reservation of a VM: HA Admission Control: Base VM reservation on percentage.

See full post at: VMware HA Admission Control and VM reservations

Customer with small vSphere environment of just two hosts had performance issues and they asked me to investigate the situation. When looking at the technical specs at first glance, you would suspect that this configuration should work. With just two hosts, each dual Quad core CPU, the enivornment had a total of 16 CPU cores. In total there were only 9 VMs running using a total of 23 vCPUs. Usually you can easily run 5 vCPUs per core, if not more.

Turned out there were a number of VMs with 4 vCPUs and 2 vCPUs that really didn’t need them. You can easily discover this by checking READY en  CO-STOP value in the vCenter performance charts. Go to the performance tab of your vSphere host and select advanced. Then select “Chart options” go to the CPU section, choose the “realtime” section and then on the right deselect all counters and only select “Ready” and “Co-Stop”. Click OK.

READY: The time a virtual machine must wait in a ready-to-run state before it can be scheduled on a CPU
CO-STOP: Amount of time a SMP virtual machine was ready to run, but incurred delay due to co-vCPU scheduling contention.

I made a list of all VMs, their vCPUs and checked per VM what their real CPU usage was over the past weeks. None of the VMs had excessive CPU usage and I noticed that downsizing the vCPUs wouldn’t be a problem. Unfortunately, this had to be done outside office hours. The vCPU assignment when I started investigating, remember each ESXi host has only 8 cores:

So I had two big Citrix VMs that where in use, but not heavily used, with each 4 vCPUs. An application server with 4 vCPU and a SQL server with 4 vCPU. The application server and SQL server had peaked to a max of 1 GHz in the past weeks. That is ONE GHz for a 4 vCPU VM. A bit overdone don’t you think?

Since I had to wait untill evening before I could down size, I decided to go for a small quick win and shuffle the VMs around, to create the following situation:

I put the two Citrix VMs together on one host, which would stop the ‘fight’ for free CPU cores. The second host now did get a bit more vCPUs to handle, but since the two big VMs didn’t need that much CPU time I figured it would be enough capacity on the host to at least make it to the evening without issues.

As the following image shows, the READY and CO-STOP values before and after the VMotion at 12:45PM. You can clearly see a big drop in READY and CO-STOP.

Later in the evening I would change the number of vCPUs for the vCenter Appliance VM from 2 to 1, the Application VM from 4 to 2 and the SQL VM from 4 to 2 vCPUs.

As the following image shows, you can again see a drop in READY and CO-STOP values. At 9:20pm both SQL and the Application server were shutdown and started again with 2 vCPUs. At 9:55pm vCenter was robbed from its 2^nd vCPU.

Conclusion: Think twice before you give VMs extra vCPUs which they don’t really need. You can negatively impact the performance of your environment since the vmkernel has to try and find a time slot in which it can give all vCPUs access to the physical cores.

See full post at: How too many vCPUs can negatively affect performance

Been fighting some problems with VMware Auto Deploy lately which turned out to be an easy to solve issue. I installed the first host in the cluster, which would NOT be deployed with Auto Deploy but had a local hard disk in it. Configured it the way I like it, set all the logging and network coredump location to be the vCenter host and then created a host profile. The network configuration consisted of just two vmnics (10Gbps) in a dvSwitch. The vmkernel port was of course on the dvSwitch. After this host was working fine, I copied the host profile and used this copied profile as the reference profile for the hosts that WOULD be using Auto Deploy.

When deploying the remaining hosts, I could get them to work the first time and register them in vCenter, but after the profile had been applied and the answer file was updated, the host would drop from vCenter. What happened is that after reboot the host would show in vCenter again, then a few seconds later vCenter would trigger applying the host profile and then the host would drop from the network. Closer investigation showed that when the host would return after reboot, it has a standard vSwitch with only a vmkernel portgroup on it, connected to one vmnic. As soon as the host profile is applied, the host will migrate the vmkernel port from the standard vSwitch to the dvSwitch.

However….. when a network coredump location is configured, the vmkernel port is “locked”. The vmkernel is unable to migrate the vmkernel port from the standard vSwitch to the dvSwitch and will fail. Problem is that it doesn’t fail back to the last good network configuration but it will just “leave it hanging”. As a result your host is disconnected from the network. You can reconnect it again by going to the DCUI and reset your network.

Solution: Don’t configure a network coredump location: esxcli system coredump network set –enable false 

See full post at: Adding ESXi host with dvSwitch through Auto Deploy fails

Had a small issue with VMware Site Recovery Manager (SRM) 5.0 today when performing a real failover of a single VM with a customer of mine. Nothing big, just using one VM one protection group, showing them that a failover would work. After recovery went fine, I started the reprotection and ran into a licensing error: “Not enough licenses”.

This customer had bought a 25 VM license pack and received one license key for this. I had entered this key in vCenter on site-A but I hadn’t entered this on site-B, because I was under the impression that in a Linked-Clone scenario the license could be used by both sites.

Digging through the admin guide I found the following:

SRM requires a license key that specifies the maximum number of protected virtual machines at a site. Larger licenses are often required when protecting large numbers of virtual machines.
-       Install keys at one site to enable failover.
-       Install keys at both sites to enable bidirectional operation including reprotection.
If your SRM Servers are connected with linked vCenter Servers, the SRM servers can share the same license key

I have always read this like: “Install the license key at one site and the other site knows about the key and will “share” the license”. While testing this at first install I never noticed this was an incorrect ‘translation’ because VMware SRM runs in evaluation mode if you don’t enter a license. After entering the 25VM license in site-A, the eval mode in site-B never complained when testing failover and reprotecting. But today the evaluation period had ended and when reprotecting the recovery plan, I did get the license error. I solved it by entering the same license key on site-B as I had used on site-A.

My conclusion: When using SRM 5 in a linked mode scenario, you should re-use the same license key on both sites.

My question to you: Would you agree different wording in this part of the admin guide could have made things more clear or did this just got lost in my translation? Let me know in the comments.

See full post at: Licensing VMware SRM 5.0

When installing vCloud Director in my homelab, I ran into an issue where the vCloud Director Agent cannot be installed into the ESXi host since the host is ran using VMware Auto Deploy. Installing that agent is useless because after a reboot, the ESXi host would be clean again. In vCloud Director you’ll be presented with an error during install: “The vCloud Director Agent version 1.5.0.453916 is required to be part of the boot image in order to prepare the host”.

Alan Renouf has a nice blogpost on this and how to solve it using PowerShell http://www.virtu-al.net/2011/10/03/auto-deploy-and-vcloud-director/ . Well, I’m not that much of a PowerShell wizard and since a few days a big fan of Auto Deploy GUI, so I tried to do the same using the Auto Deploy GUI.

Step 1: Get the vCloud Director Agent

After installing your vCloud Director cell, you’ll find the vCloud Director Agent on that VM in  /opt/vmware/vloud-director/agent/vcloudagent-1.5.0-453916.zip. Copy that zip file to a location where you can later on access it from your Windows desktop where the VI Client is running.

Step 2: Add the VIB to the depot

Click on the Software Depot tab and then right click to choose “Add Zip Repository” and add the ZIP file you just copied. In the bottom half of the screen you should now see the “vcloud-agent”.

Step 3: Make a new deploy image

Personally I like to use a different name for this image to make clear to me that this is a custom made image. Go to the “Image profile” tab and choose the ESXi5 image you want to use. Right click the image and choose CLONE. Give this new image a name. I used the ESXi-5.0.0-20111204001-standard image and changed the name to vCloud-ESXi-5.0.0-20111204001-standard. On the “Commit Change” question, click “NO”. Now make sure your image is selected in the top half and then check the list of modules in the bottom half. The vCloud Agent will NOT be there yet. Now right click the new image and select “Add Software Package”. In the wizard select the vCloud-Agent and finish the wizard. On the “Commit Change” question now click “YES”. In the task pane you should see a bundle being created. In my homelab it stays at 20% forever and then jumps to finish, mostly because it has to download stuf in the background. Just be patient and get some coffee. To save some time for the next time I want to use this image or edit it, I also do an export of the image.

Step 4: Create a new rule

Switch to the “Deploy Rule” tab and right click and select “Add” to create a new Deploy Rule. The wizard is very straightforward. Select the image you created, the host profile you want to attach and how to select your host (Vendor ID, IP address, Mac Address, etc).

Step 5: Connect the host to the image

On the “Hosts” tab you can now see your newly created rule and the old rule to which the host is connected. When you now right click one of the hosts and choose “Test Deploy rule compliance” and if needed “Repair Deploy Rule set”.

Step 6: Reboot your hosts

After Step 5 you’re actually ready to deploy the new image to your hosts. Put them in maintenance mode and reboot. When the host is available again you of course want to see if the vCloud Agent has been installed. Unfortunately this can’t be seen in the VI Client and you have to switch back to PowerShell. Mister Alan Renouf of course has a nice PowerShell oneliner for this:

Connect-VIServer MyVIServer -User Administrator –Password “Pa$$word”
 Get-VMHost | Sort Name | Foreach {
 $ESXCLI = Get-EsxCli -VMHost $_ -ErrorAction SilentlyContinue
 $ESXCLI.software.vib.list() | Where { $_.Name -like "*vCloud*"} | Select @{N="VMHost";E={$ESXCLI.VMHost}}, Name, Version
 }

For me the result on my three ESXi hosts was:

autoesx02.vanzanten.local   vcloud-agent   1.5.0-453916
autoesx03.vanzanten.local   vcloud-agent   1.5.0-453916

Which told me that these hosts did have the vCloud Agent and my first host didn’t. (Hadn’t rebooted yet). After this you can continue your vCD installation. Have fun!

See full post at: Using Auto Deploy GUI to inject vCloud Agent into image

On the VMware Labs pages you’ll find a number of great Lab projects, so called “Flings”. These are unsupported projects by VMware employees you can download and use. One of the latest VMware Lab Flings is the “Auto Deploy GUI”  created by Massimiliano Daneri which makes auto deploy of your ESXi hosts a breeze.

As you probably know, VMware Auto Deploy is a new feature in vSphere 5 that enables you to run your ESXi5 hosts stateless in memory. No disk, no USB drive is required, the host uses PXE boot to load the hypervisor and is completely run in memory. For all those admins using VMware Auto Deploy and getting sick of doing everything through the PowerShell command line, I can highly recommend the Auto Deploy GUI. It makes your life so much easier.

My series on VMware vSphere 5 Auto Deploy:

vSphere 5 – How to run ESXi stateless with vSphere Auto Deploy
vSphere 5 Auto Deploy PXE booting through Cisco ASA firewall
Updating your ESXi host using VMware vSphere 5 Auto deploy
My first Auto Deploy design for real production environment

A quick walkthrough

The VMware Auto Deploy GUI is installed as a plug-in in your VMware VI Client. Unlike many plugins, this is not just a webpage shown in the vCenter GUI but really integrates into the interface, you won’t even notice it is a separate plug-in you’re using, very nice. In the VI Client you’ll find the Auto Deploy GUI in the “solutions and appliances” tab. Start it from there and you’re welcomed by the “Auto Deploy” screen which shows to which vCenter Auto Deploy server you are connected.

When creating a new deployment image, the first step is to add a software repository where the binaries can be downloaded. This can be done on the first tab, called “Software Depot”. In a very simple way you can add a software depot URL, for example VMware’s own software repository: https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml. In the bottom half of the screen you’ll see what is already locally available.

The next step is choosing the ESXi image you want to use for deployment. This can be done in the “Image Profile” tab. You can see the images available and then choose what you want to do with it, clone, remove, export, commit and “Add software packages”. Want to add some extra VIB files? No problem, there is a nice wizard for that. If you want to create your own very custom build, just clone an existing image and add your custom software to it.

Now your image is ready and you need to deploy it. This is where you go to the “Deploy rule” tab and create a new deploy rule. Again an easy to use wizard will guide you through the process. The wizard even helps you with defining all the parameters you want to use in your rule set like vendor ID, Mac address, IP address, etc.

After the wizard has finished, you’re only left with creating the answer files in the “Answer template” tab and then you’re done. You’re ready to deploy your image. I won’t get any easier.

Congrats to Massimiliano for building such a great tool. This is more than the average “tool” that helps you a little when fighting with command lines, setting changes, etc. This is a full-blown product and when using it, you’ll never have to see that ugly Auto Deploy PowerShell command line again. I hope VMware will soon support this Fling and add it to vCenter as a standard installation option.

See full post at: Auto Deploy GUI – a new VMware Labs fling

Last week I was asked by a customer to build a new VMware vSphere 5 infrastructure in which they would like to use Auto Deploy for the ESXi 5 hosts. Of course I told them that Auto Deploy was a first release but I didn’t push that too hard, because designing and deploying it for real production environments is also a challenge I hadn’t been able to take up yet. The environment consists of two sites; each site has an EMC VNX 5300 storage array which replicates to the partner. Per site we have 2 Cisco UCS blades in which 10 blades have been assigned for the VMware vSphere 5 environment. Each blade will use the converged FCoE adapter and will be presented to the ESXi hosts as two physical nics and two physical HBAs.

My series on VMware vSphere 5 Auto Deploy:

vSphere 5 – How to run ESXi stateless with vSphere Auto Deploy
vSphere 5 Auto Deploy PXE booting through Cisco ASA firewall
Updating your ESXi host using VMware vSphere 5 Auto deploy
My first Auto Deploy design for real production environment

vCenter and ESXi host configuration

The vCenter design also includes a VMware Site Recovery Manager 5 design, should Site-A fail we can quickly fail over to site-B using VMware SRM and vice versa.  vCenter is deployed as a virtual machine and the Auto Deploy service will be running on the vCenter Server.

Should site-A fail because of power failure it would be impossible to get the ESXi host up and running again, since the vCenter VM would be down, including the Auto Deploy services. If the vCenter VM would be running in a cross-site design (vCenter for site-A running on ESXi hosts on site-B), the ESXi would be able to boot if power is restored to site-A because they would boot using vCenter and Auto Deploy from Site-B. However, for a VMware SRM design this would give me problems since losing Site-A would also lose vCenter-B, which I need to set the wheels of a VMware SRM site recovery in motion. To make a quick recovery possible after all ESXi hosts went down, I decided to have the first ESXi host in the blade center use boot from SAN and install ESXi on the “local” boot from SAN disk of 5 GB. The vCenter VM, together with the SQL VM, will always run on this first ESXi host.

Network

Between the two sites the management VLAN that I will be using is a layer2 stretched VLAN. On this VLAN the customer has a clustered DHCP solution. My first thought was to give each blade a separate physical nic for Auto Deploy because during the boot process only the native VLAN can be used. Since the customer didn’t use the native VLAN for other uses, like switch monitoring, I was free to redirect the native VLAN to the management VLAN. In other words, on the physical switch they created some trunk ports to the ESXi hosts in which the management VLAN was passed as if it was there native VLAN. The network design is based on the distributed vSwitch.

DHCP configuration

Since the customer isn’t that experienced yet using Auto Deploy, I wanted them to have to do as little management as possible on the PowerShell command line. Therefore I created a ruleset that included a large range of IP addresses which enables them to assign new blades by only changing a DHCP entry.

At the start of this project there a 10 blades on each site but since the whole IP ranges was mine to use, I reserved 20 IP addresses on each site and used these in the PowerShell rules. The following is the code I used to create the rule:

New-DeployRule –Name “Site-A-Rule” –Item “ESXi-5.0.0-20111204001-standard”, “Site-A”, “Site-A-Basic” –Pattern “ipv4=192.168.0.100-192.168.0.120”

The above code creates a rule named “Site-A-Rule” that will add the Auto Deploy hosts to cluster “Site-A”, using host profile “Site-A-Basic” if they meet the requirement of their IPv4 being between 192.168.0.100 and 192.168.0.120.

If they decide to add an extra blade to their current environment, all they need to do is add a new DHCP reservation based on the Mac address in the DHCP server and the new blade will be added to the cluster.

DHCP entries:

• Per host a reservation based on Mac address
• Use the required DNS name in the reservation for the ESXi host
• The following DHCP records are needed for the ESXi host to find the PXE boot server:

• 066 – Boot server host name:   <ip of TFTP / PXE boot server>
• 067 – Boot file name: undionly.kpxe.vmw-hardwired

Host configuration and host profiles

This was a bit of a painful experience. Where I would have expected most problems with the Auto Deploy part during implementation, it turned out the host profiles are the real problem.

I have created two profiles per site. The first profile is used for the host that boots from SAN and the other profile is for the remaining hosts on that site. I did this because of an issue with compliance failures as described in KB 2002488. When using creating a separate profile for the host that boots from SAN, the KB work around can be avoided. When using the work around you would also lose the ability to control the Path Policy (PSP) settings.

Another important KB is KB 2001994, which lists a few options that cannot be used in host profiles. To me, the following options are the most important ones:

• ScratchConfig.ConfiguredScratchLocation
• ScratchConfig.CurrentScratchLocation
• Syslog.Local.DatastorePath

I’ve not yet found a good replacement for the scratch location. When checking the scratch location on a host, it is by default set to /tmp/scratch. Reading KB1033696 I learned:

“It is recommended, but not required, that ESXi have a persistent scratch location available for storing temporary data including logs, diagnostic information and system swap.” Since logs and diagnostic data are redirected to the vCenter server, only temporary data is stored in the scratch location. And since Auto Deploy host are seldomly updated using Update Manager, my guess is that the scratch location will be rarely used. Therefore I decided to leave the scratch location to the default /tmp/scratch.

Not having the Syslog.Local.DatastorePath isn’t such a big deal since you can use a syslog server, which is also included in vCenter 5:

-       Syslog.global.loghost: udp://192.168.0.50:514

The diagnostics data is redirected to vCenter using the Network Coredump setting in the host profile. This can be found at:

-       Networking Configuration – Network Coredump settings – Fixed Network Coredump policy.

To configure this for the reference host I used the following commandline commands:

esxcli system coredump network set –interface-name vmk0 –server-ipv4 194.104.240.212 –server-port 6500

esxcli system coredump network set –enable true

Problems with host profiles

During configuration of this environment I ran in to quite some issues with host profiles. A quick list of minor and major issues:

Time intensive applying of changes
When making a change in the reference profile and then changing all the other hosts takes a lot of time. In the beginning there were no VMs yet, so I could put 9 hosts into maintenance mode at the same time and apply the new profile to all the hosts ath the same time.

However, for each host again you are presented a full list of all the changes to be applied and have to click “finish” for each host again. To me the summary screen isn’t really needed because the same info you get when checking the host to see if it is compliant. Even better would be if I could select all hosts and have vCenter make the compliant automatigically by placing them into maintenance mode one by one and applying the profile.

Profile configuration changes lost
When updating a profile from the reference host, the “Enabled / disable profile configuration” settings are lost. These settings you might want to use because of KB2002488 “Applying a host profile causes compliance failure”.

Network changes causes hosts to not reconnect
Changing the network configuration for a host often results in the host not reconnecting after a reboot. This mostly happens when the host has to switch to a distributed vSwitch. Resetting the network configuration using the DCUI for that host solves it.
Show differences
When I check a host for compliance and it turns out it is not compliant, I do see a list of the areas in which the host is not compliant, but it doesn’t show me WHY it isn’t compliant. When I need 10 changes to make it compliant that is no issue, but for just one tiny change, it would be great to see what exactly the difference is. Maybe I can just correct it manually and save myself the trouble of putting the host in maintenance mode, applying the profile and exiting maintenance mode.

Setting root password
When configuring a root password, it seems that host profiles don’t check for the correct password or at least don’t check the password setting when checking for compliancy. It also looks as if the “set fixed password” option is lost when updating the profile from the reference host.

Updating from reference host
When updating your current profile from the reference host, it would be nice if you could compare the changes. This would probably trigger you on the fact that some settings will be lost or have to be set again, like the fixed password.

“DNS configuration doesn’t match the specification”
Often, when re-applying a number of settings at once, I still get an incompliance error: “DNS configuration doesn’t match the specification”. After applying the profile for a second time, this error disappears.

Ruleset FaultTolerance doesn’t match the specification
This is an error that sometimes appears and often disappears after setting a host into maintenance mode and exiting from maintenance mode, without having to re-apply the profile.

Conclusion

If your customer is very critical and wants everything to run smooth 100% of the time, you’d better stay away from Auto Deploy at this moment because the host profiles will give you some unpredicted results and sometimes some issues that are only solved by some more manual intervention. However, this never causes any production problems, its just that sometimes it takes a bit longer and more effort to apply the changes you wanted to apply and this is always done on hosts while in maintenance mode. But then again, once stuff is running smooth, you will hardly every change your ESXi host configuration.

If I was an admin for a larger environment, I wouldn’t mind a little extra manual labor especially since even with these extra interventions, you’ll probably still have LESS work deploying and upgrading hosts using Auto Deploy than in earlier versions.

Update

In the comment section Tom Fotja posted a question on which I want to respond in the post itself, because it adds to the design. The question from Tom was: “You say that the vCenter is always on the first blade. What if you do a maintenance of the first blade? You have to vMotion vCenter away. And then you end up with not very resilient set up. I think management cluster with statefull booting is a must for autodeploy.”

Yes, when performing maintenance on the fist host, I vMotion the vCenter and SQL VM to the second host in the cluster. And yes, there is less resillience for vCenter then because the second host is not running on local storage. The consequence would be that if now the whole site fails, I would have trouble getting all my hosts running again since they rely on vCenter.

My considerations on why having only one host on physical store (boot from SAN) is enough in this cluster are as follows:

• The time an ESXi host is in maintenance mode is always relatively short. When performing an update or even reinstalling the host, it will be in maintenance mode for 30min max. Even when performing hardware changes, I think you won’t be in maintenance mode for more than one hour.
• Actually, with the UCS blade profiles being hardware independent, if extensive maintenance would have to be performed on the physical blade, I would probably first switch blades. I would give another blade the role of first ESXi host.
• When the first ESXi host is in maintenance mode and the second ESXi host would fail, VMware HA will pick up the failure of that host and bring vCenter and SQL online again.

With the above points I conclude that the maximum downtime of the first ESXi host is very low. A maximum of one hour. Since we all know mister Murphy visits you when you least expect it, it could still happen that the whole cluster goes down when the first host in maintenance mode. Should that happen, recovery could be done in the following ways:

• When first ESXi was in maintenace mode because of updates, you could just restart it again and reregister the vCenter and SQL VM to the host.
• When first ESXi was in maintenance mode because the blade was unavailable, a different blade can be assigned the profile of the first host and boot as if it is the first ESXi host.
• If the failure that hits the site at the most unfavorable time has a bigger impact and makes my blade center unavailable, I would have lost access to my SAN too, so my only recovery is VMware SRM.

The chances of this all happening are small enough to NOT buy an extra vCenter license for a management cluster. Also this cluster would have to be in different rack, different blade center and on different SAN to offer bigger resilience. The extra costs are too big for just that little extra safety.

See full post at: My first Auto Deploy design for real production environment

Last week I received a copy of Mike Laverick’s new book: “Administering VMware Site Recovery Manager 5.0″. Just in time actually since I was finishing a project with a customer where I implemented VMware vSphere 5 and VMware Site Recovery Manager 5.0. Gave me a great opportunity to check if the book would help me solve some issues I ran into while deploying SRM 5.0.

First let me start by saying that the book is very well written, as with the previous books Mike wrote. A very useful part is chapter 2 through 6 in which Mike walks with you through configuring replication for Dell EqualLogic, EMC Celerra, EMC Clariion, HP StorageWorks P4000 and NetApp SnapMirror. Very useful because these storage basics are essential for understanding VMware SRM much better.

In the next chapters Mike will guide you through the installation and configuration of VMware SRM, followed by a chapter on scripting site recovery. This chapter shows you how to create testing networks, add VMs to the inventory and resignaturing VMFS volumes from the command prompt. It contains some very valuable scripts. And last but not least, a chapter on how to upgrade from VMware SRM 4.1 to VMware SRM 5.0.

To answer my questions from the intro, yes I did get the answers I was looking for. During configuration I ran into some certificate issues which are discussed in the installation VMware SRM 5.0 and even the storage configuration questions I had were answered in the EMC Clariion chapter. If that ain’t the ultimate proof that this is the book you need….

More details on “Administering VMware Site Recovery Manager 5.0″ on the Pearson website.

Administering VMware Site Recovery Manager 5.0 By Michael Gordon Laverick
Published Dec 28, 2011 by VMware Press. Part of the VMware Press Technology series.

ISBN-10: 0-321-79992-5
ISBN-13: 978-0-321-79992-0

See full post at: Review: Administering VMware Site Recovery Manager 5.0