Home > Blogs > VMware vSphere Blog > Monthly Archives: July 2010

Monthly Archives: July 2010

ESX 4.1 is the Last ESX! What Do I Do Now?

VMware shipped ESX Server 1.0 way back in 2001. While the word “Server” was lost over time, another bigger thing was not: the Console Operating System (a.k.a. Service Console or COS), a Linux instance that facilitated local management operations. While this administrative environment had an important role early on when centralized management with vCenter Server wasn’t as common as today, it also introduced overhead and made our platform less secure and robust as it could have been without it.

To address this issue, in 2007 we introduced our next-generation COS-less hypervisor architecture, VMware ESXi, which provided the same virtualization capabilities and performance as ESX with improved reliability and security (see ESXi and ESX Info Center for more details). Since its first release, we have gradually enhanced ESXi with the objective of enabling customers to perform the same advanced management tasks they performed with ESX. The great news is that thanks to the most recent improvements included in vSphere 4.1 we solved the last few remaining gaps (see It’s here! The latest version of ESXi for more details).

With the release of VMware vSphere 4.1, we announced that 4.1 will be the last vSphere version to support both the ESX and ESXi hypervisor architectures. Going forward customers will be able to deploy vSphere only using ESXi. Although the infrastructure management tasks once performed by the Service Console are now handled by tasks running under the VMkernel, some ESX users may still depend on the custom scripts, third-party products, or operational procedures that use the Service Console. This means that upgrading to vSphere 4.1 is the perfect time to start planning on migrating to the ESXi architecture and eventually break all dependencies on the Service Console once and for all. Here is a quick summary of what you should look into:

  • Replace COS-based hardware monitoring with CIM-based tools
  • Replace COS-based backup technologies with products that use the vStorage APIs
  • Replace COS-based scripts using the VMware Management Assistant, the vCLI, or vSphere PowerCLI

For more information on these changes, VMware Customer Education is offering two recently released training courses. VMware vSphere: Transition to ESXi is a two-day instructor-led course that offers a broad survey of what is required to break these dependencies. VMware vSphere: Automation using vSphere PowerCLI is a two-day instructor-led course that teaches scripters about the extremely powerful PowerCLI scripting environment. VMotion a VM with a one-liner? You can in PowerCLI.

Enrollment in these courses is available now.

VMware vSphere: Transition to ESXi:

http://mylearn.vmware.com/mgrreg/courses.cfm?ui=www&a=one&id_subject=19816

VMware vSphere: Automation with vSphere PowerCLI:

http://mylearn1.vmware.com/mgrreg/courses.cfm?ui=www_edu&a=det&id_course=70783

VMware vCenter Site Recovery Manager 4.0.2 is now available

Hello all,

This updated release of SRM is now available and you can find the release notes here.  This is a maintenance release which means it has fixes and no new features.  I want to draw your attention to one fix in that if you are using vNetwork Distributed Switches (vDS) and are also using SRM you can now protect successfully those VM's.  You will need to have vCenter 4.0 Update 2 together with SRM v4.0.2 and you will have no problem protecting those VM's.  Due to the number of fixes, I would recommend using 4.0.2 instead of 4.0.1.  Thanks to all of the customers that helped us with this release, and the engineers that did the work!  Thanks very much!

Michael

Would you like quicker support for SRM?

Hello all,

I have heard recently that people are calling for help with SRM, and generally do not provide logs, so we need to ask for logs, and so it stretches out how quick you get help with SRM.

If you want the quickest and smooth support experience, I recommend you start by gathering your SRM logs, submit them with your support request on the web, and then phone for help.  This way, you will be talking to someone that has your logs to look at and they can start more quickly helping you!

I suggest you do this for any issue you are calling VMware with, whether it be SRM, ESXi or another product.

SRM logs can be gathered by using the option in the VMware menu on an SRM server called Gather SRM logs which is found in VMware \ VMware vCenter Site Recovery Manager.  The URL below is where you can start your support experience.  Please use this process and be sure to do it on both sides!

File a support request:

http://www.vmware.com/support/contacts/file-sr.html

Support Contacts:

http://www.vmware.com/support/contacts/

Gathering your SRM log files

http://kb.vmware.com/kb/1009253

As always, comments and suggestions welcome!

Michael

Under the Covers with VMware FT (Fault Tolerance)

By any measure, FT (Fault Tolerance) is a ground-breaking technology. Introduced a year ago with vSphere 4.0, FT enables an application to continue uninterrupted even after a complete and catastrophic physical server failure.

But how does it work? What is the impact or requirement upon the network? Dan Scales, Mike Nelson, and Ganesh Venkitachalam from the VMware engineering team that brought FT to life, recently published an in-depth, 27 page technical report on The Design and Evaluation of a Practical System for Fault-Tolerant Virtual Machines.” The paper goes deep with discussion on the FT protocol, the implementation issues for network I/O, disk I/O, benchmarks, and an assortment of other topics. It really is a fascinating read.

vSphere 4.1 is Here! Tell Me Something About the Release I May Not Know

It is a big day here at VMware with the release of vSphere 4.1. I can’t believe this day is finally here! First, let me thank everyone at VMware that has spent countless hours on this release.

What do I think is compelling and significant about vSphere 4.1?

In addition to the key or highlighted features in our release (which you can read about here), I think there are some smaller or more subtle changes to the product offering that can impact users in a big way. You may not be that aware of these so let's take a quick look at a few of them:

1. The Cloud – In just about one year’s time we have gone from discussing vSphere as the best platform for building cloud infrastructures to the now the best platform for cloud infrastructures. This small change is really a big deal because it highlights our continuing efforts to not only enable the cloud but really drive it and truly deliver benefits to users. We believe vSphere 4.1 puts those additional elements to make that step into place. Each of the highlighted features is positioning us for the cloud.

2. VAAI – The new vStorage APIs for Array Integration (VAAI) are fundamentally going to change the way vSphere common activities (Storage vMotion, provisioning a VM, Thin Provisioning) happen from a performance and efficiency perspective. Any opportunity to increase performance from 5x to 20x (depending on workload, environment, and a few other factors) is a real plus.

3. Active Directory Integration at the vSphere Host – Every customer I have talked to is a big fan here. The ability to authenticate at a more granular level means enhanced security and also a better way to leverage an existing model.

4. DRS Host Affinity Rules – Got a VM you don't want to move to a certain vSphere host due to availability, performance, licensing, or other concerns? No problem. Add a hard or preferential rule in DRS to make this happen. I would definitely make sure though you think about how these rules impact your ability to be flexible and add them where they make the most sense.

vSphere 4.1 Additional Resources

Read VMware CTO Steve Herrod’s blog on VMware vSphere 4.1

Read VMware VP of Marketing Bogomil Balkansky’s blog on today’s news

Learn more about VMware vSphere 4.1

Come see vSphere 4.1 in action at VMworld 2010 

 

Got Network I/O Control?

vSphere 4.1 launched today with a bunch of great new features and improved performance.

Network I/O Control (NetIOC) was the major feature enhancement for networking. NetIOC is a must have for anyone using or considering 10GigE.

Why NetIOC?

NetIOC enables you to guarantee service levels (bandwidth) for particular vSphere traffic types. For example, if you’re concerned about iSCSI (or NFS) bandwidth/latency when a vMotion or some other activity fires up, or maybe you wish to protect your FT traffic from congestion; or of course, you wish to ensure your VM traffic meets minimum or required levels of service.

NetIOC can isolate and prioritize six traffic types:

  • VM traffic
  • FT Logging
  • iSCSI
  • NFS
  • Management
  • vMotion

Using the limits and shares parameters, you can tailor NetIOC precisely to the requirements of your environment.

NetIOC in Action

Sree from our performance engineering group performed a myriad of benchmarks and tests to see the effects with and without NetIOC. (The paper is posted here). One test involved running FT, NFS, VM traffic, and then seeing what happens when a vMotion starts. You can see the effect in the diagram below. The aggregate bandwidth usage before vMotion is ~4-5 Gbps. The vMotion (which with vSphere 4.1 can consume up to 8 Gbps), oversubscribes the 10GigE NIC, causing all traffic types to suffer. With NetIOC enabled with appropriate shares values, the critical traffic types are protected with vMotion consuming what remains of the link bandwidth.  

image

Here is another benchmark using NetIOC. This time using the SPECweb2005 benchmark. In this instance and without NetIOC, a vMotion causes 26% of the user sessions to fall below the service level requirements. 

image

New Network Features

Of course, we released a few other network features in vSphere 4.1. An overview is presented in the “What’s new in VMware vSphere 4.1: Virtual Networking” paper on vmware.com

  • Network I/O Control (NetIOC)—see above
  • Load Based Teaming (LBT)—dynamic balancing of VM vnics across a team according to load
  • IPv6 Enhancements–toward NIST “Host” Profile compliance
  • Improved VM-VM and vmkernel Network Performance—major performance improvements across the board (vMotion now tops 8Gbps!)

You can read all about NetIOC in this 26-page paper posted on vmware.com

VDR and vSphere 4.1 compatibility

You probably saw the release of vSphere 4.1 today and might be wondering if there is a new release of VDR that accompanies it.  The short answer is no – VDR 1.2 that we released last month is also bundled with vSphere 4.1.  So, the compatibility table looks like the following for that release:

VDR                     vSphere

1.2                       4.0 U2 and 4.1

In addition to the existing VDR 1.2 features, there is one new feature that is available with vSphere 4.1:  VSS application level quiescing for Windows 2008 R2, enabled via the version of VMware Tools that ships with vSphere 4.1.  With vSphere 4.1, VSS support for Windows 2003 and 2008 are on par to each other and VDR 1.2 will take advantage of this enhancement.

Update 7/14/2010:  By the way, the change block tracking issue that I had blogged about about two months ago is no longer an issue with  vSphere
4.1.  Check with your VADP enabled backup software
vendor on the availability of their vSphere 4.1 compatible release.

It’s here! The latest version of ESXi

It’s here! The latest version of ESXi

We are proud to announce the release of ESXi 4.1!  With the new version of VMware vSphere 4.1 – whose General Availability was announced earlier today – VMware delivered several substantial improvements to the ESXi hypervisor architecture. VMware ESXi is the industry’s gold standard when it comes to hypervisor architectures thanks to a streamlined code base (less than 100MB) that dramatically improves the security, deployment and configuration, and ongoing administration of the hypervisor. While the ESXi architecture already delivers the same performance and reliability as ESX, it was missing few advanced management features particularly useful in large scale environments. Over the past year since the release of vSphere 4.0, we put a lot of effort in addressing these shortcomings and we believe that with the new capabilities of vSphere 4.1 we achieved our goal.

The table below shows you a high level summary of main features of the last two versions of both ESX and ESXi. As you can see ESXi 4.1 supports nearly all the same advanced management features as ESX 4.1

 ESX 4.1 vs ESXi 4.1 features table
 

You can find a more detailed description of the new capabilities of the ESXi hypervisor architecture in this KB article. We also have produced a new white paper on Transitioning to ESXi 4.1 .  In upcoming blog posts will provide a more information about each enhancement, so stay tuned.

What are the advantages of the ESXi hypervisor architecture?

ESXi is VMware’s latest generation hypervisor architecture. We designed ESXi to deliver the highest levels of reliability, robustness, performance and security for virtual environments in the industry. The ESXi hypervisor architecture is independent from a general purpose operating system like Windows or Linux, making its code base size less than 5% of that of ESX. Thanks to this unique design the ESXi architecture dramatically improves the security, deployment and configuration, and ongoing administration of the hypervisor while delivering the same level of performance and reliability of ESX.

To learn more about the unique advantages of VMware ESXi take a look at the Why ESXi? section of the VMware ESXi and ESX Info Center

Upgrade to vSphere 4.1 and migrate to ESXi!

As you may have read already read, 4.1 will be the last release of VMware vSphere to offer both the ESX and ESXi architectures. Starting with the next release, it will only be possible to deploy VMware vSphere using the ESXi hypervisor architecture. While VMware will continue to provide technical support for VMware ESX according to the VMware vSphere support policy, existing vSphere customers who run ESX are encouraged to look into migrating to the ESXi architecture when upgrading to vSphere 4.1.

In the Upgrade section of the VMware ESXi and ESX Info Center you can find information about the basic steps for planning your migration. In case you’d like to gain more hands on experience with ESXi you can:

  1. download a vSphere 4.1 evaluation, which lets you use the unrestricted version of ESXi for 60 days for free
  2. Install the free edition of vSphere, the VMware vSphere Hypervisor which is uniquely based on the ESXi architecture.  Note while VMware vSphere Hypervisor doesn’t have any time restriction like vSphere 60-days evaluation, it doesn’t include certain capabilities as outlined in the last section of this paper on transitioning to ESXi (Attend the following hands-on training classes that VMware makes at convenient locations around the world:


Introducing VMware vSphere Hypervisor 4.1 – the free edition of VMware vSphere 4.1

In addition to the general
availability
of VMware vSphere 4.1, today we also announced a new name for its
free edition: VMware vSphere Hypervisor. VMware vSphere Hypervisor isn’t something
new, but simply the new name of our freely downloadable product formerly known
as VMware ESXi Single Server or “free ESXi” (often abbreviated to simply
“VMware ESXi”). Just like its predecessor, VMware vSphere Hypervisor is free
and provides basic server portioning for server consolidation.

Why the name change?
As the volume of downloads indicates, since its initial availability “Free
ESXi” (I should say VMware vSphere Hypervisor) has been an extremely popular way
for companies to get started with virtualization. Unfortunately, though, its
name – especially in its more commonly used abbreviated versions, “VMware ESXi”
or “free ESXi” – has become source of confusion and misinterpretations of
actual capabilities. In an effort to improve the situation, we decided to
introduce the new name, VMware vSphere Hypervisor, which we believe better
describes the nature of the product and how it relates to the other vSphere
editions.

Where can you learn
more about VMware vSphere Hypervisor?

To learn more details about the product, you can visit the VMware
vSphere Hypervisor
webpage or join the new VMware
vSphere Hypervisor community
. From the webpage you will also be able to access
the download portal and find an answer to commonly asked questions.

What is the difference
between VMware vSphere Hypervisor and other editions of VMware vSphere?

There are three main differences:

1.       VMware
vSphere Hypervisor is the only free edition of VMware vSphere

2.       VMware
vSphere Hypervisor provides only the hypervisor capabilities of VMware vSphere,
enabling customers to run multiple virtual machines on a single vSphere host and
to experience the benefits of server consolidation at no cost

3.       VMware
vSphere Hypervisor is only based on the ESXi hypervisor architecture. On the
other hand, customers who purchase any of the VMware vSphere paid edition can
still choose to deploy vSphere with either the ESX or ESXi hypervisor
architecture.

What are VMware ESX
and ESXi and how are they different from vSphere?

VMware ESX and ESXi are two alternative architectures that customers can
choose when deploying the paid editions of VMware vSphere. VMware ESX and
VMware ESXi are both bare-metal hypervisors hypervisor architectures that
install directly on the server hardware. Both provide industry-leading performance
and scalability; the difference between the two resides in the architecture
components and the operational management. The functionality and performance of
VMware ESXi and ESX hypervisors are the same; the difference between the two
hypervisors resides in their architecture and operational management. VMware
ESXi is the latest hypervisor architecture from VMware and as of the vSphere
4.1 release, VMware’s recommended best practice when deploying VMware vSphere. To
learn more about the benefits of the ESXi architecture and the differences with
ESX, visit the VMware
ESXi and ESX Info Center

What’s new with VMware
vSphere Hypervisor 4.1?


As mentioned previously, VMware vSphere Hypervisor is based on the VMware ESXi
hypervisor architecture and as such it inherits all the new capabilities that
VMware introduced with the 4.1 release of ESX. To learn more about them check
out the blog post “It’s
here! The latest version of ESXi”

Upgrading to SRM 4.1 – including upgrading to vSphere VirtualCenter 4.1

VirtualCenter 4.1

This is more accurately referred to as migration since we are moving from a 32-bit host operating system, to a 64-bit operating system.  The steps below will help you move from a SRM 4.0 / VC 4.0 environment where Site Recovery Manager (SRM) and VC are co-located (although that doesn't impact this process much if they are not) and SQL remote.  I will try to point out useful information along the way to help in other migration scenarios.

I should point out that I am doing this with RTM bits, and not necessarily GA bits.  That should not make a difference, but it may.  And I am posting this a little early so some of my links are not available yet in this text, but will be updated after GA.  As well, this is a very long blog.  Sorry about that. Here is a PDF copy of this article ==>  
Download Upgrading to SRM 4_c
.  I will update this blog (and PDF) as I learn more.

I recommend you read carefully this document and its references completely, and understand them as well, and than plan an appropriate outage and work all the way through.  You do want to minimize the outage window of both VC and SRM!

A very useful reference is the VC release notes (click here) and the upgrade guide (click here).  Background on using the Data Migration tool is found in (1022137).

Some interesting background.

  • VirtualCenter ISO build – 4.1 build 259021
  • ESXi – 4.1 build 260247
  • ESX – 4.1 build 260247
  • SRM – 4.1 build 267817
  • You must use a 64-bit DSN for VC and remember to make it using SQL Native.  You can find SQLncli_x64.msi near the bottom of the page at click here.
  • You will need to use a 32-bit DSN for VMware Update Manager (VUM) to see the KB article (1010401) for help making a 32-bit DSN in a 64-bit OS.

Things to get ready

  • Make sure you have a good backup of everything that is going to change – which means your VC server, and database.
  • Your new host that is 64-bit will need to have the same name and IP as the old host.  This is important.  So you will need to build it when it is not on the network.  Avoid conflict with the existing VC.  You need to preserve the VC and SRM FQDN name through the migration.
  • Make sure you have access to your service account information for VC and SRM.
  • Remove your vSphere Client plug-ins.  This is not always necessary but it has helped me out in the past.
  • If you have a spreadsheet that details the VM to LUN relationship that may be useful.
  • An outage – you will have no VC and SRM for a number of hours.  With preparation, and understanding of what is needed you should be able to keep your outage to around 3 – 4 hours but this will vary widely!  SRM should be available approximately 1 hour after your VC is available again.  But that will vary depending on your prep work.
  • We need the VirtualCenter ISO – as we need the ISO as it comes with a folder we need, that the normal .zip doesn't.  The folder is called datamigration.  You can extract the ISO to a location that you will have access to when working on either the old or new VC.

Dmfolder

Datamigration folder that is only present when you use the ISO file.

Migration – VC

  • Your database for VC is remote, but you should still make sure to have a backup of it.
  • You should be logged into the current VC (or current VC / SRM host).  Than, either by using / mounting the ISO, or if you have extracted the files from it, click on autorun so that you get the main screen of the install.  Near the bottom of it, under Utility, select Agent Pre-Upgrade Check.  If it finds issues, solve them before continuing on.  The issues generally have KB articles attached to help.

Agent

Autorun screen with the Agent Pre-Upgrade Check highlighted

Agent2
Make sure to use the Windows credentials that is your VC service account, or your domain admin.

  • On the existing VC / SRM machine, copy the datamigration folder to the local hard drive and expand it.
  • Make sure that the VMware Update Manager (VUM), VMware VirtualCenter, and VMware VirtualCenter Management Web Services are not running.  If SRM is on the same host, it too should not be running.
  • Now, you need to use the backup.bat file that is in your datamigration folder.  It will do a backup of your environment in terms of the configuration that is not stored in the VC database.  Notice the log folder?  You can check out the backup.log file to see how the backup went and what it touched.  The data folder has the actual backup.  This backup contains things like port settings, SSL certificates, and licensing information.
  • The backup.bat file has only a few questions.
  • You should now copy the entire datamigration folder to a location where it can be copied to the new VC host when it is available.
  • Turn off your existing host.  Disconnect the network from it to make sure it is not accidentally turned on.
  • You need to turn on your new host, and make sure it has the same FQDN / IP information, join it to the domain, patch, etc.  Remember to install the 64-bit SQL Native client, and create a 64-bit DSN, as well as a 32-bit DSN.  The URLs earlier in the document can help.
  • You need to copy the entire datamigration folder to the new host.
  • On the new host, you need to have access to the install media so map a drive.
  • Use the install.bat file from the datamigration folder to start the install process.
  • You will be asked for the path to VC, and than later VUM.  If you are using the ISO, or extracted the files from it, the path will be the same for both.

Install bat

The start of the install.bat process.  The install.bat is in the datamigration folder.

  • You will see the normal install prompts for VC.
  • Use the same DSN information.
  • Notice how you have a choice at some point to do an automatic or manual update of the VC agents on the hosts?  I used automatic, but it is nice to have an option!

Vcenter agent upgrade

A nice improvement!

  • Select the same path as you had used previously on the old VC.
  • Use the same ports.
  • The next prompt is about the size of the JVM memory.  Use the default or make a more appropriate choice.
  • After the VC install is finished the install will return you to the install.bat file and start the VUM install process.
  • While VUM is being installed, make sure to use the appropriate VC service credentials, and the 32-bit DSN.

Install vum

Use the same path for the VUM install process if using the ISO or extracted files, otherwise, use the correct path!

  • There is a restore.log file available in the logs folder of the datamigration folder.  It can show you what was done.
  • It is important to understand that the install.bat file is smart.  If, like me, you didn't have a 32-bit DSN for VUM, you could exit, and create it.  When you start the install.bat process again, it will take off where it finished and not waste your time!
  • You should now confirm that VC and VUM are running.  In my upgrades there were NOT.  They were using the Local Security instead of my VC service account.  I changed the credentials and everything was fine.
  • Install the vSphere Client from the autorun screen.
  • Connect to the VC.
  • Install the VUM plug-in.  You can do this on your own desktop, or on the server.
  • Now check your VUM configuration, scheduled tasks and browse around to make sure your configuration is there!

Vcversion

You have now upgraded one of your VC servers.  You need to do the other one now!

Note1:  In all of the work I did, we always had the VC / VUM services not start, and we had to assign the proper credentials instead of Local Service.  No big deal, but don't forget.

Note2:  Be careful with the 64-bit and 32-bit DSN as it can get confusing.  If you make a mistake you can cancel the VC or VUM install process, fix the DSN, and restart the install.bat file.  It will not redo an unnecessary install but rather start where you last finished successfully.  A very nicely done install.bat file.

Upgrade to SRM 4.1

This too is more of a migration, but this time we don't have the lovely datamigration script to help us!  But the steps below will help.  The process below is for migrating to 4.1 when you are using a 32-bit host OS.  If you are in fact using already a 64-bit OS, you can do an in-place upgrade, but while we do not step through that process below, the information below can help. 

A very useful reference is the release notes (click here).

Some Interesting background

  • SRM 4.1 build 267817

Things to get ready

  • You will need to have your VC infrastructure already upgraded!
  • Make sure your SRM was able to do a test failover or two before you started the upgrade process!
  • You will need to confirm that your SRA has been upgraded or certified for 4.1.  Most have been, but confirm it.  Check the VMware download site for SRM and the current version of the SRAs, and the SRA download for a readme that talks about what it is certified for.
  • SRM 4.1 bits
  • SRA bits
  • Be aware that SRM requires a 32-bit DSN, which is NOT the default on a 64-bit OS.  If you need help with this check out the URL links in the VC section above.
  • Remove your SRM plug-in.
  • You need an SRM backup, but it needs to be taken at the same time – as if it was in a consistency group.  BTW, it needs to be restore like that too.  Never restore just one or the either side as it will not work.  You should also have history reports as hardcopy as well.
  • You should copy your vmware-dr.xml file from both the protected and recovery side to a central location.  This file is by default, in c:\program files\VMware\VMware Site Recovery Manager\config .

Migration – SRM

  • Remember your new SRM host must have the same name / FQDN / IP so you will need to turn off your old SRM host after you have your backups and .xml file so you can deploy the new host.
  • Backup the SRM database on each site.
  • Turn off the old SRM host.
  • Turn on the new SRM host.
  • Make sure you have a 32-bit DSN.
  • Install SRM 4.1.
  • If you are re-using the SRM 4.0 database, make sure you have a backup as errors during the install, or a cancellation of the install, could introduce corruption into the database.
  • Since you are using the old database, you will be prompted about there being an SRM extension installed already.  This is not an issue, and correct, so select Yes.

Srm install extension

Select Yes at this prompt.

  • You will need to remember the 32-bit DSN during the install.
  • SRM will likely not start, same as VC, and so you should just change the credentials to the SRM service account and hit the retry button.
  • You now have SRM running, but not quite finished.
  • Start the client, and install the SRM plug-in.  Again, you can do this on the server or your admin workstation.
  • Install the SRA.
  • Now get the other side done.
  • Important – if you have made any advanced setting changes, you will need to work through the section below.  If you have not made any changes you can continue.  Some sample changes are SanProviderCommandTimeout or San.Provider.hostRescanRepeatCnt .
  • Now you will need re-create the site pairing, and reconfigure the array manager credentials.  The passwords didn't come through.  After entering the correct credentials, you will need to select the array!

Selectarray

When you re-enter your credentials to the Array Manager, make sure to select your array!

  • Now do a test failover and make sure it works!

You are now complete.  If you have any issues, please do not hesitate to contact our support organization but also leave me a comment!

Migrating Changes to Advanced Settings

If you have not made any changes to Advanced Settings, you do not need to do this section – which should be true for very much most of our customers.  Changes would be things like SanProvider.CommandTimeout or San.Provider.hostRescanRepeatCnt.  See below for a screen-shot of the Advanced Settings categories.  If you know the changes you made you can just add them to your new install.  But if you are not sure, you will need to work through the process below.

Guestcustom
See this by <right+click> on the Site Recovery lighting bolt.

Accessadvanced
This is how you access Advanced Settings

Start by loading your vmware-dr.xml file.  Load the one from the Recovery Site when editing the Advanced Settings for the Recovery Site and do the same for the Protected Site.

  • When you are in the Advanced Settings windows, you will need to work through  each category.
  • One example is localSiteStatus.  Search your vmware-dr.xml file for that phrase.
  • In the section of vmware-dr.xml file you find the category  in our example of localSiteStatus, look for variables that match in the Advanced Settings category, and change the value to match what is in your VMware-dr.xml file.  See below for an example.

Vmwaredr

This is a sample of the vmware-dr.xml file.

  • After we see what is in the vmware-dr.xml file, we record it in the Advanced Settings.  See below for that.

Localsitestatus

LocalSiteStatus of the Advanced Settings.

Remember you will need to work through this process for each category.

Some issues I found

I have mentioned these issues elsewhere but thought I would mention them here again.

  • Forgot to update the credentials for the arrays – so test failover failed.
  • Used a 64-bit DSN for SRM.  It didn't work until I created and used a 32-bit DSN.
  • Didn't know to install the 64-bit SQL Native client on Win2K8R2 SRM server.  So I did and the problem left.
  • Did not see the SRM plug-in, but saw one called vcDR and it worked.  Restarted the vSphere Client also cleared this up.  Should have removed the SRM plug-in before starting.
  • None of the VC services started when I thought they should.  But of course, the VC service account settings were not migrated.  So after VC is finished installing, change the account credentials and you will be fine.  For SRM as well.
  • Didn't know that VUM needed a 32-bit DSN. 
  • It is likely not connected to the migration, however, I was able to do only three successful test failovers after the migration was complete.  After those three, I experienced only failures.  The error was Error:Error occurred: failed to prepare ShadowVM for recovery.  One VM was successfully recovered but not the others.  I removed the protection group, made sure the ShadowVM lcoation had no folders for the VM's that were in that removed PG, and in fact there was several folders that should not have been there.  So I removed them.  Than created the PG again and everything has worked fine since then.

Thats it!  As if it wasn't enough!  Let me know in the comments how it goes for you!  I will update things as I learn more.

Undo?

If you wish to undo this migration, it is almost easy.  You would turn off the new hosts, and you would turn on the old ones.  They would not be happy since the databases that would still be in use would be the new ones.  You would need to stop the VC and SRM services and restore the back up copy of the databases I mentioned you needed to have.  Than start the services and you should be good to go!

7/17/10 – Update – I made it more clear that you need to preserve the VC and SRM server names.  As well I added the undo option!

8/5/10 – Update – I added the URL for the DataMigration tool KB article, and corrected some spelling!

Michael