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
On a recent trip to VMware in Palo Alto, I found some time to visit with a good pal of mine, Vinay Gaonkar, who is now the Product Manager for XtremIO over at EMC. Vinay used to be a storage PM at VMware (he worked on the initial phases of VVols), and we worked together on a number of storage items in various vSphere releases. It’s been almost 2 years since I last spoke to the XtremIO folks (VMworld 2012 in fact, when the product still had not become generally available), so I thought that this would be a good time to catch up with them, as we are in the run up to VMworld 2014.
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 just learnt this morning that the paper edition of the Essential Virtual SAN (VSAN) book that I wrote with my colleague and good pal Duncan Epping is now available. The e-book and kindle versions were available a couple of weeks ago, but its great to see the paper edition hit the shelves. The book will hopefully have all you need to get you up and running with VSAN, including architecture details and design considerations. We tried to include everything that someone involved in VSAN administration would need.
I can now appreciate the time and effort that authors put into writing books. This is my first book, and although I had written a number of white papers and presentations in the past, this was something very new for me. Thanks again to Duncan for his help with getting this project up and running, to Christos and Paudie for reviewing the content, and of course to VMware Press for agreeing to publish it. I hope you find the book useful. Go VSAN!
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 next test of vSphere Data Protection (VDP) interoperability, I wanted to see if a restored vCenter Server appliance would still be able to work with pre-configured vCloud Suite products such as vCenter Operations (vCops), vCloud Automation Center (vCAC), vSphere Orchestrator VCO and Network Virtualization (NSX). All of these products were running to some extent in my environment; vCAC had a simple blueprint for VM deployment, VCO had a simple workflow for renaming a VM and NSX included an Edge device providing a DHCP service. If all of this functionality was still in place post restore, then the backup and restore will have worked. Testing was done with vCenter Server appliance version 5.5U1 and VDP version 188.8.131.52.