The idea of changing a Placeholder Datastore in SRM has come up a few times in internal discussions recently and there was some confusion around how to deal with it so I wanted to put something together to clarify things.
As a quick refresher, Placeholder Datastores are used to contain the Placeholder VM files at the recovery site. If you intend to do a Planned Migration and Reprotect you will need Placeholder Datastore(s) at the protected site as well.
Here is the process for changing the Placeholder Datastore(s) at the recovery site. The process is the same for the protected site.
For the third article of the Virtual SAN interoperability series, I want to showcase the interoperability between Virtual SAN vSphere Replication and vCenter Site Recovery Manager. This demonstration presents one of the many possible ways in which customers can use of vSphere Replication and vCenter Site Recovery Manager with Virtual SAN.
In the demonstration below, I performed a fully automated planned migration of virtual machines hosted on traditional SAN infrastructures onto a Virtual SAN environment seamlessly. This example particularly shows how simple this type of operation can be achieved utilizing existing vSphere tools and technologies that possess integration capabilities with Virtual SAN.
Continuing on with features found in the vSphere Distributed Switch, the Backup and Restore capability is a feature I rarely saw used when I was in the field. I saw, and still do see, customers going out of their way to make sure they can backup the vCenter database, and even more so SSO, but if you have to rebuild your vCenter or migrate to a new one and don’t have a backup of your Distributed Switch you’re going to be in for a lot of work.
For the second article of the Virtual SAN interoperability series, I showcase the interoperability between Virtual SAN and vCloud Automation Center. This demonstration presents one of the many ways in which vCloud Automation Center can be used to provision virtual machines onto a Virtual SAN infrastructure via a service catalog.
In this scenario, I have created and published three vCloud Automation Center blueprints to a service catalog. All blueprints are accessible to all users in a private cloud. Each blueprint was created based on virtual machine templates that are configured with a VM Storage Policy which was assigned at the vSphere level.
A VM Storage Policy is a vSphere construct that store storage capabilities in order to apply them onto virtual machines or different VMDKs. In this case the capabilities are based on capacity, availability, and performance which the offerings of Virtual SAN. In the demonstration, the focus is around deploying a virtual machine with the highest level of availability. Virtual machine or VMDKs availability configurations are defined by the “Number of Failures to Tolerate” storage capability. The service catalog contains 3 different virtual machine offerings each with a different “Number of Failures to Tolerate” policy as defined below:
In effort to continue to providing information about Virtual SAN and its capability via recoded demos I’ve created a new set of Virtual SAN walkthrough demos .
The walkthrough demos are available and accessible online, for everyone that is interested in learning about how Virtual SAN works, its capabilities and how does it interoperate with other VMware products and solutions. To access the Virtual SAN walkthrough demos use the link below:
So by now most of you are aware that Virtual SAN 5.5 was released last week, and it came in with a bang. During the launch event, we announced some impressive performance numbers, detailing 2 Million IOPS achieved in a 32-node Virtual SAN cluster. One of the most frequent questions since the launch has been what are the details of the configuration we used to achieve this monumental task. Well wait no longer, this is the post that will reveal the details in all their magnificent glory! Continue reading →
The deployment and configuration of Virtual SAN has been deemed “radically simple” because of its simplistic two click configuration capability. For the most part, most people have yet to see what the deployment and configuration of a large Virtual SAN cluster looks like and in actuality what it takes. Virtual SAN requires the configurations of dedicated virtual network interfaces as well as configuration to physical uplinks.
Configuring large clusters could potentially become time consuming and susceptible to configuration errors when done manually. In the interest of Virtual SAN interoperability and deep integration with the rest of the vSphere platform and its features the use of the vSphere Distributed Switches complement the overall ease of the configuration and deployment of Virtual SAN.
The vSphere Distributed Switches configuration “Template Mode” feature can be leverage to improve the agility of the virtual network configuration and also drastically reduce the risk of virtual network mis-configurations. This demonstrations showcase the deployment and configuration of a Virtual SAN along with its requires network configuration. For those who were not aware, the vSphere Distributed Switch is included as part of the Virtual SAN licensing.
Watch how simple and easy configure and deploy and 16 node Virtual SAN cluster with a vSphere Distributed Switch in a few minutes.
When talking with customers about our vSphere Distributed Switch I often find that they don’t know about a feature in the Traffic Filtering policy engine that allows for creation of Access Control Lists or ACLs. This is in additional to being able to tag traffic and pass Quality of Service (QoS) or Differentiated services Code Point (DSCP) values up to the physical network for prioritization.
I was recently involved in a conversations with regards to Virtual SAN and virtual machine migration capabilities. A few customers have been wondering about whether or not all of the vSphere migration operation and functions work with Virtual SAN due to the way the system works. One particular migration operation in question was around the ability to migrate virtual machines.