In a previous post, I discussed the difference between a component that is marked as ABSENT, and a component that is marked as DEGRADED. In this post, I’m going to take this up a level and talk about objects, and how failures in the cluster can change the status of objects. In VSAN, and object is made up of one or more components, so for instance if you have a VM that you wish to have tolerate a number of failures, or indeed you wish to stripe a VMDK across multiple disks, then you will certainly have multiple components making up the VSAN object. Read this article for a better understanding of object and components. Object compliance status and object operation status are two distinct states that an object may have. Let’s look at them in more detail next.
Whilst at VMworld 2014, I had the opportunity to catch up with the Nexenta team who have been working on a very interesting project with VMware’s Virtual SAN (VSAN). The Nexenta Connect for VSAN product, running on top of VSAN, is designed to provide file services, which allows VSAN to not only store your virtual machines, but also to provide SMB and NFS shares for those virtual machines. I caught up with Michael Letschin and Gijsbert Janssen van Doorn of the Nexenta team to learn more and get a tech preview of the product.
There was a very interesting discussion on our internal forums here at VMware over the past week. One of our guys had built out a VSAN cluster, and everything looked good. However on attempting to deploy a virtual machine on the VSAN datastore, he kept hitting an error which reported that it “cannot complete file creation operation”. As I said, everything looked healthy. The cluster formed correctly, there were no network partitions and the network status was normal. So what could be the problem?
Maxta are another storage vendor that I managed to get talking to at this years’ VMworld conference in San Francisco. Although they were present at last year’s VMworld, they only announced themselves in earnest last November (11/12/13) with the release of the Maxta Storage Platform (MxSP). I spent some time with Kiran Sreenivasamurthy, Director of PM & PMM at Maxta, and he was very open in sharing details on the Maxta product.
If you read the blurb on Maxta on the VMworld sponsor/exhibitor list, it states that they eliminate the need for storage arrays, provide enterprise class data services and has full virtualization integration from UI to data management.
So on the face of it, Maxta is another converged solution, similar in many respects to VMware’s own Virtual SAN, Nutanix, Simplivity, etc. So what makes Maxta so different? Kiran shared his views with me here.
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.