VMware Mobile Knowledge Portal (VMKP) app version 2.0 is now live!

VMKPFor those of you who would like to access VMware’s Technical Marketing material whilst on the move, we are pleased to announce version 2.0 of the VMware Mobile Knowledge Portal (VMKP) app is now available. The VMKP contains all Technical Marketing content including Videos, Evaluation Guides, What’s New papers, White Papers & Posters. These pieces of collateral may also be downloaded for offline viewing.

This new version now supports Android devices as well as IOS iPad device.

Please check out the post by Alan Renouf on the vSphere blog to learn more, see some sample content and the links on where to download the app.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage

What are Dependent, Independent Disks & Persistent and Non-persisent Modes?

I had a query about this recently, and actually it is a topic that I have not looked at for some time. Those of you configuring virtual machine disks may have seen references to these different configuration options and may have wondered how they affect the behavior of the virtual machine. Read on to find out the subtleties between Independent Persistent Mode and Independent Non-persistent Mode disks, and what impact they may have.

Continue reading

Heads Up! New Patches for VMFS heap

Many of you in the storage field will be aware of a limitation with the maximum amount of open files on a VMFS volume. It has been discussed extensively, with a blog articles on the vSphere blog by myself, but also articles by such luminaries as Jason Boche and Michael Webster.

In a nutshell, ESXi has a limited amount of VMFS heap space by default. While you can increase it from the default to the maximum, there are still some gaps. When you create very many VMDKs on a very large VMFS volume, the double indirect pointer mechanism to address the blocks way out in the address space consume heap. The result is that although we supported very large VMFS volumes (up to 64TB), the reality up to now is that a single host (since heap is defined on a per host basis) could only address in the region of 30TB of open files. This isn’t always an issue, since typically VMFS is a clustered file system and is shared by many hosts. Therefore one would typically have the open VMDKs spread across many hosts in a cluster. However it is an issue for stand-alone hosts with lots of virtual machines with lots of VMDKs, and is also an issue for hosts which want to have a virtual machine with a lot of VMDKs attached, for the purposes of a file share for example.

Anyway, to cut to the chase, a recent patch release for ESXi 5.0 increases the default heap size to 256MB and maximum heap size to 640MB per ESXi host. This should allow a single ESXi host to access in the region of 60TB open VMDK. Previously the default was 80MB and the maximum was 256MB, so we have increased this significantly. This is pretty much the maximum size of the VMFS volume anyway. The patch is Patch ESXi500-201303401-BG.

Although the patch for ESXi 5.1 is not yet out, it should be available very shortly, and will have a similar fix.

For those of you using very large VMFS volume with lots of virtual machines disk files, consider scheduling a maintenance slot very soon to apply these patches. This is not an issue for NFS, fyi.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage

Microsoft Clustering on vSphere – Incompatible Device Errors

When setting up a Microsoft Cluster with nodes running in vSphere Virtual Machines across ESXi hosts, I have come across folks who have experienced Incompatible device backing specified for device ‘0’ errors. These are typically a result of the RDM (Raw Device Mapping) setup not being quite right. There can be a couple of reasons for this, as highlighted here.

Different SCSI Controller

On one occasion, the RDM was mapped to the same SCSI controller as the Guest OS boot disk. Once the RDM was moved to its own unique SCSI controller, it resolved the issue. Basically, if the OS disk is configured to use SCSI 0:0, then you cannot put the RDM on SCSI 0:1, or SCSI 0:2. You must put the RDM on SCSI 1:x or SCSI 2:x.

Matching LUN ID

Another reason for the above error is when the RDM is presented to the different ESXi hosts using a different LUN ID. The RDM must be presented to all ESXi hosts (and thus all MSCS nodes) using the same LUN ID.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage

A closer look at GreenBytes

greenbytes-logoFollowers of my blog will have seen a number of articles posted recently about storage vendors that I managed to catch up with at this year’s VMware Partner Exchange in Las Vegas. In the last in this series of articles, I managed to spend some time with the folks from GreenBytes. The timing was very opportune, as GreenBytes just made a major announcement to their portfolio, namely their new vIO, the virtual storage appliance version of their IO Offload Engine solution for desktop virtualization. I met up with Michael Robinson (VP, Marketing), Jeff Eberhard (Sr. Systems Engineer) and Steve O’Donnell (CEO) of GreenBytes to get the low-down on their current product offerings and to learn a bit more about their very recent vIO announcement.

Continue reading