One of my readers recently contacted me about how SRM communicates to vCenter both during an install, and then afterwards once the service is up and running. The odd thing is this… During the install the communication to vCenter appears to be non-secured on TCP port 80, but after the install is on the secured port of TCP 443… In the book I conjecture that some redirection takes place, its actually a little bit more sophisticated than that…

Here’s what the offical guide says: 

Port 80 is provided as the default to use for the initial connection to the remote site. After the initial HTTP connection is made, the two sites establish an SSL connection over port 80 to use for subsequent connections.

Duncan Epping on his Yellow Bricks site has this more revealing statement:

http://www.yellow-bricks.com/2009/08/11/srm-faq/

Why is Port 80 used in the install but port 443 later? During install of SRM port 80 is specified and you cannot type in 443, but after the install is complete than SRM talks to VC on 443, so why is 80 specified in the install? Even though SRM uses SSL when it communicates to VC, it does not use port 443. SRM establishes a TCP connection to port 80, than uses an HTTP CONNECT request to establish a tunnel to the VC servers, then does an SSL handshake with the VC over that tunneled connection. The SRM installation enforces these semantics.

Thanks to Bas Vinken for bring these two bits of information to my attention. Quite why the communcation is this done this way isn’t really explained. But I guess it is a reminder that port numbers are some what arbitary, and they follow a convention of being associated with certain services – I guess you would calll them the “well-known ports”. But at the end of the day, there’s nothing hard coded about these ports and how they are used..

Introduction:

As you might know SRM 5.0 introduces support for “vSphere Replication” (VR) – where virtual appliances are deployed to assist in the replication of VMs from the Protected Site to the Recovery Site. What you might not know – is whilst this works perfectly for recoveries where the VM moves from one site (say SiteA: New York) to another (say SiteB: New Jersey) – there is no automated method of failback. That is to say, moving the VM back from the Recovery Site (SiteB: New Jersey) to Protected Site (SiteA: New York).

SRM 5.0 does introduce a new “automated failback” feature – its a combination of running a “reprotect” process to invert the “normal” path of replication – and then running a Recovery Plan to move the VMs back. Sadly, that “reprotect” and failback process didn’t make it into the first release of VR. That means a more “manual” process has be undertaken to a.) prepare for the failback and b.) return SRM and VR back to a state that it was in before the failover took place. For an experienced SRM Administrator (sic) this isn’t too much of chore or difficult – but if you are new to SRM, and intend to use VR – then it could be a bit of challenge. That’s what this article is all about.

I’ve been prompted to write this because I know that my upcoming SRM book will have a very long chapter on failover/failback but it is very much from slanted from the position of array-based replication – and there’s very little if any detail on how this process pans out when your using SRM with VR. This article is intended to plug that gap for my readers who buy the book. It’s shame that this didn’t make it into the book, but that is publishing deadlines for you. As it is, this likely to change over the lifetime of SRM 5.0 – and this article will be  darn easier to maintain and update…

For sometime I’ve been using the scenario of fictitious company called “Corp.com” which has two sites New York and New Jersey in my books. New York is meant to be the production or Protected Site during normal business operations, and New Jersey is an ancillary location to Corp.com – and is used for many purposes – in this case as the Recovery Site in SRM.

Overview:

Before I begin with the process of failback  – Let see how a VR setup looks like. If you have already done this – and got VR working – you might want to skip this overview section. I’m doing it just so the rest makes sense.

VR has a “Management Server/Service” (VRMS) of which you need 1 per vCenter instance. Remember, SRM itself has a requirement of one vCenter per site, although it is possible using the “Shared Site” configuration to have one Recovery Site, service the DR needs of many Protected Sites – a configuration that would popular if a service provider was selling SRM as a service perhaps. The other requirement is at least 1 vSphere Replication Server (VRS) at the Recovery Site. This appliance receives the “deltas” that make up every day replication. So after the first “Full Synch” of replication only the changes are replicated. Of course it is possible to use “Sneaker Net” to download the .VMDK of VM from the Protected Site, pop them on removable storage – and then use a secured courier service (UPS, Fedex – imagine blacked out limos and motorcyclist armed with Uzi’s) to ship the data to the Recovery Site. In this case only the deltas accrued during the time it takes to move the .VMDK files about need to be copied.

Unlike the VRMS, it is possible to have multiple VRS per vCenter for scale-out purposes. Something you would need to do if you found yourself rubbing up against the scalability limits. Interestingly, the scalability limits are outlined in the release notes – currently contradict what’s in the official admin guide – a situation that will be fixed very shortly… It’s the release notes which are correct incidentally…

http://www.vmware.com/support/srm/srm_releasenotes_5_0_0.html

Of course a failback process means invariably inverting the replication that would usually send updates from Protected Site (SiteA: New York) to the Recovery Site (SiteB: New Jersey), so they went in the opposite direction from SiteB: New Jersey to SiteA: New York. So for this reason I’ve recommended in the book that folks always setup VR at EVERY site they intend to use with SRM, so they will have the appliance in place for failback – but also useful if your Recovery Site is not dedicate location for DR but also production location. This is often referred to as a “bi-directional” configuration – where SiteA: New York is the DR location for SiteB: New Jersey, and SiteB: New Jersey is the DR location for SiteA: New York.

Such a configuration can be seen below. In the background I have two VRMS and two VRS – one for SiteA: New York and one for SiteB: New Jersey.

Only one VM has been protected called “mail04″. Although this VM currently “lives” in the Protected Site of “New York”, its the VR in New Jersey that receives the changes as the VM is powered on. For this reason the management of the replication (Move to, Resume, Pause, Remove, Synchronize) is carried out at the destination for the replication. This is pretty common practice in array-based replication – the replication “job” is managed at the location where the recovery would occur in the event of disaster. After all there’s little point in your management being located where a smoking crater might now exist.

I hope that is obvious, and I hope you’ll forgive me if I sound patronizing. With that said there are some people think the best place for management is a smoking crater. However, I digress…

This vSphere Replication is “turned on” on the right-click of a VM – although its perfectly possible to select collection of VMs in a folder and do groups of VMs using the standard [shift+click] and [ctrl+click] selection methods:

Once VR is setup and enabled for SRM. You can begin to treat a VR protected machine the same as if it were protected by any storage vendor replication. So creating protection groups – just done by merely selecting the VR radio button, and VMs they reside on.

The protection group(s) once created can be selected when creating the SRM Recovery Plan, exactly as you would do if you had used array-based replication.

When you run test or genuine recovery process (either planned or unplanned) Recovery Plans work in the same way as they would for array-based replication. Where changes or difference occur is in the management of the failback process. As with my SRM book I’m going to look at this from two perspectives – a Planned Migration (when you know that disaster is potentially on its way) and unplanned migration (when the disaster happens without much if any prior notification).

Planned Migration

A Planned Migration would be used when SiteA: New York and SiteB: New Jersey were both available – and you had received enough notification enough notification to avoid disaster. That could be triggered by some known power outage caused by the supplier in your location needing to do some a major upgrade work or someone plans to demolish a building near you – and there demolition experts can’t 100% guarantee that the soon to be deceased building, will not fall in your general direction.

In this case you would select your Recovery Plan(s), and select the “Planned Recovery” radio button, and enable the option that states “I understand if carry out this major task without senior management approval and it all goes pear-shaped I might be on welfare for the rest of my days, and have to eek out an existing with shopping trolleys and trashcan as my only friends…”

Doing this will do two major things – firstly it was cause a synch to occur between the VM at Protected Site to the VR, and then a power off the VMs affected by the Recovery Plan at the Protected Site, followed by Power On event at the Recovery Site. Of course the time complete this “delta synch” will dependent on a number of factors – volume of changes since last replication, the amount of bandwidth available at each site, latency, lost packets, and not least the volume of VMs to be migrated over to the Recovery Site.

So what affect does this have on the existing replication relationship at the Protected Site? Answer – It gets switched off, and put into “Not Active” state.

On the Protection Group at the Protected Site – the one that contained the “old” VM, you should see that vSphere Replication has been turned off the affected VMs. The “Replication Warning” is a standard alarm indicating that replication is not occurring from SiteA: New York to SiteB: New Jersey for this VM.

Note: It would be nice if message here was more noticeable – and that if the warning was meaningful. Like “Replication Broken off by Planned Migration” or something helpful like that…

One thing that appears to me to be confusing and possibly a bug – is that fact the VR backed plans still report the “Reprotect” message after you have used “Planned Migration” or the “Disaster Recovery” methods – when they shouldn’t.

This strikes me as “wrong” because reprotect/automated failback is currently meant to be an array-based only feature.  Indeed, if you do run try to run the reprotect option you get this warning dialog box.

As the dialog box clearly states – you have to edit the plan – remove the old protection groups – which then triggers a new warning on the plan… That there’s no protection groups for it… (Incidentally, once you have removed the protection groups – then the reprotect message goes away. So quite how anyone is supposed to carry out this task “…before running reprotect.” is anyone’s guess…!!!)

At this point you might as well delete the old Protection Group in the SiteA: New York. They are of no use to you. There’s is a small value in keeping the Recovery Plan that now has no Protection Group backing it. Keeping the original Recovery Plan object keeps the “history” of all the tests and clean-ups you have done. Apart from that its pretty useless. In fact some folks think deleting the old Protection Groups and Recovery Plans is actually “cleaner” and “simpler”. I think there be some merit in that – but if you remember my strategy was try to keep as much user-defined stuff as possible. Technically, the Recovery Plan doesn’t need to be deleted.

At some stage you will be recreating the Protection Group as part of the reset after the failback – but when you add a new Protection Group to the existing recovery plan, you will find your VMs will be dumped into the default priority group – and ALL your fancy customization you had in the Recovery Plan will be lost (command steps attached to a VM, Message Steps attached to a VM, Re-IP data, VM Dependencies). In fact the process is very similar to what it used to be like in SRM 1.0/4.0 – and in pact of deleting protection groups without thinking about the consequences is one I still warn folks about in SRM 5.0.

Generally, deleting Protection Groups without engaging the brain is not to be recommended…. But I guess the adage could be applied to many decisions in one’s life.

Failback with Planned Migration

NOTE: Being the kind of guy I am tried my best not to delete or remove anything to see what I could get away with. For example I tried keeping the Protected Site configuration in place (Replication Job, Protection Group and so on). For the most part I would say not to bother. The process cannot be completed without deleting some components from SRM. That inevitably means at some stage the administrator has to put them all back in again. Without any method to export/import parts of the configuration to be restored latter – and no PowerCLI cmdlets for SRM to date – that means its at the moment almost impossible to automate the cleanup and reset parts.

So what steps need to take place in order for us to make the return journey? Taking the MAIL04 VM back to SiteA: New York in my case. The main goal here is delete or remove as little as possible from the configuration at the Protected Site as possible, whilst avoiding conflicts.

The first thing to remove from the Protected Site is the “old” VM. Carrying out a Planned Migration does not remove from the inventory the original VM at the production location. As you might know we need a Protection Group containing the new VM in SiteB in order to run a recovery plan to take back to the original location necessitates creating a “Placeholder VM” in the inventory – in the very same location as the original VM. As you might know vCenter reacts badly to the creation of the same object, with the same name, in the same location. This “orphaned” object if you want to call it that, simply needs to be removed from the inventory, not deleted. That’s because the files that make up this VM might be useful in speeding up the replication process – after all only the “deltas” make up changes that have accrued in the Recovery Site, need to be sent back to the Protected Site.

Next, I need to enable VR on the VM that that has been “moved” by SRM during the “Planned Migration” when the wizard appears I can select the normal settings for RPO, Quiescing method and critically select the destination volume – If I’m clever I can use the SAME location as the original VM, and when I do this VR will think I am using the “Sneaker-Net” method of getting my .VMDK file around.

Note: Originally the MAIL04 VM was located on ESX1_LOCAL, and it was being replicated to the ESX3_LOCAL volume, now the process has been inverted and replication is going to take place from ESX3_LOCAL back to ESX1_LOCAL. I used local storage just because I can, and I wanted to prove how VR offers enterprise like storage features even to local storage. Of course local storage is waste of time if you are using VMware Clustering like I do.

Note: Because MAIL04 was previously stored on ESX1_LOCAL, VR can use the files already there to accelerate the replication process. That’s pretty neat and similar to some array vendors capacity to retain snapshot deltas for the same purpose…

This essentially triggers replication for the first time of that VM from Recovery Site (SiteB: New Jersey) to Protected Site (SiteA: New York). One thing you will find is that old replication job from that was used in the “Planned Migration” is deleted, and replaced by the new replication job put together to prepare for the failback process. So there is little point in “cleaning out” the old replication job, because VR handles that process seamlessly under the conditions of a planned failover.

So the new replication job is listed under the destination for the updates – in my case the New York Site:

And this new replication job, clears out the old replication job that used to be held at New Jersey.

Effectively we have now inverted the path of replication so New Jersey which now own the MAIL04 is replicating its changes to New York. If you like a “personality change” has taken place. The Recovery Site is now the Protected Site, and the Protected Site is now the Recovery Site. The arrow doesn’t point > this way anymore it points this way < instead.

The next step would be to create a Protection Group at the New Jersey site to enroll it into the management of SRM. Simply replicating a VM doesn’t necessarily make it a part of the SRM process. All replication does is copy stuff about. It’s the process of creating a Protection Group and mapping that protection group to a Recovery Plan – that makes SRM does it work. So in the following two screen grabs – you can see me selecting VR as the replication type, and the MAIL04 VM that is being protected by the VR Server.

After creating the Protection Group – this should create the “Placeholder VM” with new all singing and dancing “lightening flash” icon. Remember this will only really be successful if the correct “Inventory Mappings” have been put in place – so SRM knows in which cluster/resource pool/folder and network to locate the placeholder VM…

Once a Protection Group has been created – we can now create a Recovery Plan to failback the VMs to SiteA: New York which I will use to “move” the VM back to its original home.

Note: Notice how although I “store” the recovery plan in the NJ Recovery Plans folder – the dialog box allows me to indicate that the VMs will be recovered to the New York Site.

Note: Here I’m selecting the Protection Group created in the New Jersey site that I created earlier.

For simplicity I called my plans “VR Failover” and “VR Failback” so I can easily ID them. But of course, SRM supports many plans with many different options and features.

As with all failback process I always test them just as I would test any recovery plan – and I was pleased to see that it worked fine, and I’d suffered no data loss in the process… Just the loss of all the useful information in my recovery plan, which I will have to put back manually.

CleanUp After Failback with Planned Migration

PHEW! OK, so we are kind of there. Our VMs that were once in SiteB: New Jersey are now back home (all cosy and warm, and tucked up in bed) at SiteA: New York. Sadly, through we cannot sleep easy. Although the VMs are back home, they not being protected anymore. In fact the environment is much like the same state after a failover.

There is no replication from SiteA: New York > SiteB: New Jersey. There isn’t a valid Protection Group or Recovery Plan to be triggered in the event of a Planned Migration or unplanned Disaster Recovery. Getting into a state that would allow me to start all over again, and “move” the VMs from SiteA: New York and SiteB: New Jersey is essentially a re-run of what I did earlier.

1. At SiteB/New Jersey – remove from the Inventory the Orphaned, unwanted, abandoned VMs

2. At SiteB/New Jersey –  remove the Protection Group  that backs the Recovery Plan “stuck” with the “Reprotect” message

3. At SiteB/New Jersey – Delete the Protection Group that backed the Recovery Plan at is marked “Recovered” but has a “Replication Error” on all the VMs within it.

4. At SiteA/New York – enabled VR on the VMs in that need protection

Note: I’ve  seen this state that its doing a “Full Sync”, which you might find a bit confusing. This nothing to worry about – it isn’t copying the whole VM again – that would be an “Initial Sync”. The “Full Sync” is actually running a type of checksum looking for the blocks that similar/different to the sneaker-netted source.

5. SiteA/New York -  create a Protection Group for VR

6. SiteA/New York – add the Protection Group to the Recovery Plan at SiteA/New York

7. Reconfigure your Recovery Plan, and put back all the lost metadata that was once there…

Disaster Recovery

My DR tests always begin with a power cord that I unceremoniously yank to simulate a total outage. The other thing I have is all comms from the Protected Site (SiteA: New York) to the Recovery Site (SiteB: New Jersey) going through a “software router” – a VM that acts as a router. If that gets powered off all communications between the two sites are lost – including replication.

If you happen to have vCenter open when the diaster stikes (and your not at the Protected Site) – then probably the first thing you would see is the vCenter at the Protected Site would go down and become unavailable.

By default if you switch to SRM, at the Recovery Site, it will try and log you into the Protected Site. This will obviously fail, because it is now down. So if you click cancel you will see that status of Recovery Site (SiteA: New York) would “Unknown” because you are unable to log into – and the status of the Recovery Site (SiteB: New York) would be set as “Not Connected”. This means the Recovery Site, cannot connect to the Protected Site – it doesn’t mean you couldn’t connect to the SRM server at the Recovery Site – otherwise you wouldn’t have got this far.

There’s nothing special/unusual about this scenario – it would be exactly the same if you were using array-based replication.  As with all DR scenarios – the Recovery Plan used to bring up the lost VMs, would be run just like another. Incidentally, you can still test the Recovery Plan first (if you feel you have the luxury of time) – but your more likely to head for the big red “Recovery” button in SRM 5.0. When you run the recovery – you will notice that option to carry out a “Planned Migration” is dimmed, because the Protected Site is unavailable.

When you run the plan – the SRM server will try to do the same steps it tried in the Planned Migration such as synchining with the array in Protected Site (that’s under a truck load of rubble incidentally), and shutdown the VMs in the Protected Site that were powered off, when a 6ft chunk of masonry smashed its way though the blade enclosure. I’ve often wondered why VMware runs this part of the plan, given that in disaster perhaps the first thing you loose is communication to the site that’s affected by the disaster. It seems a little counter-intuitive. But there are scenarios where you might want to try anyway. So with all this said – expect to see errors as SRM tries (and fails) to carry out an almost impossible task.

Failback with Disaster Recovery

So the Recovery Plan was successful, and your VMs are up and running in the Recovery Site. After a lot of work – your Protected Site is now available. I say a “lot of work” because who the heck  knows what state your production locale was left in after the disaster? If it was a terrorist attack, it might be crime scene – and criminal foresenics won’t let you near it. If it was a hurricane – perhaps you were one of the lucky ones that didn’t get flattened – but the local power distribution has been so flaky you not had reliable power there for days, weeks, months… So SRM automates a lot of things, but it doesn’t have a big button that says: “Raise Purchase Order, Contact Reseller, Ship replacement Servers/Storage/Network to SiteA, Contract Consultancy services to assist in rack-up and configuration, Validate Implementation of new hardware, Re-instate Communications to allow replication”.

If you disaster was serious and your backup lousy. You might even be talking about a total reinstall of vCenter/SRM and going through the pairing process all over again – together with the post-configuration typical in a SRM installation (such as adding resource mappings, folder mappings, network mappings, placeholder datastores, and so on).

Of course, when diaster strikes – there is no orchestration. The Protected Site just falls of the map. If the original configuration is retrievable and does come back online. The “old” replication job will still be there, and it will be trying to replicate to destination which is now the source, and most likely a powered on virtual machine. So you might see this in the VRs management pages. The “RPO Voliation” is caused by the replication being untimely stopped by the disaster.

The failback process in this situation doesn’t differ that much from if there had been a Planned Migration. It involves some clean-up and setup to “move” the VM back to its original home – the Protected Site…

1. At SiteA/New York – remove from the Inventory the Orphaned, unwanted, abandoned VMs

2. At SiteA/New York –  remove the Protection Group from that backs the Recovery Plan stuck in the “Reprotect” message

3. At SiteA/New York – Delete the Protection Group that backed the Recovery Plan at is marked “Recovered” but has a “Replication Error” on all the VMs within it.

4. At SiteB/New Jersey – enabled VR on the VMs in that need protection

5. SiteA/New Jersey -  create a Protection Group for VR

6. SiteA/New Jersey – add the Protection Group to the Recovery Plan at SiteA/New York

7. Reconfigure your Recovery Plan, and put back all the lost metadata that was once there…

CleanUp After Failback with Diaster Recovery

Again once both the Protected and Recovery Site are available you follow the same steps I outlined in the Planned Recovery.

1. At SiteB/New Jersey – remove from the Inventory the Orphaned, unwanted, abandoned VMs

2. At SiteB/New Jersey –  remove the Protection Group from that backs the Recovery Plan stuck in the “Reprotect” message

3. At SiteB/New Jersey – Delete the Protection Group that backed the Recovery Plan at is marked “Recovered” but has a “Replication Error” on all the VMs within it.

4. At SiteA/New York – enabled VR on the VMs in that need protection

5. SiteA/New York -  create a Protection Group for VR

6. SiteA/New York – add the Protection Group to the Recovery Plan at SiteA/New York

7. Reconfigure your Recovery Plan, and put back all the lost metadata that was once there…

Conclusions:

There’s a couple of points to made here I think. Firstly, it perfectly feasible to go through the manual steps required for failover/failback. But it would be clearly benefit from more automation – just like SRM 1.0/4.0 would have benefited from the kind of reprotect/automated failback we currently enjoy with SRM 5.0. As they say, these things will come – all in good time.

The process as it is seems very reliable – and in the course of writing this blogpost I’ve done a number  failover/failbacks each time I was successful.

Note: Incidentally, I was actually awake at 3.35am testing this. I couldn’t sleep and for some insane reason I thought writing a blogpost might help me nod off. I was wrong. I keep on being wrong on this. And I’m not sure when I will learn not to do this.

Clearly, there is room for improvement when it comes to some of the messages – and I would hope to see the confusing “reprotect” dialog boxes modified in future updates.

I think it would be lovely if the replication job from SiteA to SiteB could be just “inverted” – and reused. That’s the case with many array-vendors replication. Currently, I don’t see how the structure of VR wouldn’t allow for this setup – and I think would require a redesign. It would be great if the old Protection Groups and Recovery Plans could be kept, and therefore hard work I put into developing a sophisticated Recovery Plan wouldn’t be lost. Ideally, I would love to see VR gain the same flexibility that array-based replication benefits from. If you haven’t played with reprotect you really should. It’s a joy to use – and makes “moving” VMs almost feel as casual an event, as say VMotion is now. It’s not really for me to speculate about when VR might get the “reprotect” feature  (after all I don’t work for VMware).  For the moment the failback process for SRM 5.0/vSphere Replication is more akin to the way the SRM worked in version 1.0/4.0.

I guess the importance of this depends how rigorous you think your Recovery Plan testing needs to be. After plenty of customers “saw value” in SRM 1.0/4.0 which lacked an automated failback process for array-based replication. My analogy for this centers around the tests people do of the fire alarms and building evacuation procedures.

You could see the “test” button in SRM like testing the fire alarm in the building at 10am each day. Four quick rings, checks the alarm still works. On the other hand “recovery” button in SRM is like when twice a year – that alarm bell doesn’t stop ring after 4 attempts. Folks start looking at each other, and very slowly people start making their way for the exits. The downside of the current capabilities of SRM and VR together is that bi-annual “test” would involve a lot of work to get everyone back in the building and working again. Some of it would require maintenance windows to complete, whereas a softer “test” would not. What we are all looking for is the most rigorous of tests, with the least impact on our infrastructure – I believe array-based replication and SRM achieves that lofty goal, but VR has some work to get to same level…. By definition the more realistic and rigorous the test – like our fire alarm example – the bigger the operational impact is on day-to-day activities.

But if it only happens twice year is it such a big deal?

Remember, Rome wasn’t built in a day…

I’m pleased to announce the general availability of my new book. It’s free to download as a PDF file – and if you prefer a hard-copy you can print a physical copy of the book from LULU.COM.

Both the PDF and the hard-copy are available from the LULU.COM website.

Some stats:”

• The book is just short of 100,000 words
• 400 pages
• 6 months to complete from start to finish
• Additional 100 pages of text and supporting graphics from the SRM 1.0 book
• Additional 3 chapters

What’s New?

• All graphics updated to vSphere4
• All new theme of the New York and New Jersey – Protected and Recovery Site
• How setup replication for EMC Celerra, Clariion CX3, NetApp Filers and HP Lefthand VSA
• Integrated with these three storage vendors  – so I cover what happens in EMC, NetApp, and HP when recovery plans are tested or run
• Coverage of the new “Shared Site” configuration
• Integrating PowerCLI scripts to the Recovery Plan
• How to automate VMware SRM using the SRM SDK API
• Updated PowerCLI chapter specific to the new vSphere4 Distributed vSwitches

This time around I won’t be taking a royalty for the new book.  I would however, strongly urge you to donate money to my chosen charity. That charity is Unicef and this is what they do:

“UNICEF works with families, communities and governments in more than 190 countries worldwide to protect and promote the rights of all children. We are guided throughout our work by the UN Convention on the Rights of the Child, which guarantees every child the same rights: to an education, to a childhood, to be as healthy as possible, to be treated fairly and to be heard. UNICEF works in all these areas, and does so in a joined up way to achieve the best possible outcomes for children.”

So before you begin to read book, please pause to think of the millions of children you help by making a relatively small donation.

The recommended donation is $10 (US Dollars) or the equivalent in your currency.

http://www.supportunicef.org/forms/whichcountry2.html

Click the graphic to download/order the book, but before you do – please consider a donation of some kind.

I would like to take this opportunity to welcome Hyper9 as new advertiser to RTFM. To celebrate this here’s another here’s Chapter 4 from my SRM book…

Remember you can still buy the book in EMEA at much reduced cost via the VMworld EMEA store (whilst stocks last) – alternatively, if you prefer to buy the SRM book in the US it is still available on LULU.com. 

Work is coming along well with vSphere4 book. My hope is that by the end of the month – I should have working copy I can distribute to my VMTN reviewers and internally to VMware. The plan is to still have an “authors” edition out on LULU on the day of the GA – with a hope of having the final “cut” so to speak ready for VMworld in San Francisco. I’m in discussion with McGraw-Hill about potentially publishing the book via them – so that could change…

Download Chapter 4

To celebrate the arrival of yet another advertiser on RTFM – it’s my pleasure to release chapter 2 & 3 of my popular VMware Site Recovery Manager book. The chapter on Lefthand Networks VSA is somewhat dated – one of my projects is to update my chapter on iSCSI in my vSphere4 book to match the functionality of the new VSA… and also at the same time update the chapter on LHN so it matches with SAN IQ8.

Remember you can still buy the book in EMEA at much reduced cost via the VMworld EMEA store (whilst stocks last) – alternatively, if you prefer to buy the SRM book in the US it is still available on LULU.com. 

Work is coming along well with vSphere4 book. My hope is that by the end of the month – I should have working copy I can distribute to my VMTN reviewers and internally to VMware. The plan is to still have an “authors” edition out on LULU on the day of the GA – with a hope of having the final “cut” so to speak ready for VMworld in San Francisco.

Download Chapter 2

Download Chapter 3

To celebrate the arrival of my first advertiser to RTFM. I would like to begin the process of slowly releasing my SRM book free to download. The SRM book will remain commerically available for sometime – and when SRM 2.0 the “old” SRM1.0 book will become completely free. As I release each chapter I will be reviewing the content for any old typos, and rolling those changes through to the commerical book. Remember PDFs are great but when a book runs to 300+ pages it is actually cheaper to buy a copy than it is to take it to a printers (believe you me I learned this during the proofing phase how expensive) plus you get it delivered to your door with a perfect binding! My next free chapter will update the content I created about Lefthand Networks VSA, which is now on SAN/IQ Version 8. There aren’t a huge amount of differences so hopefully it won’t take long…

This book is still based on the original GA version – not the recent U2 edition. U2 did introduce new features and some options ceased being experimental. But not enough changes we introduced to force me to stop work on vSphere4. But I will as each chapter comes out – review the content and update it accordingly.

Enjoy your first free chapter!  

Chapter 1: Introduction to Site Recovery Manager