Highlighted
exponenthr
1 Copper

How do you protect the virtual XMS in 3.0 and later?

Jump to solution

In 3.0 and later, the XMS virtual appliance uses a Paravirtual SCSI controller and an 837GB thin provisioned disk. We use EMC Avamar for data protection and leverage VM image level backups for all VMware VMs. Our prior XMS came up through the ranks beginning with 2.2 so it did not have a PVSCSI adapter. Now, of course, we cannot use image-level backups to backup the XMS, since Hot-Add doesn't support PVSCSI. I haven't seen anything in the communities about this, and I suspect that traditional VMs with PVSCSI disks would be protected with in-guest agents. Does anyone know how EMC suggests protecting the XMS?

I've also created an SR to ask directly, but as it is an S3, I'm expecting a decent delay in processing.

Thanks,

Chris

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Avi3
3 Silver

Re: How do you protect the virtual XMS in 3.0 and later?

Jump to solution

Hi Chris,

Paravirtual SCSI controller was added to the XMS in our latest release to improve performance. However, this should have no impact on the XMS recovery process. In the worse case, if the XMS has to be recovered (if there was a failure) - we always keep the configuration backed up on the array itself. This was true before version 3.0 came out, and is true now.

You do not need to use image level backup tools (like Avamar) to backup the XMS. It seems you use Avamar to backup all your VMs (including the XMS) - you can exclude the virtual XMS from your backup. We do not recommend backing up the virtual XMS using external tools - there is no added benefit that you get out of it.

Hope this helps.

4 Replies
Avi3
3 Silver

Re: How do you protect the virtual XMS in 3.0 and later?

Jump to solution

Hi Chris,

Paravirtual SCSI controller was added to the XMS in our latest release to improve performance. However, this should have no impact on the XMS recovery process. In the worse case, if the XMS has to be recovered (if there was a failure) - we always keep the configuration backed up on the array itself. This was true before version 3.0 came out, and is true now.

You do not need to use image level backup tools (like Avamar) to backup the XMS. It seems you use Avamar to backup all your VMs (including the XMS) - you can exclude the virtual XMS from your backup. We do not recommend backing up the virtual XMS using external tools - there is no added benefit that you get out of it.

Hope this helps.

exponenthr
1 Copper

Re: How do you protect the virtual XMS in 3.0 and later?

Jump to solution

My SR was just concluded with a similar answer. The engineer also put in an enhancement request for more customer-facing recovery/backup methods. It's not my desired outcome (and rather a backwards step, moving from protectable in 2.2 to locked out in 2.4 and later), but there's nothing to be done.

0 Kudos
Avi3
3 Silver

Re: How do you protect the virtual XMS in 3.0 and later?

Jump to solution

Note that this is NOT a backward step. The XMS recovery will continue to work as it always did. Even with the previous releases, even though you were backing up the XMS using Avamar - the XMS recovery (if needed) would have been done by the EMC support personnel and there was no advantage of having a backup through Avamar. The XMS details are always stored on the storage array and we therefore never asked our customers to take an explicit back up of the XMS - there was no additional benefit of doing that.

The benefit that you now have is that you get better performance because of the Paravirtual SCSI controller.

0 Kudos
exponenthr
1 Copper

Re: Re: How do you protect the virtual XMS in 3.0 and later?

Jump to solution

We haven't had much success in depending on XtremIO's reliability, so you'll forgive me for being reticent of a solution that depends entirely on EMC Support and recovering control from the array itself. Surely you can see the rational in desiring a backup of the XMS, even if it is only useful as a comparison or reference point in the event that there are challenges recovering directly from the array (even if this has always been the case).

Regarding the "better performance" from the PVSCSI controller, I don't see what practical value this has since the XMS isn't in-line, nor is it responsible for any significant data transfers (http://blogs.vmware.com/vsphere/2014/02/vscsi-controller-choose-performance.html). I understand that in the distant future, XIOS 4.0 is supposed to leverage the huge disk for additional performance logging, but in the here-and-now, I don't see any function of the XMS that gains a tangible benefit from PVSCSI.

0 Kudos