Currently viewing the tag: "VSA 5.1"

VSA Upgrade Required after Applying vCenter Server 5.1U1 Patch

By On · Add Comment

VSA-Video.pngHeads up folks! for those of you that are using the vSphere Storage Appliance 5.1.1 (VSA). If you have or are planning to apply the vCenter Server 5.1U1 patch, you must also upgrade the Sphere Storage Appliance (VSA) to version 5.1.3 after deploying the vCenter Server 5.1U1 patch due to the fact that the Sphere Storage Appliance 5.1.1 (VSA) is not compatible with the latest vCenter Server patch release.

Some of the changes added to the new release are:

  • Increase of the VMFS heap size to 256MB by default. This change will allow ESXi hosts to address up 24TB of storage capacity.
  • Support for 10 Gigabit Ethernet NICs

Check out the vSphere Storage Appliance 5.1.3 (VSA) release notes for more details on the fixes and features of this release.

- Enjoy

For future updates, be sure to follow me on Twitter at  @PunchingClouds

vSphere Web Client and VSA Manager Issues with Google Chrome

By On · Add Comment

Recently a customer reached out to me and informed me about an issue they ran into while managing a VSA ROBO environment with the vSphere Web Client and Google Chrome browser and I wanted to inform everyone about the issue and how to resolve it.

When using the vSphere Web Client with the Google Chrome browser the error message illustrated below is produced whenever an attempt is made to access the VSA Manager for the first time.

VSA Chrome Error

 

This is a known issue and its not a vSphere Web Client issue per say. This is due to the way the Google Chrome browser behavior with self signed security certificates. The workaround to this issue is listed below:

  • Copy the entire url portion of the produced “This webpage is not available” error message and paste it to a new tab in Google Chrome.
  • Click the option to proceed to the website when Google Chrome produces the security warning.
  • Reload the vSPhere Web Client and now the VSA Manager should be accessible and displayed correctly.

Bookstore bw2

Hope folks find this useful

- Enjoy

For future updates, be sure to follow me on Twitter at  @PunchingClouds

VSA 5.1 Brownfield Deployment Video

By On · Add Comment

VSA-Video.pngA couple of weeks ago I wrote a series of articles on the VMware vSphere Storage blog about considerations for successful deployments of the vSphere Storage Appliance (VSA) 5.1 onto an existing vSphere Infrastructure, normally referenced as a “Brownfield Deployment”.

Because of the VSA 5.1 requirements for this type of deployments are so strict and very specific, I wanted to do a bit more than just write a few deep dive articles and decided to create a video of the process as well. I have received numerous customer questions on this topic and I believe the blogs articles were helpful and fairly successful, but I’m a big believer in demonstrations that illustrate what needs to be done.

So here you have it, how to successfully execute a VSA Brownfield deployment with minimal or zero downtime. The video was produced and voiced over by Graham Daly who is a Multimedia Specialist within the Global Support Services (GSS) Knowledge Management group at VMware. Graham did a heck of a job with the production of the video and adding his comforting voice as well (LOL, I was really bad at that)

The video is now part of the KBTV and is accessible to everyone on VMware Support Insider blog, KBTV YouTube channel, and of course here.

- Enjoy

For future updates, be sure to follow me on Twitter at  @PunchingClouds

DRS Affinity Rules for vSphere Storage Appliance

By On · 1 Comment

VSA-LogoBased on a recent customer inquiry with regards to the use of DRS Affinity rules with vSphere Storage Appliance (VSA) 5.1 environments I wanted to shared with everyone my response based on this topic. Understanding the functional capabilities of the vSphere features and how they integrate with the different solutions VMware provides it’s important and therefore I’ve decided to share this with the rest of the community. The question was based on a real customer scenario and fairly long as it involved other VMware products. I’ve condensed the question to the main concern below:

“Is it necessary to create DRS affinity rules to pin the vSphere Storage Appliance to each host in a VSA Cluster in order to prevent DRS from migrating the appliances to other ESXi hosts?”

I believe this to be a valid concern and a great question as the customer clearly understands the business problem DRS is design to address,  which is basically to mitigate contention between workloads in a DRS enabled cluster. The answer to the question is “No”, you don’t need to create DRS Affinity rules in order to prevent DRS from migrating the vSphere Storage Appliance VMs from one ESXi host to another, and here is why:

The vSphere Storage Appliance solution presents local storage (VMFS volumes) as a shared resource amongst the members of a VSA Cluster. The vSphere Storage Appliance architecture is design to supports two and three ESXi node clusters. The VSA Installer/Manager will deploy a single VSA appliance per host in order to consume the local storage (VMFS volumes) presented to each ESXi host and present it as shared resource know as the VSA Storage Cluster. Once deployed, each vSphere Storage Appliance controls the storage volumes, storage presentation, synchronization, replication, etc.

Logical vSphere Storage Appliance & Resources

Logical VSA Resources

By listing all of those facts and function I’m trying to illustrate the fact that each vSphere Storage Appliance has a 1-to-1 relationship with the ESXi hosts and local storage (VMFS volumes) where they are being hosted. If you think about it, the fact the vSphere Storage Appliance VMs are stored on the ESXi local storage (VMFS volume) but they also control what is not a shared volume in a sense. That right there screams normal vMotion violation, and for that matter a DRS violation as well. In a normal circumstance DRS will not be able to migrate the VMs to other ESXi members of a Cluster, let alone a vSphere Storage Appliance VM to another VSA Cluster member.

This is behavior is included in the product by design, and aside from the facts the vSphere Storage Appliance VMs are programmatically prevented from being vMotioned regardless of DRS being enables in the VSA Cluster. This can be validated by looking at the options available to the vSphere Storage Appliance VMs on both the vSphere Web Client, and the vSphere Client (C#) user interface as illustrated below.

vSphere Web Client UI

VSphere Web Client UI

 vSphere Client (C#) UI

VSphere C Client

 Here is behavior that may occur when using the vSphere Web Client. The loading and response time of the vSphere Web Client it’s slower than it’s predecessor and there maybe times when all the functions and settings may take a bit longer to load and as a result of that the Migrate option maybe available and not grayed out from the menu and one could select to migrate the vSphere Storage Appliance VM. While this is a possibility, the migration will not be executed. This is again based on the fact I mentioned previously “the vSphere Storage Appliances VMs are programmatically prevented from being vMotioned and migrated.

As a result of a migration attempted in this scenario a “migrate…” error will be generated as illustrated below. This behavior is only experience with the vSphere Web Client.

vSphere Web Client Migrate Program Message

VMotion Migration Message

 I hope this information is useful for all vSphere Storage Appliance users and customers.

- Enjoy

For future updates, be sure to follow me on Twitter at  @PunchingClouds

Installing the VSA Cluster Service on the vMA Appliance

By On · 2 Comments

VSA Cluster ServiceRecently I’ve been writing and publishing a series of articles on the vSphere Storage Appliance on the VMware Storage blog. There is quite of bit of interest on this solution now that it supports centralize and de-centralized management of multiple VSA Clusters. One of the new features of the VSA 5.1 is that it allows you to centrally manage multiple two node or three node clusters from a single instance of vCenter Server. I’ve covered the VSA centralized management for ROBO topic in lengthy details in the VMware Storage blog so I recommend reading those articles to get up to speed on that.

One of the big topics around the use of VSA for ROBO is around the correct use and deployment of the VSA Cluster Service (VSACS). It’s important to know that all scenarios that will be based on two clusters require the deployment of the VSACS. The requirements for this solution demands for the VSACS to reside outside of the resources provided by the VSA Cluster in order to avoid  VSA Cluster service outages. The options available for the deployment of the VSACS range from using an virtual machine, an existing shared physical system or an inexpensive hardware appliance that meets the applications requirements.

So in an effort to simplify implementation and even possibly reduce the cost around the management and implementation of  two node VSA cluster scenarios the utilization of the vMA appliance can be considered. The vMA appliance i snow build on top of one of the Linux distribution (SLES) supported by the VSACS and it presents the following benefits to this solution:

  • Preconfigured and support Operating system
  • Free of charge
  • Small footprint
In order to install the VSA Cluster Service bits on to the vMA appliance there is a required tool called (gettext) that is not part of the default installation of the vMA which needs to be installed before installing the VSACS. Im going to provide the step-by-step procedure on how to get this done. All the stuff I’ve learned about modifying and customizing the vMA appliance have come from William Lam (@lamw) one of my colleagues at VMware. If you want to know more about working with the vMA appliance check out his blog and particularly an article called Tips and Tricks for vMA 5.