VMware View-vCenter Heartbeat; Basics

VMware vCenter Server is VMware’s management tool for ESX/vSphere hosts and VM’s and it’s configuration and health status. This tool is becoming important more and more: DRS, VMotion, HA and other management tasks rely on this server.

The importance is becoming higher when it is managing a VMware View environment. vCenter is controlling the provisioning and power settings for example. Without vCenter, no virtual desktops are provisioned, deleted, shut down and started for example. Running desktops with users working on them will continue to work though.

vCenter Heartbeat is a product which helps to protect vCenter Server. VMware OEM’s this product from the Neverfail Group. It protects the following;

-vCenter Server/database application failure, network failure, host failure.

vCenter Heartbeat is a mechanism which is based on a “shared nothing” pair of servers. This could be a pair of 2 servers with vCenter+database locally or 2x pairs of server where vCenter and the database are separated.

The pair can be a physical-physical/Physical-virtual/virtual-virtual pair of servers. In case of a virtual-virtual, you can simply clone the primary server to get your secondary.

After the setup of the pair(s) of servers, data from the primary server is replicated asynchronously to the secondary so (both) pair(s) contain the same data. Also, vCenter and the database services are being monitored for performance and other issues that may impact availability. A separate network, “heartbeat channel”, is used to maintain a heartbeat between the 2 servers allowing the secondary server to detect a failure.

On the secondary site, the vCenter/database are in a stopped state and hidden from the network through an IP packet filter. This because the pairs are identical (name and IP wise).

In a case of a host, application or service failure, a failover will happen and the secondary server will become the primary automatically. After ‘repairing” the failed server you can manually failover again so the “now secondary” will become the primary again.

vCenter Heartbeat is based on Neverfail technology but is dedicated to VMware. It is a “hidden” product but worth looking at. A lot of good information can be found;

Product page; http://www.vmware.com/products/vcenter-server-heartbeat/

Download page; http://downloads.vmware.com/d/info/datacenter_downloads/vmware_vcenter_server_heartbeat/5_5

Documentation page; http://www.vmware.com/support/pubs/heartbeat_pubs.html

Quick Start; http://www.vmware.com/pdf/heartbeat_55_u2_quick_start.pdf

Community page; http://communities.vmware.com/community/vmtn/mgmt/heartbeat

VMware View-Thin Clients; DevonIT VDI Blaster

A couple of months ago I had the opportunity to get a DevonIT VDI Blaster 1.1 NFR (build 10.01.27). Because of my schedule I didn’t do much with it until last friday. I remembered I had downloaded the software so I wanted to play around with it.

VDI Blaster appealed to me; a piece of software which can turn your “old” fat clients into thin clients. All secure, lean and mean and it supports View4 and PCoIP!

First thing I saw was I downloaded 3 pieces of software and the manual. The manual can be downloaded here. The 3 software components are;

1. vdi-blaster wininstaller.exe: You use this piece when you have Windows XP (32 bit) clients you want to repurpose and turn them into thin clients. It sets up a dual boot so the original XP instance with all its data are preserved. I do have my doubts if customers want to do this; preserve the XP installation. What I’m seeing when customers are switching to a VDI solution is that everything is put into the virtual desktop and removed from the end point. A plus is the customer can revoke a XP license. There are probably cases where it is necessary to have a local XP installed although the user needs to reboot and switch to the XP install to use it. Because it is a dual boot, you can only use either XP or VDI Blaster.

2. vdi-blaster hdinstall.iso: with this .iso you can install VDI Blaster on a end point’s hard drive. This will delete the OS and data which were originally on the end point (and saves a Windows XP license). In my opinion the way to go but on page 6 of the manual I see this feature is experimental. So keep that in mind. I haven’t used this because I don’t have enough equipment to do so.

3. vdi-blaster livecd.iso: also experimental. With this .iso you can create a bootable USB key with the VDI Blaster running on it. You can create your portable View Client. I think this is a cool feature! It is a nice gadget. In the manual it mentions “Unetbootin”. You have to download Unetbootin and run it on your machine. Attach a USB key, browse for the livecd .iso and run it. This will make your USB key bootable with the VDI Blaster software. Very easy! I’m not sure if customers will use this in production though. First of all VMware has an experimental feature called Offline VDI where you can download the VM to your access device and work offline. With VDI Blaster you always have to work remotely as long as you can connect to your data center (and sometimes you won’t have a connection to the internet) and this is where I have issues: See below my experiences.

My experiences so far:

In my house everything is connected wireless. My router is downstairs in the garage. I use a Lenovo X60 for testing and demo purposes. When i boot my X60 into the VDI Blaster GUI, (dual boot with vdi-blaster wininstaller.exe) it won’t get an IP address. When i plug in a cable, it is working fine. Apparently VDI Blaster doesn’t support my WLAN card (and won’t support all WLAN cards). For the record, I’m not a linux guru. VDI Blaster is based on linux. I bet people can get t to work but I look at products from a “simple user” point of view. Also, the VDI Blaster has a Cisco compatible VPN Client which supports a limited amount of devices. See page 26 of the manual. When I fill in the VPN information for our demo environment, I don’t see how I can make a VPN connection. I haven’t seen this part in the manual and I don’t see it in the GUI. So far, I haven’t been able to set up a VPN (PPTP) connection to VMware’s demo environment in The Netherlands.

Another thing, rather minor though, is the manual. It covers the basics and nothing more:

-As stated before it does mention Unetbootin but that’s it. I used Google to find out what to do,

-Also, the VPN isn’t documented well. Yes i can set VPN credentials… but then what? Still haven’t figured it out, maybe I’m missing something,

-The manual says, on page 16, that the default behavior of the thin client is it is persistent. All changes made, like creating a VMware View connection, will be saved. On page 18, it says your new installed thin client is a stateless, non persistent thin client. Hmm! Ok, test: create a View connection and reboot: Gone, so page 18 is right. It is a stateless thin client. To make the thin clients persistent you will need the management server. You can download the manual and software from here. I will download and convert it to my vSphere environment.

I’m still curious and interested in DevonIT’s VDI Blaster though, don’t get me wrong. The wininstall wouldn’t be my option to use but that’s not up to me. I like the hdinstall and livecd options. Like i said before, I’m not a guru on linux. Comment on this post if I’m missing something.

VMware ThinApp; ThinApp- Basics

Application virtualization helps you to separate the applications from the underlying OS which brings you a lot of benefits. VMware has a product called ThinApp which you can use to virtualize your applications.

I believe that ThinApp will get a huge boost now VDI/VMware View is very popular and more and more customers are implementing a virtual desktop environment. Both ThinApp and VMware View are very complementary and it makes sense to use them both; separate apps and OS, avoid conflicts between 2 applications, manage and maintain OS and applications independently. Also, save on storage. With ThinApp you can virtualize for example Office and provide it to users instead of installing Office inside every VM. For the record, ThinApp absolutely works in a physical environment as well.

Now, what is ThinApp?

Basically, VMware ThinApp makes it possible to run an application inside a “bubble” in stead of installing it locally. Because it is running inside a “bubble”, the application won’t “touch” your OS. When you run the application, you don’t have to install it first so this application won’t modify your system.

Inside the “bubble” there is a very small Virtual Operation System (VOS), Virtual Registry (VR) and Virtual File System (VFS). Everything the application does will be handled by the VOS, VR and VFS. It will intercept file and system calls. A “sandbox” is a place where the virtual app writes to. This can be settings like favorites in Mozilla Firefox. This to saves changes and make the life of a user easier.

When you “ThinApp” an application (which needs to be a Windows application), you will create a single file MSI or EXE file. The EXE or MSI is a choice you make during the packaging. You can copy/distribute this file and run it from almost any device; a share, USB, flash, Windows desktop but also publish it on a Terminal Server or Citrix Server.

When you put the package/EXE on a share and give users access to it, all your users can start an application from 1 file. When residing on a share, the packaged will be streamed to the (virtual) desktops. For offline users (experimental feature in View) you need to copy the file to the VM’s so the user can start the application when he/she is offline. In these cases, most times, you will use the MSI option. With this option, it looks like the application gets installed when starting it. It isn’t though. It will register itself inside the OS; you will see it in the start menu, add/remove programs and file association is established. File association means that the OS “knows” when you, for example, click on a PDF file, it needs to start the ThinApp version of Acrobat Reader.

Encapsulation and isolation are, again, the 2 magic words; the application is inside 1 package and isolated from the environment, other applications. Because of this you can run 2 versions of the same application together on the same system which in the traditional world wouldn’t be possible because off DLL issues.

Because ThinApp makes an application run inside a “bubble” (and is isolated) it won’t see other bubbles. This is perfect because this way you avoid conflicts between “bubbles”. On the other hand, what if 2 “bubbles” need to communicate with each other? Luckily there is a mechanism to make that happen; AppLink. With AppLink, which is a setting in your application package, you can let  “bubbles” communicate with each other.

A lot of information about ThinApp can be found on VMware.com. There is also a very active community where you can find a lot information about different kinds of applications and ThinApp.

When you want to try ThinApp packages, you can go to thindownload.com. Here you will find open license application which are virtualized with ThinApp.

VMware; VMware Toolbar

Today i received an internal email which is quite interesting; a VMware toolbar which gives you instant access to tools from VMware:

  • Instant access to patches, documentation, and more.
  • Built-in RSS and Twitter updates direct from Support.
  • Live peer to peer chat lets you ask for help from other VMware experts and staff. (the chats are pretty interesting to watch)
  • Custom search capabilities.
  • Works on IE, Firefox, Safari.
  • No spyware; secure, safe, and private.

Woohoo, Safari! I just downloaded and installed the toolbar. Pretty cool. it’s available for everyone: http://vmwaresupport.toolbar.fm/

Enjoy!

VMware View-Template; Novell Client/Zen Agent and SSO

I still get questions about how to get Single Sign On to work with VM’s with a Novell Client installed on them. There are a lot of Novell environments out there so I’m glad VMware documented this.

One of the requirements for View is Active Directory. When Novell eDirectory is your primary Directory service you first need to think about how to migrate the NDS information to AD. The View Manager authenticates against AD.

Single Sign On with the Novell Client inside the VM is possible.

Hereby the official VMware KB on VMware View and Novell Client based VM’s: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010521

Below you will find a description I made with a customer a while ago how to get SSO and the Zen Agent to work with VMware View;

On the Access device:

At least XP SP2 because of the mstsc patch:

Mstsc.exe version 6.0.6000.16386

Or XP SP3 with the mstsc 6.0.6001

In the VM:

XP SP2 or SP3

Install Novell Client 4.91 SP5 (custom, no NMAS) and reboot.

Install the Zen Agent and reboot.

Properties Novell Client:

Configure LDAP contextless login.

Make sure to add the tree in the Default Location Profile.

Make sure to disable NMAS authentication (Advanced login tab)

Make sure the Tree and Server are added on the Client tab

Install the VMware View Agent with SSO.

Check Gina chain in the registry for booting the View session;

1.       HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

i.      “GinaDLL”=C:\\Program Files\\VMware\\VMware View\\Agent\\bin\\wsgina.dll

ii.      “VdmGinaChainDLL”=NWGINA.DLL

  1. Add the following registry keys to:
    1. HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login

i.      DefaultLocationProfile=Default (REG_SZ)

ii.      TSClientAutoAdminLogon=1 (REG_SZ)

Fill your Remote desktop Users Group with users. Zen policies and Nal should be working now together with SSO with Novell.

VMware View4-Templates; PCoIP Install and Configure

VMware has heard about screen re-sizing issues when using the PCoIP protocol. Same goes for me. I have heard about this on vSphere and VI3 platforms with View4. Symptoms are;

You cannot resize the screen,it doesn’t resize automatically, resizing only works down instead of up etc.

In February 2010 a VMware KB came out around this; KB1018158, This KB describes How to prepare your template for using the PCoIP protocol.

I will copy paste the whole KB and afterwards tell you about my experiences and things to keep in mind. So far this has been working fine on vSphere and VI3, 3.5 with XP.

To ensure that a pool has all of the correct PCoIP functionality:

  1. Install View 4 on a supported platform (VMware vSphere 4 or VMware Infrastructure 3.5 Update 3 or 4).
  2. Create a Windows XP, Windows Vista, or Windows 7 virtual machine.
  3. Ensure that VMware Tools is installed, then install the View Agent, then the .NET framework.Note: The order is important. If you install any of these applications in the wrong order, or if you do not know the order in which they were installed, uninstall all 3, then reinstall in the correct order.
  4. In View Manager, set this desktop up as an individual desktop and entitle it.
  5. Ensure that you have the PCoIP settings for monitor and max resolution set the way you want them in the pool.
  6. Log in once and ensure that the basics work.
  7. If PCoIP or screen resizing is not already working, logout of the desktop and use the Reset option from inside of View Manager.Note: Do not reboot by clicking ShutdownRestart in the virtual machine. PCoIP is dependent upon the appropriate amount of video memory being allocated to the virtual machine. Since this is a virtual hardware setting (that needs to be in place before the virtual machine starts up), it is applied as a change in the .vmx file. If the virtual machine has already been started, it is essential that this virtual machine be restarted so that the .vmx file is re-read and the changes are used. Using Shutdown >Restart option inside the virtual machine does not force the .vmx to be re-read, as this does not cold boot the machine (from the VirtualCenter perspective) to refresh the virtual hardware. Using theShutdown Restart option from either VirtualCenter or View Manager (which issues the command via VirtualCenter) is the best way to make sure this file gets read properly.
  8. Log in again and make sure screen resizing works.
  9. Shutdown the virtual machine.
  10. Take a Snapshot.
  11. Remove the individual virtual machine assignment from View Manager.Note: If you do not perform this step, the virtual machine does not show up as an available parent in the pool creation process.
  12. Create your pool. It should work as expected.Note: When the appropriate video memory settings are in place for the parent virtual machine, you can create a pool based on this virtual machine and machines in that pool properly inherit the .vmx settings on first boot.

I have to say, I always do follow this KB until point 3. The most important part is the order of installation of VMware Tools, View Agents and .Net. Follow that order for sure. After that, I edit the VM’s properties in vCenter and change the properties of the virtual Video card; by default it is set to 4MB of RAM and I manually set it to 128MB. In vSphere this is very easy to do through the vCenter Client. In VI3, 3.5 you will have to manually change it in the .vmx file.

Keep in mind though, till vSphere 4 Update 1 you can’t set the Video card RAM to anything above 30MB. You could but VMotion of the VM’s will fail when the vRAM is over 30MB: KB1011971.

After the vRAM has been changed to 128MB and I use this VM to roll out a pool (Full or Linked Clone), when I’m using the View Manager to add a pool, I always set the Display Settings to 4 monitors and the maximum resolution of 2560×1600. Screen resizing works every time.

VMware View-ThinPrint; Basics

ThinPrint’s .print solution has been OEM-ed by VMware for it’s View solution since View3. It isn’t a part of View people talk about but it does bring benefits. I would like to write a short summary on ThinPrint inside VMware View.

When you install the VMware View Client and Agent, you install the ThinPrint .print solution at the same time. All components are inside the Agent and Client. What this basically offers a customer is a drive free print solution. You don’t need to install and manage print drivers inside virtual machines. It also compresses print jobs which saves you a lot of bandwidth usage.

There are 2 components involved here; the .print Engine and Client:

1 .print Engine; This part will be installed inside the VM as part of the View Agent. This Engine consists of 3 part;

a. ThinPrint AutoConnect; this part communicates the the .print Client and creates the users session printers. So it makes the users printers visible/available inside the VM. This process will query the .print Client every 30 seconds for changes.

b. ThinPrint Output Gateway; this is the generic printer driver for 32- and 64-bit Windows systems. Microsoft defined a standard for exchanging data between applications and the print spooler;EnhancedMetaFile. TPOG based printers provide the following properties; resolution, paper tray, paper format and duplex. Enhanced properties like stapling are not defined by Microsoft. You won’t be able to use those features with ThinPrint.

c. ThinPrint port monitor; this is the part which is responsible for the actual transfer of print data. It is also responsible for compression. it can use RDP and PCoIP for example. It also controls the bandwidth dynamically.

2 .print Client; This part will be installed on the access device as part of the View Client. The .print Client provides information about installed printer, local printer properties and users default printers. It receives compressed print data from the .print Engine. The .print Client “sees” the available printers for the user and will communicate these printers to the AutoConnect Service of the .print Engine.

Last, when a user prints something, the application will interact with the ThinPrint Output Gateway driver to generate the EnhancedMetaFile Data. Data is being processed and transferred by the ThinPrint port monitor and put back into the local print system by the .print Client.

Links:

http://www.thinprint.com/LinkClick.aspx?fileticket=nq7dClKgMBM%3d&tabid=982

VMware View-Anti Virus; Trend Micro’s beta of OfficeScan

I received an email a couple of days ago from 1 of my contacts within Trend Micro. He told me Trend is working on a new version of OfficeScan which is taking into account the desktop environment is virtualized.

As most of you know Anti Virus in a VDI environment could lead to performance issues (high resource usages on Hypervisor servers and high disk I/O’s). Especially full scans and the update of the virus definition files could be bottlenecks.

“Serialization” of scans and updates on an ESX/vSphere server base is Trend’s answer;

Full System Scans

During a full system scan, the entire file system is scanned for malware. This introduces a notable amount of load on any individual system. Typically, full system scans are scheduled by the administrator to take place at a certain time (e.g. 3PM on Thursdays). If several—or all—virtualized desktops start a full scan at the same time, the underlying shared hardware of the VDI server will experience extreme load, causing a slow- down of all virtual systems on the server. To ensure smooth operation and normal load on the host system, a VDI-aware endpoint security solution must serialize full scans for systems on the same VDI host.

Component Updates

Larger client updates present many of the same challenges and must be treated in a similar fashion to system scans. Pushing out a major update to multiple virtualized desktops at the same time can saturate the host’s network connection and introduce high I/O load on the host. This can seriously impact the performance impact on the virtual desktops that are running at that time. This load balancing must also be addressed with VDI-aware endpoint security.

III. HOW TREND MICRO CAN HELP

SERIALIZATION OF FULL SYSTEM SCANS PER VDI-SERVER

OfficeScan will allow only a given number of virtualized endpoints to perform a full system scan at the same time. With this serialized approach, the overall impact on performance is low, yet all systems will be scanned—one after the other.

SERIALIZATION OF CLIENT UPDATES PER VDI-SERVER

Similar to the serialization of full scans, OfficeScan management will only update a configurable number of virtualized desktops per VDI server at the same time.

PRE-SCANNING AND WHITELISTING OF BASE IMAGES

Most virtual desktops will be created using the same base image. Administrators can pre-scan and whitelist the elements of that base image. The result is that in each instance of virtual desktop, OfficeScan will only scan for deviations from the base image. This eliminates most extraneous scanning, resulting in much shorter scan times which ultimately contribute to lower performance impact and increased productivity.

INTEGRATION WITH VDI MANAGEMENT

The next release of OfficeScan will integrate with VDI management to retrieve information about the status and location of secured virtual desktops. This will help optimize resource utilization across the entire virtual desktop environment.

I’m curious about this new version and will test it asap. Below you will find a link to the beta software and I have attached Trend Micro’s White Paper.

Beta Software: https://www.trendbeta.com/index.php?get=357&content=562

Trend Micro White Paper: OfficeScan Beta WP