As many of you are aware, I was at VMworld in San Francisco last week. I wrote a number of articles about some VMware storage announcements, such as EVO:RAIL, VAIO and VVols. However there were, as usual, quite a number of storage vendors at this years conference. One of the vendors that I really want to learn more about was Kaminario, an all flash array vendor that I’d heard a lot of things about. I had the pleasure of spending some time at the Kaminario booth with Shai Maskit who is a senior Product Manager with Kaminario. I posed my usual set of questions to learn a bit more about their AFA products. Continue reading
It’s interesting how a number of conversations tend to pop up around the same issue in a short space of time. I read a very interesting thread from one of our support guys recently about trying to select the correct administrator credentials for the Ruby vSphere Console (RVC). RVC is a command line utility to manage various aspects of vSphere and has been extended to include VSAN functionality. The following day, I saw a thread on the VSAN forums for exactly the same thing – a customer experiencing difficultly logging into RVC on a remote vCenter server as administrator. The bottom line is that the RVC credentials are directly related to the default domain setting in SSO (Single Sign-On). Continue reading
I’ve done a few posts in the past which discuss the VM Home Namespace object. To recap, the VM Home Namespace is where we store all the virtual machine configuration files, such as the .vmx, .log, digest files, memory snapshots, etc. I also highlighted that the VM Home Namespace is limited to 255GB in size. This led one reader to raise the following observation:
It means that it is not possible to do a snapshot with memory for a VM with 256 GB of RAM.
This is indeed correct. If you attempt to snapshot a VM (with memory) that has a memory configuration that does not fit into the VM Home Namespace (in this case I created a VM with 256 GB of memory), you will hit the following “insufficient disk space on datastore” error:
Are there any plans to decrease VM Home Namespace?
I can’t say too much about futures at this point, but what I can say is that the issue is recognised, and we certainly plan to address it going forward. However, in the meantime, if you have VMs with large memory requirements, and you wish to be able to snapshot those VMs along with the memory, be cognizant of this restriction.
Because of that, Duncan and I decided we will give away 4 e-books each. If you want to win one then please let us know why you feel you deserve to win a copy using the hashtag #essentialvirtualsan on twitter.
Duncan and I will decide which 8 tweets will win an eBook, and of course we will favor the ones that make us laugh – it’s as simple as that!
So just to be clear:
- Tweet why you think you deserve the book
- Use the hashtag #essentialvirtualsan
- Be funny!
The 8 winners will be announced Friday, August 8th, 2014.
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.
This is a question that has come up a number of times. Many of you will now be familiar with the VM Storage Policy capability Number Of Failures To Tolerate for VSAN, which defines how many failures can occur in the VSAN cluster and still provide a full copy of the data to allow a virtual machine to remain available. In this short post, I will explain how many physical ESXi hosts you need to accommodate the Number of Failures To Tolerate requirement in the VM Storage Policy.
In this post, we talk about a particular behaviour with using the default (or None) policy with VSAN. I have stated many times in the past that when a VM is deployed on the VSAN datastore, it behaves like it is thinly provisioned unless the capability ‘Object Space Reservation’ (OSR) is specified in the VM Storage Policy. The OSR will pre-allocate space on the VSAN datastore for the virtual machine’s storage objects, and is specified as a percentage of the actual VMDK size. However, there is a slightly different behaviour when the default policy is used. Once again, I was in a conversation with a customer who stated that when he used the default policy of “None”, he could see space being consumed on the VSAN datastore was equal to the size of the VMDK * FTT (Number of Failures To Tolerate). He wondered why this was the case when the default policy clearly did not contain an Object Space Reservation capability.