But what about using vShield Edge? If you look at how vShield Edge is used in a vCloud Director environment, mainly NAT’ing and Firewall functionality, you could use it in exactly the same way for your VMs in a DR enabled environment. I know there are many Apps out there which don’t use hardcoded IP adresses and which are simple to re-IP. But for those who are not, why not just leverage vShield Edge… NAT the VMs and when there is a DR event just swap out the NAT pool and update DNS. On the “inside” nothing will change… and the application will continue to work fine. On the outside things will change, but this is an “easy” fix with a lot less risk than re-IP’ing that whole multi-tier application.

I wonder how some of you out in the field do this today.

After my article this week about (ab) using the SRA provided through Site Recovery Manager to fail-over any LUN I expected some people reaching out to me with additional questions. One of the questions which came in more than once was “is it possible to do a test-failover of a LUN which is not managed by the SRM infra”? I guess the short answer is yes it is. The long answer is: well it depends on what your definition of a “test-failover” is. Of course booting up a physical machine from SAN while keeping the same IP etc would cause conflicts. I am also not going to show you how to re’ip your physical machines as I expect you to know this. From an SRM perspective how exciting is this?

To be honest, not really. The same concept applies. For a test-failover SRM calls the SRA by a script called “command.pl” and it feeds it XML. The following lines of XML are relevant for this exercise, but the critical one is “TestFailoverStartParameters”:

--> <TestFailoverStartParameters>
--> <ArrayId>BB005056AE32820000-server_2</ArrayId>
--> <AccessGroups>
--> <AccessGroup id="domain-c7">
--> <Initiator type="iSCSI" id="iqn.1998-01.com.vmware:localhost-11616041"/>
--> <Initiator type="iSCSI" id="iqn.1998-01.com.vmware:localhost-4a15366e"/>
--> <Initiator type="NFS" id="10.21.68.106"/>
--> <Initiator type="NFS" id="10.21.68.105"/>
--> </AccessGroup>
--> </AccessGroups>
--> <TargetDevices>
--> <TargetDevice key="fs14_T1_LUN1_BB005056AE32800000_fs10_T1_LUN1_BB005056AE32820000">
--> <AccessGroups>
--> <AccessGroup id="domain-c7"/>
--> </AccessGroups>
--> </TargetDevice>
--> </TargetDevices>
--> </TestFailoverStartParameters>
--> </Command>

Now in our case we want to fail-over a random non vSphere LUN. We will need the “initiator” (server(s)) who will need to see be able to see this LUN and we will need the LUN identifier. All of this can either be found in the SRM log files (LUN identifiers) or on the physical server (initiator details). If you would call command.pl and feed it the XML file the SRA will request the array to create a snapshot and give the host access to that snapshot. Now it is up to you to take the next steps!

It is no rocket science. Anything SRM does with the SRA you can do from the command line using command.pl and a custom XML file. As mentioned in the comments in my previous article, I know people are interested in using this for Physical Hosts… I will discuss this internally, but for now don’t come close, it is not supported!

Last week I received a question and I figured I would dive in to it this week. The question was if it is possible to fail-over LUNs using VMware Site Recovery Manager (SRM) which are not part of the Cluster which SRM “manages”. In other words, can I fail-over a LUN which is attached to a physical Windows Server or to a completely separate VMware Cluster? Before we continue, I did not hack SRM itself, neither did I make any changes to the SRA.

Lets briefly explain what SRM does normally when you go through the process of of creating a DR plan. Now this is slimmed down with only focussing on the relevant stuff for this question:

• First it will discover the devices using the Storage Replication Adapter (SRA)
• It then discovers all LUNs using the SRA
• It show the replicated LUNs containing VMs to the admin
• Admin can use these in his plan and “protect” the VMs appropriately

I decided to install SRM in a nested environment using the Celerra Uber VSA. I installed the VNX SRA and configured it and went through some of the log files just to find a piece of evidence that my plan is even possible. For Windows 2008 you can find the SRM Log Files in this location by the way:

%ALLUSERSPROFILE%\VMware\VMware vCenter Site Recovery Manager\Logs\

Other locations are documented in this KB. When I created the environment I created multiple LUNs with different sizes to make them easily recognizable. The LUN which is replicated but not exposed to our vCenter/SRM environment is 25GB and the LUN which is exposed is 30GB. This is what the log files showed me when I did a quick find on the size:

(Production) fsid=14 size=30000MB alloc=0MB dense  read-write
path=/srm01/fs14_T1_LUN1_BB005056AE32800000/fs14_T1_LUN1_BB005056AE32800000 (snapped)

(Production) fsid=16 size=25000MB alloc=0MB dense read-write
path=/vc01/fs16_T1_LUN2_BB005056AE32800000/fs16_T1_LUN2_BB005056AE32800000 (snapped)

As you can see both my 25GB and my 30GB LUN is listed. I added a name to it which also allows me to quickly identify it “srm01″ and “vc01″, where “vc01″ is the one which is not managed by SRM.

So how does SRM get this information? Well it is actually pretty straight forward, SRM calls a script which is part of the SRA. SRM feeds this script XML. This XML code contains the commands / details required. I’ve written about this a long time ago when I was troubleshooting SRM and it is still applicable:

perl command.pl < file.xml

Now the XML file is of course key here… How does that need to be structured and can we use, or should I say abuse, it to do a fail-over of a LUN which is not “managed” by SRM/vCenter. Well I started digging and it turns out to be fairly straight forward. Keep in mind the disclaimer at the top though, this is not what the SRA’s were intended for… this is purely for educational purposes and far from supported. Again the logfiles exposed a lot of details here, but I stripped it down to make it readable. This is the response from the SRA when SRM asked for details on which devices are available:

2012-01-09T12:14:53.583-08:00 [05388 verbose 'SraCommand' opID=7D6C5634-00000023] discoverDevices responded with:
--> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
--> <SourceDevice state="read-write" id="1-1">
--> <Name>fs14_T1_LUN1_BB005056AE32800000</Name>
--> <Identity>
--> <Wwn>60:06:04:8c:ab:b2:88:c0:59:40:72:24:1b:5f:77:72</Wwn>
--> </Identity>
--> <TargetDevice key="fs14_T1_LUN1_BB005056AE32800000_fs10_T1_LUN1_BB005056AE32820000"/>
--> </SourceDevice>
--> <SourceDevice state="read-write" id="1-2">
--> <Name>fs16_T1_LUN2_BB005056AE32800000</Name>
--> <Identity>
--> <Wwn>60:06:04:8c:b8:50:22:96:0c:0b:bf:d8:59:0b:a1:75</Wwn>
--> </Identity>
--> <TargetDevice key="fs16_T1_LUN2_BB005056AE32800000_fs12_T1_LUN3_BB005056AE32820000"/>
--> </SourceDevice>
--> </SourceDevices>

Now if you look at SRM and try to make a Protection Group plan you will quickly discover that only those Datastores which have a VM hosted on there can be added. This is shown in the screenshot below.

As mentioned SRM filters out the “irrelevant LUNs”, to me this LUN wasn’t irrelevant however. So what’s next? I decided to initiated a fail-over and to look at the log files. When the fail-over is initiated the following is issued by SRM, again I stripped some details to make it more readable:

--> <FailoverParameters>
--> <ArrayId>BB005056AE32820000-server_2</ArrayId>
--> <AccessGroups>
--> <AccessGroup id="domain-c7">
--> <Initiator id="iqn.1998-01.com.vmware:localhost-11616041" type="iSCSI"/>
--> <Initiator id="iqn.1998-01.com.vmware:localhost-4a15366e" type="iSCSI"/>
--> <Initiator id="10.21.68.106" type="NFS"/>
--> <Initiator id="10.21.68.105" type="NFS"/>
--> </AccessGroup>
--> </AccessGroups>
--> <TargetDevices>
--> <TargetDevice key="fs14_T1_LUN1_BB005056AE32800000_fs10_T1_LUN1_BB005056AE32820000">
--> <AccessGroups>
--> <AccessGroup id="domain-c7"/>
--> </AccessGroups>
--> </TargetDevice>
--> </TargetDevices>
--> </FailoverParameters>

I guess we should be able to work with this! Using the “discoverdevices” information and combining it with the “Failover” information I should be able to construct my own custom XML file. After creating this XML file I should be able to fail-over any LUN which is part of the selected device… What is my plan? I am planning to change the following:

• Initiator id
• TargetDevice key

I wasn’t sure if I needed to change the AccessGroup so I figured I would just test it like this. I called the script as follows:

<path to perl>\bin\perl.exe command.pl < file.xml

I watched a whole bunch of messages pass by and then looked at the Celerra when then fail-over commend was completed and noticed the following:

And of course within the “unmanaged” vCenter you can see it:

Successful fail-over of a LUN which wasn’t part of an SRM Protection Group! Yes, when you replace the Initiator ID even the masking is correctly configured. The only thing left would be either resignaturing the volume or mounting the volume. This of course depends on the OS owning the volume and the desired end result. All in all, a nice little experiment… Once again, don’t try this in your own environment, it is far from supported!

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

Now lets give the raw facts first, SRM does not support Storage vMotion and SRM does not support Storage DRS. The reason that SRM does not support Storage vMotion (and subsequently Storage DRS) is because it changes the location of the virtual machine without SRM being aware of it. After the location of the virtual machine has changed the VM that was originally protected by SRM will not be protected anymore which can have an impact on your RTO. These are the raw facts. I have requested the SRM team to document this in a KB to make sure everyone understands the reason and the impact.

The question of course is… will it work? My colleague Cormac has tested it and you can read his observations here.

This statement is documented in the SRM releasenotes: http://www.vmware.com/support/srm/srm_releasenotes_5_0_0.html

Interoperability with Storage vMotion and Storage DRS:
Due to some specific and limited cases where recoverability can be compromised during storage movement, Site Recovery Manager 5.0 is not supported for use with Storage vMotion (SVmotion) and is not supported for use with the Storage Distributed Resource Scheduler (SDRS) including the use of datastore clusters.

** update: I followed the documentation which apparently was incorrect. Documentation bug has been filed, should be update in the near future. **
** update: Link to SRM releasenotes with statement added. **

Paul Maritz is taking the stage… Taking the next step in towards the more automated world.

We need to make infrastructure become something that people can depend on and focus on what is important to their business. Navigating your way forward offering a more dynamic infrastructure that will support your existing applications. Using a more flexible infrastructure, allowing people to take resources and aggregate to larger pools reducing operational costs by automating the use of these resources. More and more use of social media and use of mobile devices to connect anytime anywhere and most importantly securely.

Today we will be talking about  a more efficient infrastructure with exists of three stages IT Production, Business Production and IT as a Service. In 2009, the VI 3 era, 30% of the workloads were virtualized…. in 2010 with vSphere 4 we reached 40% and it is expected that in 2011 we will hit 50% virtualized with the majority on vSphere.

Accelerating and Amplifying business agility with vSphere 5! Not only vSphere 5 but the worlds first Cloud Infrastructure suite! In addition to vSphere 5 today we announce vSphere Site Recovery Manager 5 (Business Continuity), vCloud Director 1.5 (Policy, Reporting, Self-Service), vCenter Operations 1.0.1 (Monitoring and Management), vShield 5 (Security and Edge functionality).

VMware vCloud = Hybrid. Your private cloud experience needs to be similar to public cloud experience. VMware allows this through the vCloud offering and vCloud Service Providers. Trusted vCloud partners like Colt, Bluelock, Singtel, Verizon, NYSE Euronext, Softbank and CSC are some of the enablers for this.

Steve Herrod up on stage… I expect it is about to get more technical

Why do these new products matter and how do they fit together. Accelerating the adoption by increasing scalability. ESX 1.0 capable of 5000 IOps, ESX 2.0 ~ 7000 IOps, VI 3 100.000 IOps, vSphere 4 300.000 IOps and vSphere 5.0 1.000.000 IOps. Besides performance availability is key. Both HA and FT have been enhanced and of course SRM 5.0 has been released. Added to SRM 5.0 is vSphere Replication. vSphere Replication allows you to use the network to replicate between sites and different arrays. It will allow you to replicate more workloads with a lower costs. SRM is about datacenter mobility, not only for an outage but also pro-actively moving datacenters after an acquisition.

What does cloud computing really mean? Being able to order what you need and what without knowing what happens behind the scenes. IT will behind the scenes validate if they meet the consumers requirements. vCloud Director is all about Simple Self-Service. Deploy virtual machines but more importantly create new vApps and offer these in your own “app store”. The IT Cloud of the producer is all about offering agility. Virtualization enables automation in a way unheard in a physical environment.

Typically multiple tiers are offered within a cloud environment. The VMware Cloud Infrastructure enable you to do so. Intelligent Policy based Management is key with vCloud Director 1.5. Linked Clones is a very important feature to provision virtual machines “aggressively” within the system. It allows for fast provisiong and save up to 60% of storage.

Profile-Driven Storage and Storage DRS are part of vSphere 5.0. It enables you to map different arrays in to logical entities by a concept called a “datastore cluster” and link these to a profile. Virtual machines will be tagged with a profile and this allows you to validate compliancy. Storage DRS does for storage what DRS does for compute resources. Storage and Network IO Control ensures each virtual machine receives what it is entitled to.

For the SMB market a brand new shared storage appliance is introduced today: vSphere Storage Appliance 1.0. It takes vanilla servers and use local drives and present it as shared storage. It will bring agility and availability through shared storage to the SMB.

Auto-Deploy, PXE booting your ESXi hypervisor in to memory! It allows to spin-up more hosts within minutes instead of hours. Adding capacity has never been this simple?

vSphere 5 offers comprehensive security and isolation capabilities through vShield 5.0. vShield App 5 allows you to select regulations to protect sensitive data. It also enables you to get additional auditing in place.

The Cloud Infrastructure represents more than a million engineering hours, more than 100 additional capabilities, more than two million QA hours, more than 2000 partner certifications to enable this.

Rick Jackson up next discussing licensing.

Industry has traditionally licensed on physical constraints. It makes it difficult to create a cloud environment. Customers need to be able to upgrade to new hardware without having physical boundaries. No more “Cores per Proc” limits, no more “Physical RAM per host license”… vSphere introducing vRAM entitlement. Virtual RAM is the amount of virtual memory configured for a powered on virtual machine. vSphere 5 used pooled vRAM across the entire environment.

Packaging has been simplified and moving from 6 down to 5 packages. vSphere Advanced has been eliminated, all customers currently using Advanced are entitled to vSphere Enterprise.

Join us at VMworld for more details around the new product releases. 10AM virtual show, be there for more technical in-depth details!

Hello SRM users,

The VMware vCenter Site Recovery Manager (SRM) product team is looking for product feedback on SRM deployments. If you have purchased SRM, we would like to hear from you. Your participation will be very valuable to us and the information you provide will be used to improve the SRM product going forward.

You can provide your feedback by completing the survey

The survey should take no longer than 15 minutes and will expire on June 10, 2010. Please note that this survey is for SRM customers only.

Upon completion of the survey, if you are among the 1st 1000 respondents, VMware will donate $10 per response to charity. You will also receive a link to download the electronic copy of Mike Laverick’s book “Administering VMware Site Recovery Manager 4.0″ upon completion of the survey.

We appreciate you taking the time to provide us with your valuable feedback.

Thank you,
The VMware SRM Team

Site Recovery Manager 4.0.1
File size: 104 MB

You can find the download here. This patch fixes the following issues:

• Test recovery times have been improved for ESX 4.0.1 hosts that use iSCSI arrays.
• a problem that could cause a recovery plan to hang while powering-off virtual machines at the protected site if the virtual machine’s storage goes offline while the plan is running
• Customization is now supported for virtual machines running Windows 7 and Windows 2008 R2.
• a problem that could prevent IP customization from updating the /etc/hosts file on a protected virtual machine running Linux
• a problem that could cause intermittent site disconnections when there was a firewall between the sites that was configured to close connections due to inactivity
• a problem that could cause test and recovery networks to be swapped in a recovery plan after the SRM service was restarted
• a problem that could cause datastore group calculation to fail with a “Not initialized” exception when encountering a virtual machine with an RDM device for which the lunUuid is not set
• a problem that could cause a recovered virtual machine to be deleted if an administrator manually removed it from a protection group while a recovery plan was being run
• a problem that could cause the SRM Installer to fail to update vCenter credentials when running in Repair mode
• a problem that caused the Perl installation created by SRM to be incompatible with some Perl packages. This fix eliminates the need to create the temporary Perl installation mentioned in VMware Knowledge Base article 1014232.
• a problem that could cause the SRM Service to hang when a Configure All operation configured more than 300 virtual machines
• a problem that could cause recovery plan failures with hardware iSCSI HBAs connected to Clarriion arrays

I had a disagreement with a friend about where to get SRA’s from. He was under the impression that we didn’t have the arrays in our premises for all of the SRA’s on the market and so it was OK to take an SRA from a vendor as they could test it.  The fact is we do have most, or all of  the arrays for each SRA in-house but that is actually not relevant.  It is important to only take SRA’s from the VMware web site for a different reason.  When a vendor finishes updating or writing an SRA, it is run against a special program that produces a log.  The SRA and log are sent to VMware and we check them out.  Sometimes they are sent back for improving or fixes.  This continues until the SRA passes and then it is posted on our web site.  If you took the SRA from the vendor you may accidentally get an SRA that in a week or a month we might decline and send back to be fixed.  So please, make sure you get the only safe copy of an SRA available, and that is from our web site!

1. VMCI Socket Performance
   The VMCI (Virtual Machine Communication Interface) device allows fast, efficient communication between virtual machines running on the same host, without using the guest networking stack. This paper presents VM-VM performance results using VMCI Sockets and compares these results to the VM-VM performance achieved using regular TCP/IP sockets.
2. VMware vCenter Site Recovery Manager 4.0 Performance and Best Practices for Performance
   The goal of this white paper is to provide you with Site Recovery Manager performance data and recommendations so that you can architect an efficient recovery plan that minimizes the downtime for your environment.
   This white paper addresses various dimensions on which the recovery time depends:
   • Recoveries with iSCSI, FC, and NFS storage
   • Number of virtual machines and protection groups associated with a recovery plan
   • Virtual machine to protection group relation
   • Recovery site performance in a cluster with DPM and DRS
   • Configuration of various recovery plan parameters
   • Priority assignment of virtual machines in the recovery plan
   • High latency network between protected and recovery sites

   Furthermore, best practices are suggested in applicable areas so that you can optimize the recovery time using Site Recovery Manager.