Enable vSphere console copy/paste without power off — the PowerCLI way

Posted on October 10, 2011 by brian.wuchner

I’ve had an ongoing love/hate relationship with security for years. Today it was heavy on the hate. I rarely have a need to copy/paste between my desktop and a VM console. I normally use some other method to connect to a VM (ssh, Remote Desktop, etc) but today I was testing some Powershell code in an isolated lab environment. The only way to see what is going on is through the console, as there is no IP connectivity between me and the lab. I wanted to write code in the script editor on my desktop and paste it into the VM console, and that’s where I started to run into problems:

Clipboard Copy and Paste does not work in vSphere Client 4.1 and later http://kb.vmware.com/kb/1026437

The solution listed in the code works, but modifying those settings inside the GUI requires the VM to be powered off. Who wants to do that? Not me.

Instead I re-used some previously written PowerCLI code and a stun/unstun operation (i.e. power on/off, suspend/resume, create/delete snapshot/storage VMotion) to achieve the same thing.

[cc lang=”Powershell”]
#Clipboard Copy and Paste does not work in vSphere Client 4.1 and later
#http://kb.vmware.com/kb/1026437

$copy = New-Object VMware.Vim.optionvalue
$copy.Key=”isolation.tools.copy.disable”
$copy.Value=”FALSE”

$paste = New-Object VMware.Vim.optionvalue
$paste.Key=”isolation.tools.paste.disable”
$paste.Value=”FALSE”

#Create a Machine Config Spec using the three option values specified above
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.extraconfig += $copy
$vmConfigSpec.extraconfig += $paste

#Get a VM View collection of all the VMs that need to have these options
$vms = get-view -viewtype virtualmachine |where {$_.name -eq “lab-dc01”}
foreach($vm in $vms){
$vm.ReconfigVM($vmConfigSpec)
}
[/cc]

This code creates a ReconfigVM specification that includes the values required for both copy and paste operations into the vSphere client. It then applies it to a VM named lab-dc01. (If you wanted, you could change the -eq (equals) to -like or -match to get more than just one VM.)

After running the code you just need to complete a stun/un-stun operation (in my case, I did a storage VMotion as I needed to move the VM to a different datastore anyway) and now we are in business.

Oh, and to keep the security people happy, I should mention that you need to change the FALSE values to TRUE and run the script again when you are complete. We wouldn’t want to allow future copy/paste operations now, would we?

Posted in Scripting, Virtualization | 2 Comments

View 5.0 Upgrade issues

Posted on October 2, 2011 by brian.wuchner

I recently upgraded a View 4.6 installation to 5.0. The update went pretty well until I went to update the View agent inside the desktop sources. The install kept failing with the following error message:

Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action VM_RegisterPcoipPerf32, location: ...\pcoip_perf_pr...

After a bunch of searching/testing, I finally realized that McAfee On Access Protection was blocking the ability for the composer agent to register as a service. McAfee exclusion in place, I continued to have issues with the installer, so I removed VMware Tools and cleaned up all of the VMware installer bits using the tool in this KB:

Cleaning up after an incomplete uninstallation on a Windows host (http://kb.vmware.com/kb/1308)

After a reboot I was able to install the View 5.0 Agent and then I finally re-installed VMware Tools and recomposed my desktops. Now for the next error, which showed up in the View Connection Server/Admin console after attempting to deploy these new linked clones:

View Composer agent initialization state error (-1): Illegal state (waited 0 seconds)

I couldn’t find much documentation on this error…but after searching through some of the agent logs, I realized that the “VMware View Composer Guest Agent Server” service wasn’t installed in my guest VM. It appears this option only exits in the View Agent installer if VMware Tools is already installed in the VM. Re-running the View 5.0 Agent installer gave me the option to install the composer agent and thin print support.

Lessons learned

  • Disable antivirus protection before starting View Agent upgrade
  • Install/Upgrade VMware Tools before View Agent
    • Posted in Virtualization | 1 Comment

    PowerCLI vCheck 5.45 – Updated export options

    Posted on September 27, 2011 by brian.wuchner

    I started working on this update in the airport the Sunday before VMworld 2011. It is only a minor update to exporting the reports and sending email notifications. In this update, all of the code to send emails and/or export reports has been moved to a function near the top of the code and at the very end of the script (where the export code used to be) I added a call to this function. I think it is now easier to see/edit/understand your output options.

    # Version 5.45- bwuch: Updated export options

    5.45 – Minor update to the Out-File and Send-MailMessage code; moved into a function in the “config” part of the script and then called from the end.

    You can download the updated version here: vcheck5.45.ps1

    Posted in Scripting, Virtualization | 2 Comments

    LDAP query performance

    Posted on September 18, 2011 by brian.wuchner

    The other day I was having a discussion with a co-worker about Active Directory performance related to standard LDAP queries. The complaint (and basis for my involvement in the discussion) was based around poor LDAP performance, which was assumed to be attributed to LDAP queries hitting domain controllers contained within virtual machines. This assumption was based on the fact that some queries completed quickly while similar queries were much slower. After some discussion, and viewing the queries, I believed the problem to be more likely attributed to poorly designed queries, so I set off to prove this with actual data.

    The queries included as part of this discussion were searching an attribute that was indexed and part of the partialAttributeSet (replicated to Global Catalogs). The queries that completed faster contained a specific value to search while the slow queries had multiple wildcards included in their value. To prove my hypothesis, I created a simple script to perform the same LDAP searches several times, some with specific values, some with a single wildcard and others with multiple wildcards:

    [cc lang=”powershell”]
    $report = @()
    for($i=1; $i -le 5; $i++) {
    $item = “” | select Count, SpecificValue, SingleWildcard, TwoWildcards
    $item.count = $i
    $item.SpecificValue = (Measure-Command { get-dn user mail “testuser@test.domain” }).TotalMilliseconds
    $item.SingleWildcard = (Measure-Command { get-dn user mail “testuser*” }).TotalMilliseconds
    $item.TwoWildcards = (Measure-Command { get-dn user mail “*tuser*” }).TotalMilliseconds
    $report += $item
    }
    $report
    [/cc]

    *Note: Get-DN is a custom function created by a co-worker. It is a PowerShell function I have loaded in my profile that performs a global catalog search. It builds the LDAP filter using three arguments: 1.) the objectCategory to search 2.) the attribute to search 3.) the value to search for in attribute.

    The results of the searchs can be seen below:

    Count SpecificValue SingleWildcard TwoWildcards
----- ------------- -------------- ------------
    1        9.5489         9.3398   11066.8601
    2        7.7018          7.335   11102.0755
    3        7.8635         8.3801   11067.5442
    4        8.0664         7.6145   11137.9768
    5       10.2233         8.9622   11132.9646

    The averages speak volumes about this test:

    Property : SpecificValue
Average  : 8.68078

Property : SingleWildcard
Average  : 8.32632

Property : TwoWildcards
Average  : 11101.48424

    As I expected, placing multiple wildcards in an LDAP search greatly impacts search performance — even if the attribute being searched is indexed. What I found somewhat surprising is that a single wildcard has nearly no impact on performance — actually in the test a single wildcard slightly outperformed the search of a specific value (but only by a fraction of a millisecond).

    I performed these same queries several times and hard-coded the server names to search to include 1.) physical GC only 2.) virtual GC only 3.) allow DNS to resolve domain name to obtain GC name. Each result set was very similar (within fractions of milliseconds) so I included the default result set where DNS resolves the domain name to obtain a GC.

    This article is filed under scripting (and not virtualization) because the results prove that using inefficient queries creates more impact on LDAP directory performance than whether you have physical or virtual domain controllers.

    Posted in Messaging, Scripting | 1 Comment

    Network configuration missing from ESXi host

    Posted on September 12, 2011 by brian.wuchner

    I came back from an awesome week at VMworld to find a very odd networking issue on several production ESXi 4.1 hosts. I first noticed that the hosts in question had an HA warning, so I attempted to ‘Reconfigure for VMware HA’ which resulted in the following error message:

    Cannot complete the configuration of the HA agent on the host. Misconfiguration in the host network setup.

    I decided to place one of the hosts into maintenance mode while I investigated this issue. This failed with several warnings during the vmotion operation(s): 

    The vMotion interface is not configured (or is misconfigured) on the Source host.
Currently connected network interface 'Production' uses network 'Production' which is configured for different offload or security policies on the destination host than on the source host.
The vMotion interface of the destination host uses network '<unknown network>', which differs from the network '<unknown network>' used by the vMotion interface of the source host.

    Image of vMotion error

    I then decided to check out the networking configuration to see what was going on. I clicked on the host configuration tab, then Networking and waiting. I never got more than the following screen — even after selecting ‘refresh’

    Thinking something wasn’t displaying correctly, I moved to the Network Adapter link. What I found there was even more alarming:

    Just for clarification, all six of those network interfaces should be assigned to vSwitches! The oddest part was the hosts still had active, running and responding virtual machines, but the host had no visible signs of network configuration.

    I then pointed my vSphere client directly at the host, thinking something was wrong in vCenter. No such luck, I received the same results. I enabled tech support mode and logged in through ssh. I then listed all of the vswitches using the following command:

    esxcfg-vswitch -l

    Fortunately, all of the vSwitches were still in tact — which explains how/why the VMs were still online. I then checked the esx config file to see if my NICs and portgroups were still properly defined:

    cat /etc/vmware/esx.conf |grep -i nic
cat /etc/vmware/esx.conf |grep -i portgroup

    Since everything was in order I went to the DCUI on the console and restarted the management agents on one host. A few seconds later everything was back in working order and I was able to re-enable HA. This was a very simple fix, but it is one of the weirdest network issues I’ve ever seen on an ESXi host.

    Posted in Virtualization | 5 Comments