[Updated] This is a very short post as I only learnt about this recently myself. I thought it was only available in vSphere 5.5 but it appears to be in vSphere 5.1 too. Anyhow Storage DRS now has a new setting that allows you to configure the default VM affinity setting. Historically, VMDKs from the same virtual machine were always kept together on the same datastore by default; you had to set a VMDK anti-affinity rule to keep them apart. Now you can set a default for this option, which can either be to keep VMDKs together on the same datastore or to keep VMDKs apart on different datastores.
All Flash Arrays continue to make the news. Whether it is EMC’s XtremIO launch or Violin Memory’s current market woes, there is no doubt that AFAs continue to generate a lot of interest. Those of you interested in flash storage will not need an introduction to SolidFire. These guys were founded by Dave Wright (ex-RackSpace) and have been around since 2009. I have been trying to catch up with SolidFire for sometime as I’d heard their pitch around Quality of Service on a per volume basis and wanted to learn more, especially how it integrated with vSphere features. Recently I caught up with Dave Cahill and Adam Carter of SolidFire to have a chat about SolidFire in general and what the VMware integration points are.
I wrote about this issue on the vSphere blog some time back. Essentially, the issue described in that post was if a VM that was being replicated via vSphere Replication was migrated to another datastore, it triggered a full resync because the persistent state files (psf) which tracks the changes were deleted. All of the disks contents are then reread and check-summed on each side. This can have a significant impact on vSphere Replication’s RPO (Recovery Point Objective).
The answer right now is no, but if you are interested in how this query came about, and why I decided to blog about it, continue reading. It has something for those of you interested in some of the underlying workings of Storage DRS. Continue reading
You may remember an enhancement which we made to Storage I/O Control (SIOC) in the 5.1 vSphere release whereby SIOC can now automatically determine the characteristics and thus the latency threshold of a datastore. Prior to this change, SIOC used either a default value or had customers manually set it. Neither of these were ideal, so we introduced this automatic method. However, there was little detail on how often this latency threshold was calculated. In other words, did the calculation take place when SIOC was first enabled, or is there regular on-going calculations?
One of my friends over in VMware support just gave me a heads-up on this issue. It affects virtual machines with anti-affinity VMDK rules defined (for keeping virtual machine disks on different datastores in a datastore cluster) when changing the Storage DRS automation level via scheduled tasks. The rule will be removed if you use the Storage DRS scheduler to change Storage DRS automation level from automatic to manual and then back to automatic. The result is that a VM which had an anti-affinity rule and has its VMDKs on different datastores could end up with its VMDKs on the same datastore after the scheduler runs.
This is a follow-up to my previous post on the 5.0U2. At the same time, VMware also released vCenter 5.1.0b. This post will look at the storage items which were addressed in that update, although the issues that are addressed in the storage space are relatively minor compared to the enhancements made in other areas. Note that this update is for vCenter only – there is no ESXi 5.1 update.