Recently we encountered an interesting issue. A particular VM in the cloud be a unpingable sometimes. When the network guy tried to ping this VM from the cloud border routers, there would be no reply from one of the router. Yet on the other router there is no issue. So we had to figure out what happened to the ping packets in the cloud. Read the rest of this entry »
Category Archives: Cloud
Recently the team found a bug in vRA 7.1 and 7.2.
- You have a reservation in vRA with 2 networks (e.g. NW1 and NW2), each assigned to a network profile (e.g. NW-Profile1 and NW-Profile2).
- vRA assigns NW1 to the VM
- vRA attempts to allocate an IP from the NW-Profile1, but its exhausted
- vRA next allocates IP from NW-Profile2 and is successful
- vRA does not update the initial network assignment to NW2
- The VM is provisioned to the wrong network
You only see this issue if the first network is exhausted. Case was raised to VMware and waiting for their investigation.
So what does NSX cross vCenter failover look like in a real world scenario?
In this setup, we have 2 NSX managers across two sites, with Site A hosting the primary and DR Site hosting the secondary NSX manager. Simulating a DR scenario, the primary NSX manager, all 3 controllers and all the universal DLR control-VMs are shutdown in Site A
Updated this article after Peter’s comments and my own testing
During failover of an RP4VM consistency group (CG), you have a few choices of selecting the test network to failover your VMs in. Why is this necessary?
RecoverPoint for Virtual Machine (RP4VM) allows you to create disaster recovery per Virtual Machine in your vSphere environment. By itself, the application is great because you can pick and choose what VMs to protect, test failover and even restore your production VM at various points in time. However, if you have vRealize Automation (vRA) and the vendor is trying to sell you the miracle of self-service DRaaS that RP4VM+vRA can bring, you may want think harder about it.
Note: this is a review of 4.3, but I didn’t think much changed for 5.0
1. Very limited set of services from vRA blueprint, not true DRaaS
A very limited set of services are exposed to the automation blueprint. As far as I am aware, there are no other means of creating customized workflow if the standard blueprint does not satisfy you requirements for DRaaS. There are no blueprints to perform production failover, test failover nor to manage CGs or protected VMs. The current blueprint only allows a user to create protected VMs. All other administration has to be done from vSphere. Read the rest of this entry »