Archive for February, 2010

This morning a work colleague attended an EMC NetWorker Webinar and asked EMC’s Anu Yamunan the big question we’ve been wanting to know for quite some time.

Q: IDATA: “When will vSphere vStorage API be fully supported by NetWorker ? As the VCB framework is end of life from 25/07/2010

A: EMC: “We are currently working on leveraging the vStorage API to deliver proxy based protection for VMware environments. NetWorker support for vStorage API is coming soon in the second half of 2010.

I’m really pleased to hear this important feature is in the works, but one particular part of the reply made me nervous “coming soon in the second half of 2010” this is because almost every EMC road map I’ve seen over the years breaks the year up into quarters.

EMC agreed to take this conversation offline and I’m hoping to get a better indication of the release date soon.


If your running an older version of NetWorker e.g. 7.3.x and you’ve implemented VMware Consolidated Backups, you need to consider the configuration differences between early and recent versions of NetWorker before upgrading.

Lets take a look at the differences

Pre NetWorker 7.4.1 each each virtual machine was configured as a saveset in the client instance of  the proxy server.

Example shown below.


So why is this configuration less then ideal ?

  • Firstly the backup server owns the client index and media database information for every VCB client
  • Limited visibility of the virtual machines configured in NetWorker
  • Both FULLVM and FILE  backup information was stored in the client index

  What changed post 7.4.1 ?

This in my opinion was the point where EMC took a step back and really started to think about how to better improve the configuration of virtual clients within NetWorker.

The image below shows a client configured in NetWorker 7.5.1, no longer is the virtual machine an entry in the saveset field for the proxy server.


Why is this configuration better ?

  • Each virtual machine is configured in NetWorker as you would any other client (which results in each system having its own client index)
  • The FULLVM (full image export) information is now stored in the media database, only vcb file backups populate the client index
  • Improved visibility of virtual machines configured in NetWorker

Final Note

This is a good example of why documentation such as the admin guide and release notes should be read before rushing into any NetWorker  upgrade.

One of the best features of Site Recovery Manager is the ability to perform regular testing of the DR process without any impact on the production systems.

Just recently a mate in the UK called me up with an issue which occurred while he was performing a failover in SRM, I had seen the exact same issue before on a customers site so after a quick change to one of the timeout values, everything was all sorted.

The point I want to make here is that in both cases the Test option in SRM had worked perfectly but when an actual failover was done (using the RUN button) SRM failed the task leaving people scratching their heads.

Some may argue the amount of manual steps and outages required to perform an actual fail over and fail back  (which of course does have an impact on production systems) outweighs the need to perform this kind of testing, some may say its drastic.

Personally I don’t think so, kudos to the customers who actually schedule production outages to truly put the technology to the test.

If you’ve ever gone looking for information on how the VSS integration in VMware tools works with VCB, then I’m guessing you come up empty-handed.

I remember some time ago reading a document called ” Volume Shadow Service Frequently Asked Questions for VMware Partners ” and thought Id dig it up incase someone found it useful.

Why is VMware offering VSS support ?

The requirement for application consistent VMware Consolidated Backup (VCB) snapshots has been communicated by our customers and partners. VCB will utilize our VSS support to take application consistent VCB snapshots. VSS is also the market standard for providing application consistency for Microsoft applications.

How will VMware provide VSS support?

VSS support will be provided via VMware Tools that run in the guest operating system. VMware will provide a VSS Requestor and a VSS Snapshot Provider (VSP). Changes are needed on the ESX platform as well so moving virtual machines across different versions of host will cause erratic behavior.

The Requester component is available inside a supported guest and responds to events from an external backup application. The Requestor also controls the progress of backup operations inside the guest and interacts with the VMware Snapshot Provider. It will be instantiated upon request of the VMware Tools service when a backup process is initialized.

The VMware Snapshot Provider will be registered as a Windows service and will be used to notify an external backup application of provider-specific events during a VSS backup. The VSP is tightly coupled with the aforementioned Requestor. For this reason, it is only enabled by the Requestor when a backup operation takes place.

 What type of backup is taken in the guest when a VMware snapshot occurs ?

The backup type enumeration is a VSS_BT_COPY backup type. Please see‐us/library/aa384679.aspx for more information on VSS enumerations. This also means that incremental and differential snapshots are not provided by this implementation.

Is there a mechanisim to Vmware tools what type of VSS backup to take instead of a VSS_BT_COPY?

No, in the ESX 3.5 Update 2 implementation this is not possible. In the future, backup partners can have finer control.

What is the sequence of events during a VCB Backup ?

1. The proxy initiates a quiesced snapshot for a VM, it will be able pass the information about whether to create full/incremental/differential backup snapshot and corresponding arguments needed by VSS.
2. The host receives this message and forwards it to the VMware VSS components in the guest.
3. The VMware VSS components in the guest initiates the VSS snapshot based on the arguments passed from the proxy and waits for the volumes to quiesce.
4. The guest notifies the host to create a VM snapshot.
5. The host notifies the guest that the snapshot was created.
6. The guest finishes the quiescing operation.
7. The proxy queries the backup component and writer manifests using the API.
8. The proxy accesses the VM snapshot to perform the backup operation.
9. The proxy initiates a delete snapshot for the VM; it will be able to pass the information about the backup status.
10. The host receives this message and forwards it to the VMware VSS components in the guest.
11. The guest will notify the VSS writers about the backup status so that the logs get truncated only after a successful backup.
12. The host deletes the snapshot of the VM

 Is the VSS manifest made avaiable to the backup application after the snapshot has been taken ?

No, in the ESX 3.5 Update 2 implementation the manifest is not passed to the backup application.

If I wanted to run an ESEUTIL after the exchange backup, How can I do this ?

Using the VCB framework, you can run pre and post operation commands to perform these tasks.

Is the VSS shapshot retained after the backup ?

No, we delete the VSS snapshot during the VMware snapshot operation.

Does the implementation provide any restore capabilities such as revert to VSS copy ?

No, since we we delete the VSS snapshot right away, this is not possible.