Yesterday was my first day at VMworld 2014. As usual with this event, there are simply so many interesting announcements that it is hard to keep track. However, for me, there were a few things which stood out in the storage space worth calling out. These are specifically VMware focused products and features. I know that many of our partners have also made announcements in the storage space, but for today I concentrated solely on VMware. There are the two that really caught my attention.
Last year I published a list of storage vendors and partners that I was planning to check out at VMworld 2013. This year is no different, with a number of new arrivals on the storage scene, as well as some super new cool products from many of VMware’s partners. Whilst this is no means a definitive list of what’s on show, these are the ones that I am particularly interested in checking out this year.
I was involved in an interesting thread recently with one of our VSAN partners regarding disk sizes used in VSAN, and what impact smaller drives may have. In an earlier post, I discussed reasons why VSAN would stripe a VMDK storage object even though a stripe width was not requested in the VM Storage Policy – Why is my Storage Object striped?
In that post, I highlighted the fact that if the VMDK storage object is too big to fit onto the free space of a single hard disk, then it will automatically be striped across multiple hard disks. However there is another VSAN object that disks size may also impact – the VM Home Namespace.
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 to a particular point in time, in-place and also by restoring to a new location. This is the same infrastructure that I used for backing up and restoring vCops and backing up and restoring vCAC and VCO. On this occasion, I was using NSX version 6.0.4, vCenter 5.5U1 and VDP version 126.96.36.199.
I’m a bit late in bringing this to your attention, but there is a potential issue with VASA storage providers disconnecting from vCenter resulting in no VSAN capabilities being visible when you try to create a VM Storage Policy. These storage providers (there is one on each ESXi host participating in the VSAN Cluster) provide out-of-band information about the underlying storage system, in this case VSAN. If there isn’t at least one of these providers on the ESXi hosts communicating to the SMS (Storage Monitoring Service) on vCenter, then vCenter will not be able to display any of the capabilities of the VSAN datastore, which means you will be unable to build any further storage policies for virtual machine deployments (currently deployed VMs already using VM Storage Policies are unaffected). Even a resynchronization operation fails to reconnect the storage providers to vCenter. This seems to be predominantly related to vCenter servers which were upgraded to vCenter 5.5U1 and not newly installed vCenter servers.
We’ve seen a spate of incidents recently related to the HP Smart Array Drivers that are shipped as part of ESXi 5.x. Worst case scenario – this is leading to out of memory conditions and a PSOD (Purple Screen of Death) on the ESXi host in some cases. The bug is in the hpsa 188.8.131.52-1 driver and all Smart Array controllers that use this driver are exposed to this issue. For details on the symptom, check out VMware KB article 2075978.
HP have also released a Customer Advisory c04302261 on the issue.
This was a tricky one to deal with, as one possible step might be to roll back/downgrade the driver to an earlier version. Unfortunately, not only is this not supported (or documented), but you might also find that an older driver may not work with a newer storage controller. The good news is that HP now have a new version of the driver available which fixes the issue. Customers should upgrade to HP Smart Array Controller Driver (hpsa) Version 184.108.40.206-1 (ESXi 5.0 and ESXi 5.1) or Version 220.127.116.11-1 (ESXi 5.5). Details on where to locate the driver and how to upgrade it are located in their advisory. Think about doing this as soon as possible.
I just recently received my credentials to VMware’s vCloud Hybrid Services. One of the first things I was interested in testing out was the Disaster Recovery Service, which uses VMware’s vSphere Replication technology to protect VMs in your on-premise DC to vCHS. The following post provides the steps to configure the replication target as your vCHS VDC (virtual data center), and then configuring replication on a VM.