In my 10 part series of posts on the new vSphere 5.1 Storage Features, I called out in part 3 that there was now even greater interoperability between features like Profile Driven Storage and vCloud Director. The purpose of this blog is to highlight this particular interoperability in even more detail.
Some changes have been made to the vSphere Storage Appliance (VSA) Cluster Service in version 5.1. Previously, the VSA Cluster Service was installed on the vCenter Server – there was no way to decouple it. However in VSA 5.1, the VSA Cluster Service is a stand-alone entity. It can still be deployed on the vCenter server, but it can also be deployed outside of it.
For those of you who have been following my new vSphere 5.1 storage features series of blog posts, in part 5 I called out that we have a new Boot from Software FCoE feature. The purpose of this post is to delve into a lot more detail about the Boot from Software FCoE mechanism. Most of the initial configuration is done in the Option ROM of the NIC. Suitable NICs contain what is called either a FCoE Firmware Boot Table (FBFT) or a FCoE Boot Parameter Table (FBPT). For the purposes of this post, we’ll refer to it as the…
For those of you who are already using VSA 1.0, and are considering an upgrade to VSA 5.1, the following information will be of interest to you.
vSphere 5.1 introduced a number of vCloud Director (vCD) interoperability features from a storage perspective, namely ability to take VM snapshots from within the vCD UI, interoperability with Storage Profiles and interoperability with Storage DRS. Admittedly, its been a while since I played with vCD and I am a little rusty, but I wanted to see how well these storage features worked with vCD 5.1. I’ll follow-up with some future posts on how this all integrates, but this first post is just to highlight an issue I ran into in my haste to get the environment up and running. The…
At VMworld 2012 in San Francisco, I had the pleasure of catching up with Scott Kline, Karthik Pinnamaneni & the rest of the team from Nimbus Data. In the weeks leading up to VMworld I read quite a bit about Nimbus Data’s new Gemini Flash Array, but my primary interest was to figure out what integration points existed with vSphere.
I had an interesting question the other day about whether Raw Device Mappings (aka RDMs) still had a reliance on the LUN ID, especially when it comes to the vMotion of Virtual Machines which have RDMs attached. I remember some time back that we introduced a concept called Dynamic Name Resolution for RDMs, which meant that we no longer relied on a consistent HBA number or even the path to identify the RDM, but do we still use the LUN ID in vSphere 5.1?