myvirtualcloud.net

In some circumstances where firewalls devices are are blocking VMware View traffic, or other network service is already making use of VMware View default network ports you may be required to change the ports in use. Another reason for a View port change would be when a organisation have a standard procedures to change default application’s port for security reasons .

Before starting, a quick note – Teradici has registered port 4172 with IANA and this is the official PCoIP port moving forward. So, from 50002 to 4172 (both TCP/UDP).

Modifying PCoIP Ports

PCoIP ports can be changed using the PCOIP.ADM templates provided with VMware View Connection Server or via a registry change at GuestOS level. If you need more information  please refer to View Administrator Guide.

Please note that ADM templates are technically not officially supported by VMware.

Modifying View Connection and Security Server Ports

VMware View 4.0 and 4.0.1 run on Apache Tomcat/6.0.20 and the default HTTP/HTTPS ports configured are as per default 80/443.

The HTTP/HTTPS listener is part of the sslgateway component, which also supports SSL tunnelling. To configure the listening port, create or edit the file %programfiles%\vmware\vmware view\server\sslgateway\conf\locked.properties

The “locked.properties” file needs to be created or copied to each connection or security server in your organisation. The contents of the file should reflect the following:
clientProtocol=https
clientHost=fqdn
clientPort=443
serverPort=80
serverProtocol=http

• clientProtocol=https—Indicates that the client will use HTTPS.
• clientHost=view-ext.ese.com—Indicates that the client will connect on the tunnel phase (second phase) to the DNS name that resolves to server.
• clientPort=443—Indicates the port the client will use to connect. This entry seems redundant because the clientProtocol field is already there, but the VMware documentation states that if this entry is not defined, the client will use whatever is defined in the serverProtocol field, which will be 80.
• serverPort=80—Indicates the port that will be used to connect to the Connection Server.
• serverProtocol=http—This entry is not needed because HTTP is the default, but is included here for clarity.

Add or edit “serverPort=xx”, where xx is the port number you’d like to use.

You will need to stop and restart the View Connection Server service (or reboot) in order to switch the listening port. And don’t forget to change any firewall rules appropriately.

Next you should look in the debug log for a line like this: “Server listening port: xx”, where xx is the currently configured listening port. Finally if you want HTTP address to be automatically redirected to HTTPS you need to add “httpRedirectURL=https://server:8181″ in the same file.

Modifying View Connection Ephemeral Ports

An ephemeral port is a short?lived endpoint that is created by the operating system when a program requests any available user port. The operating system selects the port number from a predefined range, typically between 1024 and 65535, and releases the port after the related TCP connection terminates.

You might want to increase the number of ephemeral ports if your View Manager deployment is likely to use more than 800 concurrent client connections; another reason to modify ephemeral ports would be to change the range restriction for a multi-site distributed environments where firewalls rules would have to be applied or revoked.

By default, you can create a maximum of approximately 4,000 ephemeral ports that run
concurrently on Windows Server 2003 but the VMware View Admin Guide 4.0 covers the subject in more detail and provides a formula to calculate the number of ephemeral ports.

To modify ephemeral ports you must open the registry and change on each of the VMware Connection or Security servers available in your environment.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value Name: MaxUserPort
Value Type: DWORD
Value data: 1024 + <calculated number of ephemeral ports>
Valid Range: 5000-65534 (decimal)

This week’s APAC Virtualization Roundtable features Duncan Cambridge, Senior Enterprise Management Solutions Specialist at VMware, and Darren Byrnes, director at Synergistex.

Together, the team will cover three products of the recently announced VMware vCenter Product Family and Enterprise Management Solutions that were incorporated to the portfolio as part of the EMC Ionix acquisition.

vCM – VMware vCenter Configuration Manager
vADM – VMware vCenter Application Discovery Manager
VMware Service Manager

The broadcast is LIVE via TALKSHOE.com.

You can participate via web accessing http://www.talkshoe.com/tc/75046.

Title: New VMware Management Stack – vCM & vADM & Service Manager
Start Time: Wed 28/7/2010 09:00 PM EST (Sydney Time)
Duration (minutes): 45”
Call ID: 75046

or click the link below

Other Time zones:
EDT (USA) – 7AM
PDT (USA) – 4AM
Perth (Australia) – 7PM
Hong Kong (Hong Kong) – 7PM
Kuala Lumpur (Malaysia) – 7PM
Tokyo (Japan) – 8PM
Auckland (New Zealand) – 11PM
London (UK) – 12 Noon

If you would like to listen pasts episodes click here or download from iTunes.

In a VDI environment each CPU cycle, megabyte of memory or disk IO that can be reduced may represent considerable performance improvement when the workload is characterized by hundreds or thousands of desktops. Disk alignment is a topic that has been discussed to exhaustion, but the use of the correct block/cluster size for your workload is something that will drastically improve your VDI disk IO performance.

Have you ever analysed your VDI IO length trend?
Your answer is most likely NO, but you should.

I will start the discussion saying that to obtain best performance from the IO stack, all storage layers must be properly aligned and they must use analogous cluster/block block size. There is a good article from Duncan Epping, and there you will find a comment from Vaughn Stewart.

Storage arrays from other vendors store data in other block, or chunk, sizes. Say your array stores data in a 64 KB block. In this configuration if the GOS partition is misaligned then should a VM make a 4KB read request we will read a 64KB block. As I’ve stated before most data reads aren’t that small, so let’s consider a 1MB read request. In this case the array would retrieve 1MB plus an additional 64KB block. In this case the overhead on the array is around 1%. So if we consider my premise that many non-busy VMs make requests in the 32KB to 128KB range the overhead with a misaligned 64KB block would be between 200% and 50%.

I have performed IO Length trending analysis on different VDI environments to understand how virtual desktops are issuing IOs. What I found is quite contradictory to what I have been reading. Some documentation, including VMware ones, mention that Windows XP uses 64kb block IO request in it’s majority, but that is not what I was able to observe.

Three different samples collected from Windows XP 32b using vSCSIStats tool had the majority of the IOs issued with 4kb length. That’s is not hard to understand as Microsoft’s The Default Cluster Size for the NTFS and FAT File Systems article make the following mention:

Drive size
   (logical volume)             Cluster size          Sectors
   ———————————————————-
     512 MB or less               512 bytes           1
     513 MB – 1,024 MB (1 GB)   1,024 bytes (1 KB)    2
   1,025 MB – 2,048 MB (2 GB)   2,048 bytes (2 KB)    4
   2,049 MB and larger          4,096 bytes (4 KB)    8

The results collected were as follows:

Disk alignment is important but the use of the correct block size for your VDI needs is essential to achieve the ultimate IO performance from your storage array. I recommend you to perform the IO Length trending analysis using vSCSIStats tool or the tunning tool provided by your array vendor to determine the best cluster size for your VDI workload.

The one size fits all doesn’t apply here and that is what most storage vendors will try to fit you in.

In my examples the majority of IO lengths are 4kb. If the array volume was created, let’s say, with 64kb blocks, each IO request will require the storage array to read an extra 60Kb to satisfy a 4kb request. Seems like a waste of reads/writes, doesn’t?

The good thing is that most arrays will allow you to specify volume block size during creation time based on the RAID type you are using.

Windows 7 might have a complete different set of IO lengths and that’s what I will sample next.

VMware released this week vSphere 4.1, a dot release packed with new features and improvements on key performance areas. How do all these new features and performance improvements will affect VMware View VDI infrastructures? Off course everything helps on the overall, but I decided to list and comments on those few improvements that will provide best benefits for VDI.

Transparent Memory Compression (TMC) – this new feature is particularly important when running several desktop VM on a single host – does that resemble VDI? The feature is a new overcommit technique that compresses on the fly the virtual pages that should be otherwise swapped on disk. Each virtual machine has a compression cache where vSphere can store compressed pages of 2KB or smaller size. TMC is enabled by default on ESX/ESXi 4.1 hosts but the administrator can define the compression cache limits or disable TMC completely.

On VDI environments, often bound by memory the results in a performance regain of 15% when there’s a fair amount of memory over-commitment and a regain of 25% in case of heavy over-commitment.

Storage I/O Control – This feature provides quality-of-service capabilities for storage I/O in the form of I/O shares and limits that are enforced across all virtual machines accessing a datastore, regardless of which host they are running on.

VDI environments are highly IO intensive and disk contention will be quickly perceived by users when interacting with their desktops. The ability to monitor and take automated actions over VMs under disk contention will definitely help to maintain VDI infrastructures running smoothly.

Scalable vMotion – vSphere 4.1 supports up to 8 concurrent virtual machines live migrations. The engine has been significantly reworked to reach a throughput of 8GB/sec on a 10GbE link, 3 times the performance scored in version 4.0.

In VDI infrastructures where workloads can drastically change according to users interactions and activities, the ability to offload hosts quicker is crucial to maintain a stable environment for users.

Distributed Resource Scheduler (DPM) – DPM now has a set of scheduled tasks to help control it, turning it on and off at certain times of the day if you’d like. Disabling DPM will bring all the hosts out of standby, to help guarantee that no hosts get stuck in a useless state.

On VMware View infrastructures this feature improvement will provide flexibility to set hosts to power off at night hours and automatically bring them online prior to business hours. That’s GreenIT!

Memory footprint reduction- The hostd footprint and memory consumption (down by 40%) has been greatly reduced, speeding up some operations by a factor of 3x. Less memory overhead equals to more VDI VMs per host, or more memory available to give to users.

vCenter Server 4.1 – vCenter 4.1 also introduces better performance when used in conjunction with VMware View. The creation of new virtual desktops now is 60% faster and their power on timing is 3.4 times faster.

• 3,000 virtual machines per cluster (compared to 1,280 in vSphere 4.0)
• 1,000 hosts per vCenter Server (compared to 300)
• 15,000 registered VMs per vCenter Server (compared to 4,500)
• 10,000 concurrently powered-on VMs per vCenter Server (compared to 3,000)
• 120 concurrent Virtual Infrastructure Clients per vCenter Server (compared to 30)
• 500 hosts per virtual Datacenter object (compared to 100)
• 5,000 virtual machines per virtual Datacenter object (compared to 2,500)

I am anxiously waiting for VMware announcements on View 4.5, and the support to more than 8 hosts per cluster when using View Composer. Unfortunately I have not inside track to know if this will change.

VMware vCenter Server Heartbeat 6.3 –View Composer v1.1 and v2.0 services can now be protected using vCenter Server Heartbeat.

Have I missed anything?

I would like to start this blog post saying that this article was actually not planned – it just happened. Some other very smart people have been doing the hard work of going through all the new features, one by one, to explain to us the differences and improvements on vSphere 4.1

I had opportunity to do some pretty interesting performance tunning exercises with vSphere 4.0 and 4.1 using Intel Nehalem 5500 CPUs with 8 physical cores HT.

Now that vSphere 4.1 RC has been released and the NDA has been lifted I can share this information. Unfortunately  I can’t give details about the applications or the performance tests executed. However, I am able to say that these tests are the exact same simulation, on the same piece of hardware and they were executed on 2 VMs with 8 vCPU, 16GB RAM, in a single physical server. During the simulation there are no contentions to be seen on memory or disk IO.

The test workload had the ability to increase user simulations and achieve 100% CPU utilisation of all 8 vCPU (maximum supported by vSphere) for both VMs through increase of number of users/transactions.

There are a number of lines on my graphs below but please concentrate on the marked ones: CPU Host Utilization (%), Transaction Response Time (latency in ms) and Number of Users.

vSphere 4.0

When number of users (black line) reach 2200 the Response Time start to slip (yellow line) and when more users are loaded into the system the Response Time gets even higher; eventually getting up to 100 milliseconds. You may also picture what is happening to CPU utilization (blue line) and will notice that average CPU host utilization never really goes up to 100%.

Note: Sample interval is 20s

Now, let’s have a look at vSphere 4.1 performance improvements that VMware has been announcing.

vSphere 4.1

As the number of users (dark blue line) increases, the Response Time (light blue) has minimal variation, only slipping when user load is at 3000 and CPU at 100% utilization. By itself this represents an increase of 136% on the number of supported users/transactions for this specific workload. It’s is also interesting to note that vSphere 4.1 will reach more often an average of 100% CPU utilization when the system if fully loaded, and maximum average obtained with vSphere 4.0 was around 97%.

vSphere 4.1 clearly better utilizes the resources available or make more resources available thought the reduction of overhead. The impact of the new VM Wide NUMA feature must be also considered.

Take your own conclusions of these comparisons but it’s important to mention that this is not a deterministic test and the results may vary according to the type of workload, number of VMs and number of vCPUS.