VMware Horizon 7 v 7.6 Technical What's New Overview

VMware End-User Computing (EUC) solutions empower the digital workspace by simplifying app & access management, unifying endpoint management & transforming Windows delivery. To learn more visit Digital Workspace Tech Zone at https://techzone.vmware.com

LSI Logic SAS vs VMware Paravirtual SCSI disk

Within virtual machines, there are different SCSI controllers available for writing the data to the actual disk. For the different operating systems, there are best practices which gives the best performance. Windows XP uses the BusLogic Parallel SCSI driver and the results are acceptable. With Windows 7 the commonly used controller is the LSI Logic SAS controller. Which is selected automatically when creating a virtual machine of this type.

Different vendors have different best practices, some of them advice to use the VMware Paravirtual SCSI controller. The VMware Paravirtual SCSI controller needs to be selected manually and needs some additional actions before it can be used. Creating a small additional disk with VMware

Paravirtual SCSI controller connected will force the OS the use and installation of the correct driver. The additional drive can be removed after installation and the initial drive must be connected to the VMware Paravirtual SCSI controller.

The question is which of these controllers gives the highest performance. For that I have started some tests with IOmeter in a virtual Windows 7 machine. The first test was with the VMware Paravirtual SCSI controller and using an additional disk beside the system disk. The results of the test is show below:



The second test was performed with the LSI Logic SAS controller and was using the additional diks.
This configuration could not give the same performance as the VMware Paravirtual SCSI controller, the results of this test are placed below



The other test we did was with the system disk instead of the additional disk. The same results are showed as the previous tests. The use of the VMware Paravirtual SCSI controller performs a little better then the LSI Logic SAS SCSI controller.

The results of above are within the virtual machine, with Xangati i was able to measure from the outside. The following picture will show the light better performance of the VMware Paravirtual SCSI controller, where the first and last test includes the VMware Paravirtual SCSI driver:


For now, the conclusion can be drawn that the use of the VMware Paravirtual SCSI controller lead them a slight performance gain in these test.

VMware Remote Console 7.0 Released

VMware Remote Console (VMRC) is a standalone Windows application that provides console access and client device connection to virtual machines on a remote host.  You need to download this installer before you can launch the external application directly from a vSphere Web Client.
In the VMware Remote Console Windows application, you will have access to:

• Mouse and keyboard functionality in the VM
• Send Ctrl + Alt + Delete
• Full screen mode
• VM power operations
• Client-side device connection such as CD-ROM, USB, and Floppy (requires administrator access)

Internationalization

VMware Remote Console 7.0 is available in the following languages:

• English
• French
• German
• Japanese
• Korean
• Simplified Chinese
• Traditional Chinese
• Russian
• Italian
• Spanish
• Portugal
• Nederlands

Download at source

Multiple Sessions in VMware Horizon View

When connecting to a floating pool using the View client, a user ended up receiving a new session despite having an existing session on another VM.

Analysis showed two desktop launch requests that came in from the same client connection in quick succession, spaced two seconds apart. Client log files imply the most likely scenario is that the user requested the desktop, immediately hit cancel on the wait dialog after the request was dispatched, and then launched it a second time. The View Connection Server correctly identified an existing disconnected session for the user while processing the first request at 13:18:57 for example, and provided the client with details to reconnect. The client dropped the Connection Server's response and sent a second request at 13:18:59. This in turn was routed to the same VM, but the request was rejected as the first connection was still being set up by the View Agent. At this point the Connection Server then fell back to providing the user with a new session as the original was unavailable.

Solution:
View 5.1.1 and onwards contains a hidden configuration option that will inform the Connection Server to not fall back and allocate a new session if it knows the user already has one, even if reconnecting to the session failed. In the specific case analyzed, if this was toggled the user would have received a connection error on the second launch request with the option to retry. Retrying a few seconds later would have succeeded.

VMware recommends that the option to disable the default fallback behaviour is enabled. Instructions for this are below:

• Ensure connection servers are running 5.1.1 or later
• Follow the steps to connect to the ADAM database at http://kb.vmware.com/kb/2012377
• Navigate to the object CN=Common,OU=Global,OU=Properties,DC=vdi,DC=vmware,DC=int
• In the Attribute Editor for the object, edit pae-NameValuePair attribute
• Making sure not to adjust any other values, add a new string to the attribute with value "cs-allowfallbackfromexistingsession=0" (no quotes)
• Click OK to close the editor dialog, your change is applied with no need to restart the servers
• To reverse the change, edit the attribute again and remove the above line

Verification:
To verify the fix has been applied, you may find the allowFallback value in a debug level line on any desktop launch. The line will have the following format:
 
  DEBUG getSessionForApplication, userDn: , appMap: {=, [...], allowFallback=false, [...]}

Removing vCenter Extensions

Many different products that provide additional functionality within a vSphere environment, use the registration method within the vCenter Server. These so-called vCenter Extension used for integration. This may sometimes happen that a new installation of the product must be carried out where the vCenter Extension not properly removed. These vCenter Extensions can also be manually removed.

To remove a vCenter Extensions, go to the URL:

https:// //mob/?moid=ExtensionManager

Here, an overview is given of the present Extensions.

Select the Extension that needs to be removed and select Unregister Extension.

In the opened window, the name of the Extension need to be filed. For example com.vmware.vShieldManager to remove the Extension of the vShield Manager software. Then select the option Invoke Method to the registration within the vCenter Extension Services to remove the Extension.

Adding AD domain to vCenter 5.1

With the new vSphere 5.1 release, authentication can be done with local accounts and additional sources from existing authentication sources. When adding additional sources, one of the possibility to add Active Directory as a authentication resource.

In the following sample an environment will be added to the vCenter environment which contains a single domain controller.

The main configuration settings which must be set are the Primary server URL, which is the ldap source. In this sample a IP adress is used, but a FQDN will work to. The second configuration setting which have to be made is the Domain name of the active directory.

The last configuration is the authentication type. When using the Password type a UPN name of an administrative account and password will do.

Adding Users and/or Groups
After preparing the vCenter configuration for SSO, the user or groups can be added and given permission for using the vCenter environment.

Assigning Roles

After selecting the needed users or groups a role can be assigned to the selected user and/or group.

After hitting the OK button the user and/or groups are given the selected role within the vCenter environment.

VMware View 5.0 new features

The next version of VMware View will have better PCoIP performance, more client device support,a storage management feature similar to Citrix IntelliCache and -- finally -- integrated profile management.

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 with Oracle 11g

The latest release of VMware vCenter 4.1 is capable of using difference database systems, mostly these installations are done on SQL databases. But also DB2 and Oracle databases are supported. At a customer site is Oracle 10g used as a default for all databases. Within a few months the customer will upgrade these databases to Oracle 11g. Using these difference versions for now and in the feature, we decides to use the Oracle 11g client for installing vCenter and View Composer. The Oracle Install Client 11g is used for connecting to the Oracle 10 database.

vCenter will be placed on a Windows Server 2008 R2 Enterprise with slip streamed 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 /Infrastructure/tomcat/lib folder

VMware View 4.0 (with software-only PCoIP)

Last week VMware finally released the much awaited View 4.0, which supports vSphere 4.0 and introduces the software-only version of the Teradici remote desktop protocol PCoIP.



VMware is offering two versions of View 4: Enterprise (which includes vSphere and View Manager 4.0), priced at $150 per concurrent user, and Premier (which also includes View Composer and ThinApp), priced at $250 per concurrent user.



Of course the key aspect of this release is how well PCoIP performs on LAN and WAN scenarios.
Unfortunately the product will be available for download on November 19, so for now it’s impossible to make a performance analysis and comparison with Microsoft RDP 7, Citrix ICA/HDX and the other tens of alternatives that are flooding the VDI market.



The major problem with PCoIP is if its performance is so great to justify the adoption of a new proprietary remote desktop protocol at its 1.0 release (the protocol is more mature than that but so far relied on hardware components).
Many customers may want to be careful here, mostly considering that VMware and Teradici just have a co-development agreement, which is not even exclusive.
What happens if Teradici is acquired by a VMware competitor or if the company suffers major issues?
And most of all, what happens if one year from now VMware consider this protocol unpractical and too expensive to optimize and decides to replace it, for instance, with the just ratified Net2Display standard?

Anyway a lot has been already said.

Brian Madden already published a brief FAQ list, which includes a couple of interesting details:

* The PCoIP client only supports Windows at the moment. Linux and Mac OS versions are expected next year
* View 4.0 will fully support Microsoft Windows 7 as guest OS in early 2010

Chad Sakac already published a blueprint to design a View 4.0 architecture with the recently announced VMware/Cisco/EMC hardware called VBlock.
The solution (a VBlock 1) fits over 2,048 virtual desktops and costs $750 per seat all inclusive:



The paper includes some performance analysis. It doesn’t clarify if the numbers are obtained when using the RDP or the PCoIP protocol (assuming this will make any difference) but it’s really worth a check.


Update: With some delay VMware finally released the bits of View 4.0 (build 210939).
To install it you first need to update vSphere 4.0 with Update 1 (build 208156), released Nov. 19, 2009.

Source: virtualization.info

virtual machine with input specifications already exists

While in the progress of deploying new virtual machines the deployment of a virtual machine stopped in one particular pool. After doing some investigation the viewcomposer log gives me the following message:

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 = ''))

SELECT * FROM SVI_SIM_CLONE

WHERE (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 = ''))

delete FROM SVI_SIM_CLONE

WHERE (VM_NAME = '')

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

VMware View Client as a shell for XPe and XP Pro clients

Using the Win32 View Client on XPe or XP Pro will allow you to use the full featured View client with all the bells and whistles. The problem is that it's still XP and can be confusing to your users to have them log into one desktop just to send them to another virtual desktop. So how can we fix that? If you replace the shell with the View client you can eliminate the XP desktop and on a boot of the client the only interface presented to a user is the View Client. This makes logging in simple and clean. The problem with just replacing the shell with the View client is that once the user exits, logs out, or just accidentally closes the client, It will not start again automatically. Below is a way to have the Client restart automatically and hide the needed command window.

The following instructions will hide the XP desktop and present the user with just the View client and will restart if it gets closed. This was done on an HP t5730 Thin client but the process should be the same for most XPe Thin clients and even a repurposed XP Pro desktop.

Create a View.cmd file with the following.

@echo off

:View

"C:\Program Files\VMware\VMware View\Client\bin\wswc.exe"

goto View

Place it where ever you like, c:\BatchFiles for example

Create a vbs script with the following in it. Place it wherever you like C:\BatchFiles for example.

Set WshShell = CreateObject("WScript.Shell")

WshShell.Run chr(34) & "C:\BatchFiles\view.cmd" & Chr(34), 0

Set WshShell = Nothing

Open Regedit and go to ;

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

Change Shell from explorer.exe to the new shell path and the Windows Scripting command, e.g wscript c:\BatchFiles\view.vbs

Commit the changes to the flash drive if using XPe.

ewfmgr c: -commit

Reboot. Enjoy the new View only interface!

Once this is done there will be no desktop for any users, including Administrator. You can still get to the Task Manager with a CTRL-ALT-DEL but the interface is gone. You can modify the Registry setting to use a specific user by logging in as that user and modifying HKEY_CURRENT_USER instead.

Distributed Power Management on x3850

While working at a customer site I have been working on setting up Distributed Power Management, DPM is an experimental feature delivered through VMware ESX 3.5 and vCenter 2.5. While having some problems with the configuration I had two goals. I wanted to keep redundancies within the current configuration and wanted to comply to the goals of the customer, which was as Green as possible.

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

View Designing

When doing a design for a View Architecture there are a lot of things to think about in difference areas, the following rules are general and can be used for doing the View design.

The following design specifications will be observed when designing the View Composer architecture:

•Every View partition with View Composer desktops requires that View Composer is installed on that container’s vCenter Server system
•Maximum of eight ESX/ESXi hosts per View Composer cluster
•Maximum of 500 vClones (linked clones) per Parent VM replica; this is a good practice for recompose/refresh operations
•Maximum of three 500 VM clusters per View container; this is to stay clear of the 2,000 VM limit in vCenter Server 2.5
•Maximum of 64 linked clones per datastore

There are a lot of other objects to observe, i will try to write them down here in the future.

VMworld 2008 - The day before

After picking up my badge en general stuff this day i found some nice info from Cisco, they were announcing the introduction of Cisco's Virtual Switch for VMware ESX. During these days Cisco will introduce technologies and services to help the turn in the IT environment into a dynamic data center that is more scalable, more agile, and more resilient. More info will come when available.

They are still working hard to get everything done for Tuesday when vmworld will really start, tomorrow the Partner Day and the Technology Exchange is on the program.

VMware unveils VMDirectPath technology, Intel to support it with Nehalem

At the Intel Developer Forum (IDF) 2008, Intel showed on stage its upcoming new quad-core CPU codename Nehalem, much expected by the virtualization professionals because of the included Extended Page Tables (EPT) technology.

On top of that now there’s another reason to wait for Nehalem: the processor will support a new technology developed by VMware and called VMDirectPath.

VMDirectPath will allow ESX to avoid the emulation of network interface cards and map the physical NICs directly to the virtual machines:

Intel delivered a very interesting presentation about its effort to boost the hypervisor performance with VT-x, VT-d and VT-c technologies and slides from 27 to 32 are about VMDirectPath:




Nehalem CPUs for server use will be released no earlier than H2 2009.

VMware predicted that around that date the technology would completely cancel the performance degrade that virtualization introduces.It seems that to go there customers will have to bring with them a lot of hardware (and possibly drop a lot of flexibility).

VMware ESX and Enhanced VMotion Compatibility

The classic VMotion problem of recent times is the customer who buys tin from a vendor, only to find out that the processor number e.g. 53xx and 54xx, is actually quite significant. The principle difference which will prevent VMotion is the addition of SSE4.1 to the 54xx range of Intel processors (if you previously only had 53xx Intel processors).

An application using the SSE4.1 feature (or is aware of this feature) when VMotioned to a non-SSE4.1 host would likely blue screen trying to make use of this feature on the older host.

People then recalled the CPU mask feature in VMware - we’ll just mask it out they thought. Unfortunately VMware declared this was an unsupported mask with KB1993 and KB1991.

Note that for production environments, VMware neither supports nor recommends modifying VMotion masks for SSE3, SSE3, or SSE4.1 because of the risk of failure of the application or guest operating system after migration.

The reason soon became clear:

* SSE features can be used by user-level code (applications).
* Mask does not work for user-level code (i.e. applications).
* In user-level code, CPUID is executed directly on hardware and is not intercepted by VMware.
* Thus, VM cannot reliably hide SSE from an application

The best that customers could do was buy compatible hardware, and keep themselves right with vendor compatibility charts such as these ones from Dell and HP.

ESX 3.5 U2 brought a new feature: Enhanced VMotion Compatibility (EVC for short) which I’ll explain…

New CPUs are coming out with a facility to ‘turn off’ (mask) features that would make them VMotion incompatible with other hosts running older (compatible) CPUs.

For Intel this is called Flex Migration. It is clear that for processors that are in different families but support Flex Migration will negotiate the common feature set amongst the CPUs.

Where it is not absolutely clear, is where you have an existing cluster and you want to add in hosts with the new Flex Migration facility. You should be able to do this if you satisfy the following requirements (paste from Basic Administration Guide):

All hosts in the cluster must either have hardware live migration support(Intel FlexMigration or AMD‐V Extended Migration) or have the CPU whose baseline feature set you intend to enable for the cluster. For specific host processors supported, see Table 15‐1.

Table 15-1. Processors Supported in EVC Clusters

Vendor Baseline Processor Processors Supported
Intel Intel Core 2 (Merom) Intel Core 2 (Merom)
45nm Core 2 (Penryn)
AMD AMD Second Generation Opteron (Rev‐E/F) AMD Second Generation Opteron (Rev‐E/F)
AMD Third Generation Opteron (Barcelona)

It is therefore advised that customers buying new tin, if they cannot acquire a processor that is exactly the same or in the same family – purchase a Flex Migration enabled CPU.

It should also be clear that only masks the features on the processors, it does not turn them off. Programs which are written to guidelines will behave, those which are coded badly will see these features regardless – and more importantly will encounter issues if VMotioned to a host that used that feature. Pasted from VMware:

EVC utilizes hardware support to modify the semantics of the CPUID instruction only. It does not disable the feature itself. For example, if an attempt to disable SSE4.1 is made by applying the appropriate masks to a CPU that has these features, this feature bit indicates SSE4.1 is not available to the guest or the application, but the feature and the SSE4.1 instructions themselves (such as PTESE and PMULLD) are still available for use. This implies applications that do not use the CPUID instruction to determine the list of supported features, but use try‐catch undefined instructions (#UD) instead, can still detect the existence of this feature.

Therefore, for EVC to be useful, application developers must adhere to recommended guidelines on feature detection. CPU vendors recommend that software programmers query CPUID prior to using special instructions and features available on their CPUs. If this guideline is followed by programmers, EVC is a reliable mechanism for live migration of x86 virtual machines across varied hardware. Thus, you can use EVC to enable an entire cluster to use the same set of basic features, allowing migration with VMotion across any two nodes in the cluster. VirtualCenter can also set up new hardware add‐ons to the cluster and apply these masks.

Intel provide a comparison tool to check beforehand if a CPU possesses Flex Migration capability.

Further Information on this subject can be located in the VMware VMotion Guide and the ESX 3.5U2 Basic Admin Guide Page 238 Onwards.

Bron: http://www.novosco.com/articles/2008/08/19/vmware-esx-and-enhanced-vmotion-compatibility/

ESX3: Scripted Install is disabled

When you click the Log In To Script Installer link, you are presented with the following error

To fix this problem you will need to login as ‘root’ to the console of your ESX host and edit a file. By default the scripted installer applet is disabled - to enable it follow the process below:

1. Log in to the console using your root account

2. Using VI or NANO open the following file /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/webapps/ui/WEB-INF/struts-config.xml

3. We need to comment out and un-comment some lines. Luckily they are in the same section. You need to find the scripted install handler section.

4. I have marked in red the line of code we need to comment out and the section to un-comment in blue, in the picture below.

To comment out the line, we use the to start the comment and close the comment using –>

5. In the screenshot below you can see the changes we have made to the section. Save the changes and exit the editor.

6. To have our changes take effect the configuration file needs to be re-read by the web server so we will need to restart the webAccess service.

Enter service vmware-webAccess restart to restart the webAccess service

Bron: xtravirt

A Few SRM Discussion Points

• Storage array replication is a necessity. Without it, SRM can’t be used. Keep in mind that only certain arrays and certain replication technologies are supported, so be sure to check the SRM compatibility list.
• The Storage Recovery Adapter (SRA) is a critical part of an SRM deployment, but it doesn’t come from VMware. It comes from the storage vendor (assuming that it is a compatible array and compatible replication technology).
• Two instances of VirtualCenter (VC) are required. One of these will be at the “Protected Site,” the other will be at the “Recovery Site.”
• Likewise, two instances of SRM are needed, one at each site.
• The VC servers and SRM servers at each site need to be able to talk with each other, i.e., they need IP-based connectivity. SRM will communicate with the local VC server over TCP ports 443 and 8095. SRM will communicate with the remote VC server over TCP port 443. The local SRM server uses the remote VC server as a proxy to communicate with the remote SRM server instead of communicating with it directly.
• VC and SRM each require their own database.
• If the physical hardware is sufficiently equipped, then VC and SRM can be co-located on the same server. Otherwise, VC and SRM should be placed on their own physical server.
• SRM does not support failback. Instead, create a Recovery Plan in reverse.
• The VC and SRM databases do not replicate between the sites. They are maintained separately.
• Observe the “DNS Rule of Four” for SRM—forward lookup, reverse lookup, short name, and fully-qualified domain name (FQDN). All four of these should work properly.
• All VMs in a Protection Group will fail over at the same time, so users will want to properly architect the Protection Groups to provide the appropriate DR functionality for the right VMs. Application dependencies are important here—failing over some VMs but not others that provide dependency services won’t do much good, now will it?
• VMware SRM requires Virtual Center 2.5, and VirtualCenter 2.5 Update 1 is recommended. Update 2 is not supported.
• Similarly, VMware ESX 3.5 Update 2 is also not supported (yet).

bron: blog.scottlowe.org

Watching your ESX server performance in real time with ESXTOP

Very few people understand the power of the VMware Console. Even fewer know the power of esxtop, a command-line real-time monitor for the vmkernel. You can get more information here.

One of the most awesome things about esxtop is that it’s minimally intensive on resources and can be run interactively, as a batch mode or as replay worlds.

However the practice of logging in and running it with root logged in on every ESX host is a little annoying and exposes anyone with basic knowledge to the Ctrl-C kill command, and then the root prompt. Which is bad.

What I do on some of my sites is similar to what VMware does on tty11 (Ctrl+Alt+F11) - the VMware ESX Service Console Welcome Screen. Essentially, I output a dynamic interactive esxtop to one of the available tty’s (tty7-12 are disabled in ESX 3.x, so you have to use 1-5, 6 is the emergency console)

Here’s what you need to do edit in the/etc/inittab file:

Edit out the mingetty tty5 terminal by making this line:

5:2345:respawn:/sbin/mingetty tty5

…look like this:

#5:2345:respawn:/sbin/mingetty tty5

Then, insert the following bolded lines after the non-bolded line which should already exist in your /etc/inittab:

6:2345:respawn:/sbin/mingetty -f /etc/issue.emergency -l /bin/login.emergency tty6

# Output ESXTOP to Console/tty5
esxtop:2345:respawn:/usr/bin/esxtop -d 2 -s > /dev/tty5 < /dev/tty5

After this, reboot your ESX server and watch console 5 (Ctrl+Alt+F5) - you will see all your vmkernel performance stats, and you can control them interactively as per the instructions for esxtop which you can find by running man esxtop in the service console. Or you can read the documentation here.

Bron: http://lraikhman.blogsite.org

Top Tips for Deploying VI

The following “top tips” highlight some issues that can arise in a VI deployment. They cover things which are sometimes hard to diagnose, or which might result in a problem weeks or months after some seemingly innocuous action. It is meant to shed some insight on “latent” issues, that is, those which don’t result in immediate warnings or errors when the root cause event occurs. These have been collected from customer experience gathered over time by the VI team, and will be posted in two parts. We welcome your comments on these and any other “gotchas” that you might have encountered.

1. Make sure DNS is fully configured. This includes ensuring proper, consistent configuration for all of the following: short name, fully-qualified name, forward lookup, and reverse lookup. Otherwise, you’ll see ESX hosts intermittently disconnect from VirtualCenter, and HA might not work properly.
2. Don’t use Virtual SMP for applications which don’t need it. Most applications are single-threaded and therefore cannot benefit from more than one virtual CPU. Assigning just a single CPU to VMs maximizes the physical CPU utilization of ALL of your cores, and avoids underutilized cores. If your applications were converted from running on 2 physical servers, don’t assume they need to – they might have been running on the smallest practical server configuration available. Start with a single VCPU, and then monitor the performance to see whether increase the number of virtual CPUs actually makes a difference.
3. Make sure you monitor the “% ready” metric. There’s one new, key metric in managing virtualization environments that is doesn’t exist in physical environments: “% ready”. “% ready” measures, for a given VM, the amount of time that a VM is able to run on the physical CPU but is unable to run because ESX doesn’t schedule it. In a well-running VMware environment, “% ready” should always be near 0. When it climbs to non-zero, it’s indicating that your applications are not getting the CPU time that they desire. This typically points to one of many possible, real underlying issues: maybe you don’t have enough physical memory, and ESX is swapping out VM’s… Or maybe you’re simply running too many VM’s on the box… Or, maybe you’ve got the overuse of virtual SMP issue described above, and other VM’s are getting starved.
4. Watch your snapshot space growth. Because snapshots live on your disk and grow over time, you want to be careful that you have enough spare capacity on your disk. Every snapshot consists of a “REDO” file; for the most recent snapshot, all new disk writes associated with the VM are recorded to this file. A REDO file has the potential in the extreme to grow to be the size of the original disk, and the REDO file of every snapshot that you maintain continues to occupy disk space. You want to make sure that you have enough “headroom” on your datastore to handle such growth over time. Operations that might dramatically increase the size of your snapshots include the following: an OS service pack update, application reinstall, or a disk defrag inside the VM.
5. Make sure the SQL Server Agent is up and running on the VirtualCenter DB. VirtualCenter depends on Microsoft SQL Server Agent to perform stats rollups. However, VirtualCenter does not have the ability to ensure this service is running on the DB server. If the user has it disabled, or the service is shut down at some point, the VI Client will not show expected stats (weekly, monthly…). In addition, since daily data is not rolled up, it accumulates in the database, thus degrading performance and consuming more and more space.
6. Team your management NICs if using VMware High Availability (VMware HA). This will help you avoid false alarms (i.e. false VMware HA failovers of VM’s) in situations when you temporarily lose connectivity between your ESX hosts (e.g. when there’s a momentary network outage, or even during a network switch maintenance operation).

1. If you have an active/passive FC storage array (most mid-range arrays fall into this bucket), be careful about setup. Firstly, be sure to have redundant paths from FC switches to your arrays’ storage processors. Secondly, be sure to use “MRU” (the default) for the path-selection policy and not “fixed”.

The best way to explain the first issue is with a picture. What’s wrong with the following configuration?

Although you might believe that you have full redundancy between the hosts and the switches, and specifically that you can survive one HBA failure on each host, the reality is that you don’t have enough redundancy. Here’s one failure scenario that won’t be handled properly:

The reason is that, with active/passive storage arrays, a given LUN can only be presented on one storage processor at a given time. The LUN can shift from one storage processor to another, but such a shift takes many seconds (potentially up to 30 seconds). If both HBA’s have failed (as in the above diagram), then the ESX hosts won’t be able to access to the same LUN at the same time. Host 1 attempts to access the LUN on storage processor 1; host 2 attempts to access the same LUN on storage processor 2; and you end up with a ping-pong effect, or a “path thrashing” effect due to the active/passive array shifting the LUN back and forth between the two storage processors. Performance of VM’s on both hosts will be erratic and penalized.

The solution is simple: create redundant connections from the FC switches to the array storage processors, as shown below.

There is a second noteworthy issue with active/passive arrays related to this same path thrashing effect: make sure that you use the “MRU” path selection policy (the default) rather than the “fixed” path selection policy. If you use “fixed”, you may make the mistake of forcing the use of a particular storage processor for one host… but a different storage processor for another host… and thus end-up in a similar LUN ping-pong or path thrashing situation.

For more details about path thrashing see, the SAN Configuration Guide.

2. When configuring your VI environment for VMotion, make sure that your physical network switches are configured properly; in particular, make sure that each port has the right network (e.g. VLAN) visibility.

VMotion requires that the destination ESX host have similar network connectivity to the source ESX host (so that, for example, the VM can continue access to its assigned VLAN after the VMotion). VirtualCenter checks for correct virtual switch configuration on the source and destination ESX; however, VirtualCenter does not for correct configuration of the physical network switches. In a larger VI deployment where many network switch ports are involved, a single misconfiguration of a single physical switch port can be hard to detect. The symptom will be as follows: when the particular VM relying on a particular VLAN id VMotion migrates to the particular ESX host with the misconfigured switch port, the VM loses all network connectivity. Solution: when adding new ESX hosts to a network, take the time to double-check your network switch port configurations to make absolutely sure that all the VLANs are correctly configured.

3. When using VMware HA, take note of how memory reservations are specified and used to reserve cluster failover capacity. Using more consistent reservations or disabling admission control are both appropriate workarounds if the calculations are overly conservative in your environment.

How VMware HA works: If a VMware ESX host fails, VMware HA will restart the VMs affected by that failure on alternate hosts in the cluster. In order to do so, HA must reserve failover capacity within the cluster. HA currently achieves this by implementing an “admission control” policy that prevents (or warns against) the powering on of VMs that would encroach upon the failover capacity being reserved. In some cases, however, the admission control calculations may be too conservative.

Example scenario: Suppose you have 19 VMs, each with a 300 MB memory reservation. To power-on all of these VM’s, you need 5.7GB of RAM (=19*0.3) (total within the cluster, after allocating space for potential host failures, and not accounting for memory sharing in ESX). Since all reservations are equivalent, HA defines an average VM to require 300 MB of memory.

Now, let’s suppose you power-on a 20th VM with a 2 GB memory reservation. Instead of calculating memory requirements as 7.7 GB (=19 x 0.3 + 1 x 2), HA takes a more conservative approach and redefines the average VM to be the biggest reservation observed. With the higher reservation specified, HA will cautiously assume that every VM need 2 GB of memory, and will ask for 40GB (=20*2) of RAM to be set aside for total runtime and failover capacity within the cluster. These calculations are intended to be conservative to ensure that sufficient spare capacity is available, without fragmentation across hosts within a cluster.

In many cases (such as clusters with widely varying sizes of hosts and VMs), however, these calculations can be more conservative than desirable, and can lead to “insufficient failover capacity” warnings when powering on more VMs.

Two potential approaches are recommended if you are observing these warnings, or want to avoid them within a heterogeneous cluster configuration:

Approach 1: Either lower the reservations on your most demanding VM’s, or remove the reservations skewing the calculations and rely upon “shares” instead. See the resource management guide for differences between reservations and shares.

Approach 2: Alternatively, configure HA to disable strict admission control. Host failures will still be detected and acted upon, but VMware HA will not prevent the starting of new VMs due to insufficient failover capacity.

4. When sizing your LUNs, a medium-sized LUN (~500GB) seems best for most situations.

Small LUN’s (and VMFS volumes) can result in SAN management complexity (too many LUNs to manage). Very large LUN’s can result in performance issues (due to VMFS lock-contention for certain operations), too coarse a granularity for troubleshooting and performance tuning, and failure/error isolation. The below chart summarizes some of the considerations. Details are provided on page 72 of the VI 3 SAN Design Guide.

	Smaller LUN’s 100GB	Medium-sized LUN’s 500GB	Larger LUN’s 3TB
VMFS: Metadata overhead	Some overhead (0.5%)	Negligible overhead (<0.1%)	Negligible overhead (<0.1%)
VMFS: Lock-contention during VM creation operations, or during VCB-based backup operations (*)	Near zero contention	Some contention	Much contention
Impact of a failure or error, difficulty of troubleshooting	Affects a few VM’s	Affects 20-30 VM’s	Affects many VM’s
Ease of SAN mgmt	Hard (many LUN’s to manage)	Medium	Easy (just 1 LUN to manage)
Ease of tuning performance (**)	High (tunable per the few VM’s on a LUN)	Medium (tunable for 20-30 VM’s at a time)	Low (one setting for many, many VM’s)
Flexibility in specifying value-added services (***)	High (different LUNs can have different policies or settings)	Medium (tunable for 20-30 VM’s at a time)	Low (many VMs share the same policies or settings)

(*) File creation in VMFS grabs a SCSI lock on the LUN. Since each LUN has a limited number of SCSI locks, excessive concurrent file creation in VMFS can cause lock contention, which can hurt performance. This can be apparent if multiple users are concurrently creating VM’s (and therefore VMFS files), or when a VCB-based backup process is concurrently backing up multiple VM’s (and is therefore concurrently creating multiple VMFS REDO files)
(**) e.g. RAID-level, array caches, queue depths, path selection/path dedication
(***) e.g. Backup, other data protection features such as replication, mirroring, etc., capacity optimization features such as de-dupe, thin-provisioning, etc., security and encryption features

Bron: http://blogs.vmware.com