In this next test of vSphere Data Protection (VDP) interoperability, I wanted to see if a restored vCenter Server appliance would still be able to work with pre-configured vCloud Suite products such as vCenter Operations (vCops), vCloud Automation Center (vCAC), vSphere Orchestrator VCO and Network Virtualization (NSX). All of these products were running to some extent in my environment; vCAC had a simple blueprint for VM deployment, VCO had a simple workflow for renaming a VM and NSX included an Edge device providing a DHCP service. If all of this functionality was still in place post restore, then the backup…
In this third article in the series of backing up the vCloud Suite, we turn our attentions to NSX, VMware’s Network Virtualization product. Before starting, I should point out that NSX has a recommended way of backing up and restoring configuration information via the use of an FTP server, which you need to configure in your infrastructure to hold this exported metadata. However this exercise looks at how you might be able to use VDP to back up and restore an NSX configuration using image level backups. Once again, I wanted to see whether I could restore the NSX environment…
This post is a follow on to a previous post I did on vCops and VDP interop. In this scenario, I am going to try to use vSphere Data Protection (VDP), which is VMware’s Backup/Restore product, to back up and restore a vCloud Automation Center (vCAC) v6.0.1. and vCenter Orchestration (VCO) v5.5 deployment. In this particular scenario, there are nine virtual machines making up my vCAC and VCO deployment. VCO has been deployed in a HA configuration, which accounts for two VMs. The others make up the DEM, Manager, Web, vCAC, SSO and various databases for vCloud Automation Center.
I am currently involved in a project that looks at how we can back up and restore various components of the VMware vCloud Suite. One of these components is vCOps, vCenter Operations Manager. I wanted to verify that I could backup and restore vCOps with VDP, VMware’s Data Protection product. There were a couple of scenarios that I wished to test: Restore vCops VMs outside of a vApp construct and verify that it was still operational Restore vCOps VMs inside of a new vApp construct and verify that it was still operational Restore vCOps VMs inside of the original vApp…
Continuing on my set of posts related to Virtual SAN (VSAN) interoperability, let’s take a look at how vCenter Operations Manager (vC Ops for short) integrates with Virtual SAN. vC Ops version 5.8, which was released in December 2013, recognizes the VSAN datastore and can report various characteristics, as you might expect. Although vC Ops 5.8 was released around 3 months before VSAN GA’ed, this release works with ESXi 5.5U1 and vCenter 5.5U1, the vSphere release which introduced VSAN. However, this release of vC Ops does not present all the ‘storage’ metrics for VSAN like it does for datastores based…
It should come as no surprise but VMware Horizon View is also supported on VSAN. VMware released Horizon View version 5.3.1 to coincide with the vSphere 5.5.U1 and VSAN release. This release allows desktops to be successfully deployed on a VSAN datastore, using default policies for the desktop storage objects. Let’s go through the steps to get this configured and running, and then we can talk about the default policy settings afterwards.
In this post I though it might be useful to share some information about VSAN interoperability with VMware’s flagship backup and restore product, vSphere Data Protection also known as VDP. First a note about versions – that you will need to use the March 2014 release of VDP (version 5.5.6), not just to backup VMs running on VSAN, but to back up VMs running on vSphere 5.5U1. Here is a comment taken from the release notes for ESXi 5.5 U1: vSphere Data Protection. vSphere Data Protection 5.1 is not compatible with vSphere 5.5 because of a change in the way…