HTML5

UnityVSA – Part 2: Deploy

This post is part of a series covering the EMC Free and Frictionless software products.
Go to the first post for a table of contents.

So, to start this off let’s go to the EMC Software Download page; navigating to UnityVSA to get the download. You’ll receive a login prompt, if you have not registered for an EMC account previously, you’ll need one to access the download. Once logged in, you’ll start downloading the OVA file for UnityVSA.

Yes, last time I went immediately to downloading OVAs without reading the manuals my installation failed miserably. But I’m going to try an installation unassisted every time; maybe I’m a glutton for punishment, but I choose to be optimistic that installations should be intuitive, so I prefer trying unaided first.

That’s just me; you might want to check out the Installation Guide and FAQs. Here’s the quick details though… in order to run the VSA you’ll need to be able to run a vSphere virtual machine with 2x cores (recommended is 2Ghz+), 12GB of RAM, and 85GB of hard drive space, plus however much extra space you want to give the VSA to be presented as storage. The VSA does not provide any raid protection inside the virtual array; so if you want to avoid data loss from hardware failure, ensure the storage underneath the VSA is RAID (or VSAN, or SAN itself). You’re also going to want at least two IP addresses set aside; I’d recommend about 5 for a full configuration. Depending on your network environment, you might want to have multiple networks available in vSphere. The UnityVSA has multiple virtual network cards to provide ethernet redundancy. One of those virtual nics is for management traffic, which you could place on a separate virtual switch (and thus VLAN) if you’re topology supports this. My lab is basically flat, so I’ll be binding all virtual nics to one virtual network.

With the downloaded OVA in hand, the initial deployment is indeed incredibly easy. If you’re familiar with OVA deployments, this won’t be very exciting. If you’re not familiar with deploying an OVA, you can follow along in the video below. I’m going to be deploying UnityVSA on my nested ESXi cluster, running VSAN 6.2. You could install directly on an ESXi Host, or even VMware Workstation or Fusion; put that’s another post.

*Note there is no sound, this is to follow along the steps.
  1. In vCenter, right-click the cluster and select “Deploy OVF Template”
  2. Enter the location you saved the UnityVSA OVA file
  3. Select the check box “Accept extra configuration details”, this OVA contains resource reservations which we’ll touch on below.
  4. Provide a name, this will be the virtual machine name, not the actual name of the Unity array
  5. Select the datastore to house the UnityVSA, in my case I’m putting this on VMware Virtual SAN.
  6. Select which networks you wish the UnityVSA bound to.
  7. Configure the “System Name”, this is the actual name of the VSA, I’d recommend matching the virtual machine name you entered above.
  8. Configure the networking, I’m a fan of leveraging DHCP for virtual appliance downloads when possible, it eliminates some troubleshooting.
  9. I do NOT recommend checking the box “Power on after deployment”, the OVA deployment does not include any storage for provisioning pools; for the initial wizard to work, you’ll want to add some additional virtual hard drives.

 

UnityVSA_ResourceReservations

 

A couple notes on the virtual machine itself to be aware of. EMC’s intent with UnityVSA is to provide a production-grade virtual storage array. To ensure adequate performance, when the OVA is deployed the resulting virtual machine has reservations in place on both CPU and memory. These reservations will ensure the ESX host/cluster underneath the VSA can deliver the appropriate amount of resources for the virtual array to function. If you are planning on running UnityVSA in a supported, production environment, I recommend leaving these reservations. Even if you have enough resources to make the reservations unnecessary, I’m sure EMC Support will take issue with you removing them should you need to open a case. If this is just for testing and you are tight on resources, you can remove these reservations.

 

 

 

 

 

Next, let’s add that extra hard drive I talked about and power this up.

 

*Note there is no sound, this is to follow along the steps.

UnityVSA-InitialConfigurationWizard

  1. In vCenter, right click the UnityVSA and Edit Settings
  2. At the bottom under New Device. use the drop down box to select “New Hard Disk” and press “Add”
  3. Enter the size, I’m making a VMDK with 250GB; if you use the arrow to expand the hard drive settings, you can place it on a separate datastore, if you want to using FASTVP to tier between datas tores this is where you’ll want to customer the hard drive.  I’m putting this new hard drive with the VM on VSAN.
  4. Once the reconfigure task is complete, right click your VM again and select “Power On”
  5. I highly recommend opening the console to the VM to watch the boot up, especially on first boot as the UnityVSA will configure itself.
  6. When the console shows a Linux prompt, walk away. Seriously, walk away; get a coffee, take a smoke break, or work on something else. More is happening behind the scenes at this point and the VSA is not ready. You’ll only get frustrated and this watched pot will not seems to boil.
  7. Ok, are you back? Close the console and go back to the virtual machine, ensure the VM Tools are running and the IP address shows up. If you choose DHCP as I did, you’ll need to note the assigned IP address. If you don’t see the IP address, the VSA is still not ready (see, I told you to walk away)
  8. Once the IP appears vCenter, you’re safe to open a browser over SSL to that address.
  9. You should receive a logon prompt, the default login is:
    1. user: admin
    2. pw: Password123#
  10. Did you login? Do you see a “Initial Configuration” wizard? Congratulations then, the VSA is up.

In the next post in this series, we’ll leverage this wizard to fast track configuring the UnityVSA, but, if you want you can cancel the wizard at this point, manually configuring the array; or restarting the wizard later through preferences.

For now, as evident by this post; the deployment of UnityVSA was straight-forward and exactly what we’ve all come to expect of virtual appliances. From download to up and running, user interaction time was less than 2 minutes, with overall deploy time around 30 minutes.

 

 

 

By | May 24th, 2016|EMC, Home Lab, Storage|3 Comments

vSphere HTML5 Web Client – Fling

Last week, a small light appeared at the end of the dim tunnel called the vSphere Web Client. If you’re a vSphere engineer, or even just a user managing applications or server; you know what I’m talking about.

The vSphere Web Client has been problematic since day one. Some days it feels like you need an incantation to get the web client working, with Adobe Flash, browser security, and custom plug-ins. Even when you do, the slow response time of the web client directly impacts your productivity. Then there has been the very slow migration from the C# client, with components such as vCenter Update Manager just recently being available in the web client. Plus, only with the recent fling activity around the ESXi Embedded Host Client can we see a world where we don’t need the C# client at all.

Speaking of flings; the vSphere HTML5 Web Client is currently a VMware Fling; a technology preview built by VMware engineers with the intent the community explore and test, providing feedback. Often flings make it into the product in a future release, though that is largely dependent on the feedback from the community. This one needs our feedback!

If you are running vSphere 6, I highly encourage you to install the vSphere HTML5 Web Client. Currently, the deployment is through a vApp with the web server hosting the interface on a separate virtual machine from any of your vCenter Servers. This means there is very low risk to your environment, as you aren’t modifying your existing vCenter, rather extending it through the SSO engine to a separate web server.

At first glance, the instructions for the fling appear a little involved, though trust me they are not. All told it took me about 10 minutes to setup the H5 Web Client. The instructions are very detailed, so I won’t repeat them in depth; though I captured my deployment if you are interested.

I have both VCSA and vCenter for Windows in my lab, the fling will work with either (and will support an existing enhanced link mode setup like mine). I went the Windows route as it’s my platform services controller and SSO server.

  1. Download the OVA and the batch file
  2. Execute the batch file, which generates three config files
  3. Deploy the vSphere HTML5 Web Client OVA
  4. Once the new vApp is only, follow the instructions to create three new directories.
  5. Using a tool such as WinSCP, copy the three files from your vCenter server to the
  6. vSphere Web Client server
  7. Set the NTP Server
  8. Start the web server
  9. Browse vCenter in beautiful native HTML5, no plug-ins, no flash, so fiddling with your browser security. (If you are not already logged in to vSphere, the H5 site will redirect you to the SSO for authentication)

 

*Note there is no sound, this is to follow along the steps. The video is not speed up, this is the actual deployment time

Again this is the very first preview and as such the functionality is limited. Here a just a few screen shot while you’re waiting on the download.

This slideshow requires JavaScript.

By | April 6th, 2016|Home Lab, VMWare|0 Comments