Announcing the App Volumes Backup Fling

It gives me great pleasure to announce the first Fling that I have worked on.

Over the last couple months Chris Halstead, Stephane Asselin and I have been working on the new App Volumes Backup Fling.

Picture1

This tool will help customers to backup their AppStacks and Writable Volumes VMDK files using their standard backup tools, normally backup tools do not see these files as they are not seen with in the vCenter inventory unless they are connected to a users virtual desktop.

Below you will find a number of links where you can find more information about the App Volumes Backup Fling.

Fling Download

App Volumes Back Fling

Video Demo

You can also see the full announcement on VMware.com here

For instructions on how to use the Fling see the blog here

Please feel free to leave any feedback for Chris, Stephane and I and any features you would like to see added.

Veeam NFC Storage Connection is Unavailable

I am currently doing some testing in my lab around backing up App Volumes, more to come on this in the new year, and I needed a backup solution to do my testing. I decided to use Veeam Backup and Replicate 8 as being a vExpert I get a free 1 year NFR license to use the product. Thanks Veeam for this benefit.

The product was easy to setup but when I came to make my first back I kept getting the following error.

NFC Storage Connection is Unavailable

After a couple of google searches I found the following KB article here. Having read through the article I started to look at the log files. The log files can be found on the Veeam server is this location.

%ProgramData%\Veeam\Backup\Backup_Job_Name

After looking at the logs I didn’t have any of the issues mentioned in the KB article but I did notice the following errors.

ERR |Failed to initiate NFC session. Target host: [10.0.1.200]. VI connection ID: [vcenter.delboyshome.com]. Storage MOID: [200-Local].

[22.12.2015 20:04:44] <  1592>      ERR |SSL error, code: [336151568].error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

[22.12.2015 20:04:44] <  1592>      >>  |SSL_connect() function call has failed.

[22.12.2015 20:04:44] <  1592>      >>  |Failed to establish connection with the SSL server.

[22.12.2015 20:04:44] <  1592>      >>  |Cannot initialize new SSL connection.

[22.12.2015 20:04:44] <  1592>      >>  |Authd handshake has failed.

[22.12.2015 20:04:44] <  1592>      >>  |NFC session with the specified ticket [52 fc d5 d8 27 e2 4a 73-57 79 e2 13 85 b7 60 e8] is unavailable. Target host: [10.0.1.200].

[22.12.2015 20:04:44] <  1592>      >>  |Cannot connect to NFC session. Target host: [10.0.1.200]. Storage: [200-Local]. VI SOAP connection ID: [vcenter].

After some more goggling around I found that in ESXi 6.0U1 SSLv3 is now disabled by default and would need to be re-enabled, on all of my hosts, or at least on the host doing the backup specifically, SSLv3 would need re-enabling for post 902.

Thankfully the issue and easily be fixed. To fix the issue you can follow the simple steps in this KB from VMware found here.

 

 

 

VMware App Volumes Storage Group Improvements with 2.10

Several months ago I wrote a blog post on how VMware App Volumes can be deployed in a multi-site deployment. You can find the blog here.

With the release of App Volumes 2.10, for more information on the release see the information here, there has been a great improvement of the way App Volumes handles Storage replication. In this Blog I will explain how the new storage replication works and how to configure your storage groups to take advantage of this improved feature.

The main change that has happened when when looking at configuring storage groups and datastore’s is the ability to make datastore’s non-attaching. What does this mean, well basically a non-attaching datastore would be a place to create AppStacks but those AppStacks would never be attached to a desktop from this datastore.

The non-attached datastore would then be a member of a storage group or a number of storage groups. These storage groups would then replicate the AppStacks from the non-attached storage to all the other datastore’s with in the storage group.

Picture8

Now how will this look when deploying App Volumes to multiple sites here is a high level architecture of how this could be deployed. As you can see from this diagram at least 1 vCenter from each site will need access to the non-attached datastore.

Picture9

How to create the New Storage Group

First create the non attachable storage

With in the App Volumes Manager click on Infrastructure, Storage then select the storage to be non-attachable then click Make As Non Attachable.

Picture3

Now create a Storage group

With in the App Volumes Manager click on Infrastructure, Storage Groups then click Create Storage Group

Picture4

Give the storage Group a Name. Then select the required options. When choosing the datastore’s make sure to include the datastore’s that will be used to attach the AppStacks from as well as the non-attachable datastore. Click Create.

Picture5

 

As you can see from the image below I have created 2 Storage Groups one for each site and the Non-Attached storage, NFS2, is included in each Storage Group.

Picture10

 

Now all you need to do is create AppStacks on the non-attachable storage and they will automatically be copied to all the other datastores in the storage groups.

Is ThinApp Dead?

Screen Shot 2015-08-25 at 8.48.52 AMNow that VMware App Volumes is live and a number of customers have deployed App Volumes or are thinking of deploying App Volumes, one of the questions that I constantly get asked is, “is ThinApp Dead?” Or “is App Volumes replacing ThinApp?”

Well I want to say this once and for all that ThinApp is not dead and App Volumes is not replacing ThinApp.

ThinApp still has a purpose in the EUC stack and is still the leader in Application Virtualization. In fact, App Volumes and ThinApp can work together happily and App Volumes is a great tool for delivering ThinApped applications to the End User.

App Volumes makes it very easy to deliver your ThinApp application quickly and instantly to your End Users.

Another use case for App Volumes and ThinApp is to deliver your ThinApped applications to RDSH servers so that you can stream your ThinApped applications to your End User devices such as iOS and Android devices. This can even improve your XenApp environment.

App Volumes and ThinApp working together make it very easy to quickly spin up a RDSH host and publish applications through VMware Horizon View or through Citrix XenApp.

I hope that this quick post puts the question to bed for the foreseeable future.

As a ThinApp fan I am happy that there is still life in this great solution!!!

Storage Considerations with App Volumes

With the release of VMware App Volumes 2.6 VMware has added the ability to manage multiple copies of the same AppStack as a single AppStack with in the App Volumes Manager interface. Storage groups can be used to group datastores together, this way you can add an AppStack to a storage group and the App Volumes Manager will place the AppStack in the best place based on your Distribution Strategy. For Distribution Strategy you have 3 options:

  • Spread – Distribute files evenly across all the storage locations.
  • Spillover – Distribute files by filling each storage location before using the next one.
  • Round-robin – Distribute files by sequentially using the storage locations.

When a user logs in, the App Volumes Manager will manage the connection to the relevant AppStack. When the Spread option is chosen the App Volumes Manager will use Round-robin to connect users to the AppStack VMDK to spread the connections over the datastores.

This will make managing and assigning AppStacks to large numbers of users much easier for the App Volumes administrators.

The graphic below gives you a high level look at how this affects storage.

Featured image

Now the question that an architect needs to answer is how many VMDK’s will be needed to support a single AppStack with in the App Volumes manager. The table below is the recommended number of connections per VMDK depending on storage type.

Storage Type VMFS NFS Flash Storage
Recommended Maximum connections per VMDK 128 250 1000

Using this table it make the decisions basic math. The following equation can be used to figure out just how many VMDK’s will be needed per AppStack.

Number of users / Maximum connections per storage type = Number of VMDK’s needed or datastores

So if you were assigning an AppStack to 500 users in you organization and the storage type the AppStack VMDK’s is stored on is VMFS the calculation would be

500 (Users) / 128 (max connections per datastore) = 3.9

A single copy of the AppStack VMDK could then be placed on a datastore with in the Storage Group and the App Volumes Manager would replicate that VMDK to all the datastores with in the storage group.

Now the above calculation helps with number of users connecting to AppStack VMDK’s however you will also need to take in to consideration the number of IOPS needed for the software in the AppStack. For best performance this may mean you need more datastores to spread the load across more disks.

How to configure Storage Groups for AppStacks

The following will walk you through how to configure a storage group in App Volumes.

  1. Log in to your App Volumes Manager
  2. Click Infrastructure, Storage Groups, Create Storage Group

Featured image

  1. Give the Storage group a Name, then choose the options that are required, then click Create

Note: If there are already AppStacks on the storage that will be included in the storage group check the box Automatically Import AppStacks

Featured image

  1. Click Create

Featured image

Once the storage group is created any new AppStacks created on a datastore with in the storage group will be automatically copied to all the datastores with in the storage group.

Upgrading App Volumes Templates

Following on from my ealier blog about upgrading the App Volumes managers, found here, another key task is upgrading the App Volumes templates. These templates are always used when you create a new AppStack or Writable Volume.

To upgrade your App Volumes Templates simply follow these simple steps.

  1. Log into the App volumes manager
  2. Click Configuration and then Storage

Featured image

  1. Verify the storage locations listed and then press the “Upload Prepackaged Volumes” button.

Featured image

  1. Select the correct storage location where the templates are located, select a Host to copy the files and enter the correct user credentials. Select the correct templates to upload and click Upload.

Featured image

If you have created any custom templates then you should also update these at this time. You can read more about creating custom templates here

I would like to thank my good friend and colleague Stephane Asselin for contributing to this blog. To read more about Stephane please see his blog here