Home > Blogs > VMware Consulting Blog > Monthly Archives: May 2015

Monthly Archives: May 2015

VIO – A Closer Look from a vSphere Administrator View.

Julienne_PhamBy Julienne Pham

A version of VMware Integrated OpenStack was released in April, and for the DevOps team, the Cloud API did not change from one vendor to another. So, how does it impact me as a vSphere administrator?

This article will go through how VIO can be managed through the vSphere Web Client.

After deploying the VIO cluster services instance, this is what I have noticed:

One Single Pane of Glass

Yes, the initial OVA deployment involves the registration of the VMware Integrated OpenStack services to vCenter Service, so there is no surprise to see the OpenStack logo on the vSphere Web Client.

Instead, I find it very practical to be able to configure all the services through the same vSphere Web Client.

JPham vSphere Web Client

 

Backup and Restore Configuration File

I like this feature in particular, if you are like me, someone who is constantly multitasking, it is really a gain of time when you have to redeploy the OpenStack services or troubleshoot any deployment issue.

The installation requirements can be found on this article: http://blogs.vmware.com/openstack/vmware-integrated-openstack-first-look/

It is quite an exhaustive list, and it can save a lot time especially when you have to fill the IP range.

JPham vSphere Web Client 2

Managing the VIO OpenStack Management Cluster

Depending on the business demand, you can scale-up and scale-down your Nova Compute or other storage configurations from your actual setup within the VMware Integrated OpenStack web interface.

You can:

  • Get the summary of OpenStack Services cluster
  • Add new Nova Compute
  • Add new Nova Storage
  • Add new Glance Storage resources
  • Eventually patch your OpenStack Cluster

JPham vSphere Web Client 3

 

High Availability (HA)/Disaster Recovery Services (DRS) Rules

VMware has designed an OpenStack architecture in high availability mode, but does it integrate with the vSphere HA or DRS? In this example, during the OpenStack services cluster deployment, DRS rules get created to ensure the same OpenStack Service virtual machines are not hosted on the same VMware ESXi host.

JPham vSphere Web Client 4

 

Once configured, the things you need to remember are:

  1. DevOps will provision daily virtual machine workload. You need to make sure you have some controls, monitoring and alarms set on the vSphere infrastructure to prevent any massive production disruption, e.g., a case where a virtual machine provisioning script keeps running in a loop … and might impact the full vSphere environment.
  2. Maintenance. For application awareness, you need to go through the vSphere VMware Integrated web plugin and shut down the cluster from there, not from the vSphere web virtual machine inventory, as it has no application dependency awareness.
  3. We are providing a validated VIO architecture. If you are customizing OpenStack services virtual machines manually, I would suggest backing up the virtual machines and calling support if needed to validate it – as with any future upgrade, your configuration might be overwritten and not persistent.

Julienne Pham is a Technical Solution Architect for the Professional Services Engineering team. She is specialised on SRM and core storage. Her focus is on VIO and BCDR space.

Simple VDI Load Testing with View Planner

Jack McMichaelBy Jack McMichael, Solutions Consultant

In the last few years it seems the number of customers asking for assistance in re-evaluating their “VDI 1.0” infrastructure is increasing at a faster rate than ever. It makes sense when you consider that in the rush to achieve datacenter consolidation many administrators were under pressure to just “make it happen.” Many of those administrators and architects didn’t have time to design their virtual desktop infrastructure (VDI) solution to scale and accommodate things our customers and users have grown accustomed to using every day, such as YouTube HD, Skype, and other resource-intensive applications.

Last year, VMware released their very popular internal tool View Planner for use to the general public for free. While it’s flown under the radar for a lot of customers, it can be an invaluable tool for judging where your VDI solution stands, and identifying where the stress cracks in your VDI infrastructure may be forming—or are already wide open.

The View Planner appliance is simple to install and fairly straightforward to set up for local tests. It’s capable of local-only load testing, as well as passive/remote connections with the VMware Horizon® Client.

Deploying View Planner

After deploying an Open Virtual Appliance in VMware vSphere®, configure your View Planner integrations in the Config tab of the administrator page. The AD and View integrations are optional, but can be used if you wish View Planner to deploy desktops and/or create and delete users.

Note that for best results, I recommend using IP addresses instead of hostnames. Create a service account for your credentials, and give it administrator privileges in both AD and in VMware vCenter™.

In this screenshot, you can see all three connectors configured. You can use the Test buttons to ensure the configuration works, but click Save first.

JMcMichael 1

Environment Preparation

For my simple test, I created a linked clone pool with the name VPDesktop-{n:fixed=3} in VMware Horizon View™. On this master snapshot, I added the View Planner Desktop Agent that you can download from the View Planner portal on the Packages tab.

Make sure you reboot your desktop before creating your snapshot. Once you reboot, you will likely see the desktop auto-login. If so, run the View Planner Agent as seen in this screenshot.

JMcMichael 2

 

Configuring Run Profiles

There are three test modes available: Local, Passive and Remote. Typically, Local mode will be used for load testing since it doesn’t require actual Horizon Client connections, but has the disadvantage of not replicating PCoIP performance impact. Passive mode will add PCoIP connections that are shared amongst client servers that host more than one client connection at a time. Remote mode will create a 1:1 relationship between clients and desktops, thus creating the most overall resource impact.

To configure a Run Profile for a simple load test, I recommend using Local as it doesn’t require the use of the Horizon Client, and is also easy to set up. Simply add the Workload profile you want to run into the Run Profile by clicking Add Group, and click Save to save the Run Profile. You can add multiple workload profiles if you desire, but for a simple test only one is required.

The most important thing to remember is that desktop names (and client names if you choose Passive or Remote) are case-sensitive. In this example, VPDesktop– is valid for VPDesktop-001, but not vpdesktop-001 or VPDesktop001.

JMcMichael 3

Running a Test

Simply click the Run button to start a test. If you run into trouble, View Planner will show you right away; by clicking the link on the appropriate box, you’ll see the exact error or success message.

JMcMichael 4

 

Once completed, you can view the results in the Per Stats column; they will look something like the example below.

JMcMichael 5

Summary

Overall, I found the View Planner tool to be great for simple and quick tests of a VDI environment. It shows you where resource contention exists, or singles out how an app may be creating resource gaps in your VMware ESXi™ hosts. The free downloadable version includes several standard templates that cover a variety of normal user application workloads. If you require more flexibility in your tests, a paid VMware Professional Services engagement offers a more feature-rich version to create customizable workload profiles and other goodies. Contact VMware Professional Services or a VMware Partner for an on-site evaluation.

 


Jack McMichael is a Solutions Consultant for the VMware Professional Services Engineering Global Technical and Professional Services team. Follow him on Twitter @jackwmc4 !

So You Virtualized Your Desktop Environment. Now what?

mmarx.phpBy Mike Marx

Most of my customers start with a low-risk user group consisting of a large number of users with identical application requirements. This is the common scenario when starting out on the virtual desktop infrastructure (VDI) journey and ‘testing the waters.’ With proper design efforts, initial implementations are highly successful.

I spend the majority of my consulting effort working with customers helping them create their initial VDI design. Designs can be simple or complicated, but they all utilize a common technical approach for success: understanding user requirements, and calculating infrastructure sizing. But I’m not blogging about technical calculations or infrastructure sizing. Instead I would like to address a VDI design challenge customers face as they expand their VDI design: user application assignments.

While resource requirements are simple to assess, calculate and scale, application delivery becomes increasingly challenging as more users are added to the design. VDI administrators struggle to manage increasing numbers of desktop users – each having unique application requirements.

Applications are easy to add to a large static group of user desktops using linked-clones. But when unique user groups are introduced, and application requirements change, administrators are confronted with the challenge of maintaining a large number of small desktop pools – or impacting large groups of users in order to change an application assignment.

So how do we design an effective stateless desktop and maintain application diversity amongst unique user groups? VMware Horizon AppVolumes is the answer.

Using AppVolumes, VDI designs become simple to understand and implement. Once applications are effectively removed from the VDI desktop, VDI administrators are left with a simple stateless desktop. But users aren’t productive with an empty desktop operating system; they need applications – and lots of them.

Without going into deep technical detail (there are excellent blogs on this topic already) AppVolumes captures the application files, folders and registry components, and encapsulates them into a transportable virtual disk called an AppStack. As the user logs on to a stateless desktop, the assigned AppStack(s) will automatically attach and merge the user’s applications with the desktop virtual machine.

Now users are presented with a stateless desktop that is uniquely assembled with all of their applications. AppVolumes’ attached applications interact with other applications— and the operating system—as if they were natively installed, so the user experience is seamless.

Now that applications are no longer an impediment to VDI designs, VDI administrators are able to support large groups of users and application requirements using the same stateless desktop pool. By following the KISS principle: “Keep It Simply Stateless,” AppVolumes will open the door to new design possibilities and wider adoption by users and IT administrators.


Mike Marx is a Consulting Architect with the End User Computing group at VMware. He has been an active consultant using VMware technologies since 2005.  His certifications include : VCAP-DTD, VCP-DT, VCA-WM, VCA-DT, VCP2-5 as well as being an expert in VMware View, Thinapp, vSphere and SRM.

App Volumes: Storage Migration for AppStacks

Jeremy WheelerBy Jeremy Wheeler

Inside of App Volumes you can accomplish a storage migration between different SANs using the feature called ‘Storage Groups,’ provided you have shared storage between App Volume Managers. If you don’t, I recommend creating a temporary LUN/Volume to accomplish this migration. If you are performing a migration on a large scale, such as 2X or more App Volume Manager instances, you will need to perform steps one through eight on each App Volume Manager instance.

Conceptual architecture:

JWheeler AppVolumes Manager Conceptual Architecture

 

To achieve a successful migration we will need to utilize a shared LUN/Volume between datastores. This can be an NFS or iSCSI datastore and will only be used temporarily to complete this process.

JWheeler AppVolumes Migration Setup

Stage 1: Migration Startup

  1. Select ‘Infrastructure’
  2. Select ‘Storage Groups’
  3. Give your storage group a name (my example: migration_temp)
  4. Check ‘Automatically Replicate AppStacks’ and leave ‘Automatically Import AppStacks’ unchecked. If you check the ‘Import AppStacks’ checkbox, you will need to do a lot of cleanup if you were using a temporary LUN to do this migration.
  5. Select ‘spread’ for your distribution strategy.
  6. Select your preferred template storage.
  7. Select ‘direct’ for storage selection.
  8. Select the checkbox of your local shared storage. This field will represent where you currently have the AppStacks you want migrated.
  9. Select the checkbox of your Temporary LUN. The temporary LUN is assumed empty or the AppStacks you want migrated over are not on the temporary LUN.
  10. Select ‘Create’ 

Once your storage group is created replication will begin immediately; it might take awhile depending on how many AppStacks you need to distribute within the storage group.

Stage 2: Cleanup

  1. After all AppStacks have been evenly distributed in the storage group, you can simply delete the storage group. This will not delete any AppStacks – it simply disassociates the logical bucket of resources. Both the source LUN and temporary LUN will still have the AppStacks.

Load the VMware vSphere® client and move any AppStacks from the temporary LUN to the permanent shared storage LUN, and then to the View Block.

JWheeler AppVolumes View Block

I want to dig further into explaining this process about moving AppStacks from the temporary LUN. App Volumes create pointers to all AppStacks residing on storage. This means in our example (shown above) when we replicate an AppStack between two points the inventory object in App Volumes Manager will consider all these locations as the AppStack living space. This also means that if you decide to delete an AppStack from inventory, ALL pointer locations will also be deleted. So, if you need to clean up the App Volumes Manager inventory in your Source Environment, you will need to copy, move, or detach the temporary LUN you created prior to deletion. The process for doing that is explained here.

JWheeler AppVolumes

a)      Move AppStacks from cloudvolumes/apps/* to a temporary folder /cloudvolumes/apps/tmp/* using the vSphere C# client, GUI, or vSphere command-line.
b)      Delete AppStacks from Source inventory.
c)      Move AppStacks from cloudvolumes/apps/tmp/* to a permanent shared storage in the target environment folder /cloudvolumes/apps/* using the vSphere C# client, GUI, or vSphere command-line.
d)      Select ‘Import AppStacks’ in App Volume Manager under Volumes > AppStacks.
e)      Select the LUN you moved all the AppStacks into (step c).
f)       Set the root path of where the AppStacks will live and select ‘Import.’

You can also use ‘vmkfstools’ if you have shell access to a host that can see the shared storage. This process is a lot more manual compared to using App Volumes Storage Groups, but you can still accomplish the migration using this method.

Execute the following syntax:

vmkfstools -i </source/location> </dest/location> 

This will copy the VMDK file in its current format from source to target.
(AppStacks VMDKs are Thin Provisioned by default).

Once you have copied the AppStacks you will need to ‘Import AppStacks’ from the App Volume Manager
(Volumes –> AppStacks –> Import AppStacks).

Reference this Knowledge Base for additional information when using the vmkfstools command:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028042

For more information, be sure to check out the following Education Course:


Jeremy Wheeler is an experienced senior consultant and architect for VMware’s Professional Services Organization, End-user Computing specializing in VMware Horizon Suite product-line and vRealize products such as vROps, and Log Insight Manager. Jeremy has over 18 years of experience in the IT industry. In addition to his past experience, Jeremy has a passion for technology and thrives on educating customers. Jeremy has 7 years of hands-¬‐on virtualization experience deploying full-life cycle solutions using VMware, CITRIX, and Hyper-V. Jeremy also has 16 years of experience in computer programming in various languages ranging from basic scripting to C, C++, PERL, .NET, SQL, and PowerShell.

Jeremy Wheeler has received acclaim from several clients for his in-¬‐depth and varied technical experience and exceptional hands-on customer satisfaction skills. In February 2013, Jeremy also received VMware’s Spotlight award for his outstanding persistence and dedication to customers and was nominated again in October of 2013