A VMware View integrator based in New England who is privy to company details said VMware View 5 will have a storage management feature similar to Citrix IntelliCache. Storage costs and performance issues plague virtual desktop customers, so this would alleviate those issues.

Sources close to VMware also said Virtual Profiles will be part of the View picture later this year, but the functions will be limited. Specifically, it won’t include the desired Windows XP to Windows 7 profile compatibility.

That means many VMware View shops will still need to buy third-party profile management tools. VMware endorses Liquidware Labs profile management product, and Liquidware offers its ProfileUnity product at a discount intermittently for View customers. The company’s profile management offering does much more than the Virtual Profiles management tool VMware acquired from RTO Software in 2010.

VMware declined to comment on View 5. However, IT pros expect the company to disclose the product’s advances at VMworld 2011 in August.

Source: http://searchvirtualdesktop.techtarget.com/news/2240036965/VMware-View-5-to-add-profiles-PCoIP-and-client-support

vCenter will be placed on a Windows Server 2008 R2 Enterprise with slipstreamed SP1, and is using a double vCPU with 4 GB of RAM.

Before the ODBC connection to the database can be made, the Oracle 11g client is places on the vCenter server, therefore the Oracle version 11 packages are extracted to C:\Oracle

• instantclient-basis-windows.x64-11.2.0.2.0.zip
• instantclient-odbc-windows.x64-11.2.0.2.0.zip
• instantclient-basic-win64-10.2.0.5.zip

After that the odbc_install.exe is executed for making the client software available within the ODBC connection software. A default tnsnames.ora Oracle configuration file, created by the customer is stored in the created sub folder NETWORK\ADMIN, which results in:

C:\Oracle\instantclient_11_2\NETWORK\ADMIN\tnsnames.ora

The installation of the Oracle 11 Client have been finished with these steps.

The next step is creating the ODBC connection to the database, the following steps are used for creating these connection:

Start Data Sources (ODBC) within Administrative Tools, and create a new System DSN

Select the Oracle in instantclient 11_2 and hit the Finish button

Supply the needed information for the connection and use the Test Connection button for testing the connection.

After these steps the installation of vCenter can be done and the created DSN can be selected during the installation and the connection will be used for filling the database.

The latest step is the extraction of the ojdbc14.jar file from the Oracle instant 10 client, and place the file in the <vCenter Install Location>/Infrastructure/tomcat/lib folder

The Knowledgebase Team has prepared KB article: Unable to connect from the Windows 7 Client to the View Connection Server after installing the patch in Microsoft Knowledge Base article 2482017 (1034262), and an alert has been placed on the Support page to alert customers of this issue.

This Knowledge Base article will be updated if new information becomes available (you can subscribe to rss feeds on individual KB articles for this purpose). If you have been affected by this, please read the KB.

Both Remote Desktop application types (Predefined and User Defined) do not require import of TSPUB file. All necessary RDP parameters are automatically generated by the Microsoft Forefront UAG Terminal Services RDP Data service.

Publishing a Remote Desktop, UAG Management Console reads an RDP parameters template file at the moment a new Remote Desktop application is added to the portal. All parameters specified in this file will be added to the RDP data the UAG automatically generates for particular Remote Desktop application unless these parameters are controlled in the RDP data generation. Such parameters will be always overwritten whatever their customization is.

The template file is not reread in the moment of RDP data generation, configuration activation or whatsoever. Its content is read at the moment the application is added to the portal, and its content in this very moment is stored internally within the UAG application data. Thus the template can be modified before addition of each new Remote Desktop application, and these applications will use different sets of additional RDP parameters. Unfortunately, this set cannot be edited or reviewed later. Therefore a Remote Desktop application should be removed and added again if modification of the customized RDP parameters is necessary (the new template file will be read upon application addition).

The default RDP data template file is located as

<install-path>\common\conf\rd-template.txt

It is a plain ASCII text file expected to hold RDP parameters in the same way RDP files do this. Currently, the default template file contains a single parameter for illustrative purposes only (it has no actual effect since it is always overwritten during RDP data generation). It is urgently recommended not to modify this file directly but create a custom file according to the current UAG conventions:

<install-path>\common\conf\CustomUpdate\rd-template.txt

The template’s file content is validated for being a syntactically correct RDP file but RDP parameters themselves are not validated for existence, correctness of values, etc.

When using a SQL Database server which resides on a different host, the installation of the SQL Server Native Client is required. When not installing the software, the ODBC connection to the database isn’t working. With the following URL the required software can be downloaded:

http://download.microsoft.com/download/4/4/D/44DBDE61-B385-4FC2-A67D-48053B8F9FAD/sqlncli_x64.msi

While creating the ODBC connection to the SQL Server Database with the Data Source Administrator program, the connection needs to be created with the selection of the SQL Native Client.

On the SQL Database server the database need to be created and some specific SQL Server user account needs to be created. The created SQL Server account is given some specific permission to get the installation to work. The account needs the db_owner permission on the database just created and the same permission on the msdb database. The last permission can be released after the installation of vCenter is finished.

When doing the actualy instllation of the vCenter machine the just created ODBC connection can be selected as the installtion destination, and all the database information is written to this database.

After finishing these steps the installation is done and you end up with a working vCenter installation.

Localization of VMware View

The View Client and online help for View Client are now available in Japanese, French, German, and simplified Chinese. The View Manager Administration Guide, View Manager Release Notes, Getting Started with VMware View document, View Upgrade Guide, and View Architecture Planning Guide are also available in these languages.

VirtualCenter 2.5 Update 6 and ESX 3.5 Update 5 Support

View Manager 4.0.1 includes support for VirtualCenter 2.5 Update 6 and ESX 3.5 Update 5.

Enhancements to the PCoIP Display Protocol

PCoIP now supports the following features:

• Virtual Printing, which allows end users to use local or network printers from a View desktop without requiring that additional print drivers be installed in the View desktop.

• Single sign-on support for third party providers such as Sentillion and Imprivata.

• View Client supports international keyboards when using PCoIP.

For PCoIP-related bug fixes, see the View Client Resolved Issues section.

Click to enlarge.

From this image, we can see that 41.06 GB of memory is in use out of an available 64. But wouldn’t you also like to know which processes or VMs are using the 41.06 GB? To find out, we’ll use PuTTY as our SSH client to run VMware’s esxtop tool.

Let’s start a PuTTY session. Log on, start esxtop and press M for memory. The top of the screen features an impressive amount of info on your host’s memory usage.

Let’s take it from the top.

Physical memory

Click to enlarge.

The MEM overcommit avg tells us that the average memory overcommitment over the past one is between five and 15 minutes. A value of 0.20 is a 20% overcommitment of memory. In the second line, we see the PMEM stats that describe physical memory in the host. This host has 65,534 MB (or 63.99 GB), of which 800 MB is allocated to the cos (i.e., the service console); 672 MB is being used by the VMkernel and 4,0437 MB (or 39.489 GB) is used by “other,” which leaves 23,624 MB of free memory.

Note: The memory used by “other” is officially described as: “everything other than the ESX Service Console and ESX VMkernel.” It is not necessarily all memory consumed by the VM. Each VM, for example, also has memory overhead. The amount of overhead memory depends on the type of guest OS,the number of virtual CPUs, configured amount of guest memory and on whether the guest is 32-bit or 64-bit. For example, a dual-CPU virtual machine with 2,048 MB memory will have 126 MB overhead as 32-bit system and 163 MB overhead as a 64-bit system.

Service console memory

Click to enlarge.

The next line about VMKMEM is of less importance, though it does tell you how the VMkernel performs. But unless you’re troubleshooting an unusual problem, you won’t work with these values. Of more value is how the service console (cos) is doing, which is detailed on the next line. The first value (in this case, free) is the amount of idle memory in your cos. In our example, the cos has 92 MB RAM free out of the 800 MB allocated. Next, we see the swap space configured and swap space free, which are both 1,600 MB. Usually, I configure a host with a 1,600 MB swap partition and 800 MB cos memory.

While 800 MB may seem like a lot, third-party agents often run in the console and so the default 272 MB of memory is not enough. In that event, you want to increase cos memory and set it to 800 MB. You could set it for a higher number, but you might run out of partition space. I therefore always set the swap partition to 1,600 MB since you can also assign only a maximum of 1,600 MB to the cos. Since implementing that as a best practice, I haven’t had to resize a swap partition once.

Transparent Page Sharing (TPS)

Click to enlarge.

Back to our example, the Non-Uniform Memory Access, or NUMA, values in MB. As with VMkernel you seldom have to worry about these. It only shows you how ESX is distributing the memory across the NUMA nodes (if you have NUMA, that is) but these are not values you will be working with. Pay more attention to the PSHARE line. This one tells us how much memory is saved by transparent page sharing (TPS), which in some environments can be quite a lot. In our example, 32,492MB is shared between the VMs, of which 3,779 MB is common, which leaves us with savings of 28,713 MB (or 28 GB) of memory.

Let me explain this in a different way. On this host machine, a total of 32,492 MB is somehow the same in a lot of guests. By using transparent page sharing, ESX only needs 3,779 MB to “store” 32,492 MB. So we are saving 28,713 MB of memory. In my opinion, that is a large amount of memory to save on a single host. Just imagine how much this could save you across an entire virtual environment.

What is transparent page sharing?
VMware ESX can save lot of physical memory using transparent page sharing, especially in environments where a lot of similar OSes are in use. The hypervisor checks each block of memory that a virtual machine wants to write to physical memory. If that block of memory is equal to a block of memory already saved in physical memory, there is no need to use extra physical memory. Instead, ESX only sets a pointer and remembers that this block is used by other VMs. As longs as the VMs only read this block and never change it, the block is saved just once. ESX will use this block until a VM wants to make changes to the VM (write to the block). When that happens, ESX will create an additional copy.

When looking at Windows Server 2003, for example, one can see that a basic Windows install without any extra applications will easily occupy 250 MB RAM after startup. Now suppose I run 20 Windows VMs on one hypervisor. 20 instances of Windows requiring 250 MB RAM each would cost a total of 5,000 MB physical RAM without TPS. With TPS, however, 250 MB would have been stored and used only once. In other words, a memory savings of 5,750 MB. That’s not something to take lightly.

Click to enlarge.

Swap memory and ballooning

Click to enlarge.

This may sound strange, but I believe both SWAMp and MEMCTL numbers should be 0. Let me explain what they are:

• The SWAP value displays the ESX server swap usages statistics, where “cur” is the current swap usage, “target” is how much ESX expects to swap and “r/s” and “w/s” show the rate at which the swapping occurrs.
• MEMCTL shows the total amount (cur) of physical memory reclaimed using the vmmemctl module or the balloondriver, the total amount ESX attempts to reclaim (target) and the maximum amount ESX can reclaim (max).

Now, why should they be zero? Simply put, because they are both indications that ESX doesn’t have enough memory to give to the guests. The first thing ESX wants to do when resources are getting scarce is reclaim the least valuable memory from the guest OS. Because ESX can not talk directly to the OS, it uses the VMware Tools memctl-driver for this.

Ballooning
When VMware ESX runs out of guest VM space, ESX starts a process inside the guest which claims memory. The guest OS will then check the list to see if it has memory that is not in use. If there is, it will will give this to the process. Next, VMware Tools will claim this memory and tell ESX exactly which memory blocks ESX can reuse for other VMs. In this way, the last pieces of unused memory are squeezed out of the other guests to give it to the guests that need it more.

Swap to disk
If the ballooning technique isn’t sufficient, ESX will use its last resort: swapping out guest memory to disk. As disks are always much slower than physical memory, the guest VM will notice a performance degradation so that is not the way we want to go.

Therefore, as soon as you see the SWAP curr or MEMCTRL curr rise above zero, you should really start investigating what is wrong. As a rule of thumb, you should never load your ESX memory to more than 80% or 85%. This way you always have spare memory in case VMs start to use more physcial memory. Also, loading your ESX hosts in a cluster at more than 80% to 85% can get you into trouble with your VMware High Availability failover level.

Violation of UNIQUE KEY constraint ‘IX_SVI_SIM_CLONE_GUEST_NAME’. Cannot insert duplicate key in object ‘dbo.SVI_SIM_CLONE’

I created a support call with VMware, the responses I got where remove those particular record from the database. Removing those records didn’t solved the problem, cause those records were written in different tables, so we created a query which does the trick for us.

Doing a search first, so we know which records will be deleted:

# Finding VM from VM_NAME and BASE_DISK key

SELECT * FROM SVI_SC_BASE_DISK_KEYS

where PARENT_ID = (SELECT ID FROM  SVI_SIM_CLONE

WHERE  (VM_NAME = ‘<VM-NAME>’))

SELECT * FROM SVI_SIM_CLONE

WHERE (VM_NAME = ‘<VM-NAME>’)

When I know which records will be removed I used the following query to actually remove the records:

# delete VM from VM_NAME and BASE_DISK key

delete from SVI_SC_BASE_DISK_KEYS

where PARENT_ID = (SELECT ID FROM  SVI_SIM_CLONE

WHERE  (VM_NAME = ‘<VM-NAME>’))

delete FROM SVI_SIM_CLONE

WHERE (VM_NAME = ‘<VM-NAME>’)

After actually removing the faulty records i was able to deploy new virtual machines again.

To get the redundancy I created a single vSwitch with two portgroups one for the Service Console and one the VMotion port, with each a difference VLANs configured. At both portgroup an active physical NIC was attached which was standby on the other portgroup. My first goals was reached.

To get the second goal I selected the first internal NIC at the ESX host and configured this one attached to the VMotion portgroup. Within the portgroups I configured the auto negotiation as on the Cisco switch to. The reason for this is that is that the used NIC only support wake-on-LAN at 10 or 100 Mbit and not at 1 Gbit.

More info can be found at the following URL: http://tinyurl.com/r8bwth