Where art though CVP…

Category : Citrix, VDI, VMware, View

Caught a tweet from @robupham to @tom_howarth today regarding Citrix Synergy and it startled me somewhat. Enough to write about it anyway – it regards the announcement of Citrix XenClient.

image

Last year, VMware announced the Client Virtualisation Platform (CVP). A type 1 client hypervisor to go head to head with XenClient. 15 months later, XenClient is here but it’s pretty quiet on the CVP front. Annoying because I see the client hypervisor as one of the boons for a VDI deployment.

As has been stated many a time, the Capex arguments for VDI are non existent. It’s all about Opex. In the Enterprise, I see the client side hypervisor as greatly reducing the costs related to desktop/laptop lifecycles.

By abstracting the user’s environment from the hardware, lifecycle management becomes a case of waiting for the courier to deliver the replacement. No acceptance testing, no imaging or pre-staging. Glorious.

In addition, there’s also the promise of near native desktop performance using the client hypervisor. Sounds like a win win.

The problem is, without CVP, we’re left with offline/local desktops in View. This is all very good if you use a BYOPC model, but if you don’t have this, the management overhead per user doubles. Two OS deployments (updates, troubleshooting et al), two copies of AntiVirus and likely duplicated applications. That sounds like a nightmare scenario to me.

Which leads me back to the original tweet. Having tested both XenDesktop and View, my experience is that XenDesktop is more mature and has a far greater feature set but View has a better core infrastructure and is far more simpler. VMware are adding features so that they can ‘catch up’ to Citrix, but with announcements like this and huge gaps in the View product set (remote access, end point performance tracking, etc), it feels like VMware are constantly one step behind at the moment.

Therefore I can safely say, I’m a VMware customer and I want a client hypervisor. Am I alone?

Integrating vCenter in to your own PKI

Category : VMware, vCenter

I am rebuilding one of my vCenter installations at the moment to split out all the subcomponents (SRM/VUM etc) in to separate VMs for scaling. One of the actions for this project was to integrate all components with our internal CA.

After reading VMware’s own document on the subject and Derek Seaman’s blog on the subject, I gave it a go.

First thing’s first, download OpenSSL from here. You will need to install the Visual C++ Redistributables first and then OpenSSL Light install. By default, this will install to C:\OpenSSL.

Within C:\OpenSSL\bin, create a file called openssl.cnf

[ req ]
default_bits = 1024
default_keyfile = rui.key
distinguished_name = req_distinguished_name
#Don’t encrypt the key
encrypt_key = no
prompt = no
string_mask = nombstr
[ req_distinguished_name ]
countryName = US
stateOrProvinceName = California
localityName = Palo Alto
0.organizationName = VMware, Inc.
emailAddress = ssl-certificates@vmware.com
commonName = vCenter.domain.local
subjectAltName = vCenter

(where vCenter.domain.local is the FQDN of your vCenter server and vCenter is the hostname)

Open command prompt, browse to a directory in which you want to save the files temporarily and create a certificate request by typing the following:

c:\openssl\bin\openssl.exe req -new -nodes -out rui.csr –config c:\openssl\bin\openssl.cnf

image

rui.key and rui.csr will be created within your temp directory. Open rui.csr with notepad and copy the text. This text will be used to request the certificate from your CA.

Open a browser, point it to your CA and select ‘Request a certificate’ then ‘Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file…’.

Paste the contents of rui.csr in to the Saved Request window and ensure the certificate template is set to Web Server (this template must support a minimum key size of 1024 or less!). In the additional attributes field, enter the following:

san:dns=vCenter.domain.local&dns=vCenter

(where vCenter.domain.local is the FQDN of your vCenter server and vCenter is the hostname)

Submit this then download the certificate (not the chain) with Base64 encoding. Save it in your temporary folder as rui.crt. Run the following command:

c:\openssl\bin\openssl.exe pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Within your temp folder, you should have the following files.

image

Stop the VMware VirtualCenter Server Service and browse to your VMware vCenter SSL certificate folder (by default – C:\Users\All Users\VMware\VMware VirtualCenter\SSL in Server 2008 and C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL in Server 2003). Back up all the files in this directory to somewhere safe.

Finally, copy rui.crt, rui.pfx and rui.key from your temporary location to the VMware SSL folder. Following this, from the VMware vCenter installation direction (in my case c:\Program Files (x86)\VMware\Infrastructure\VirtualCenter Server), run vpxd.exe –p. This prompts you to reset your DSN password to the vCenter database based on the new certs, if you don’t do this step, the service won’t start. Restart the VMware VirtualCenter Server service. As long as the certificates are correct, the service should start. If it doesn’t, check the log files for further info and at worst case, roll back your certificates.

From a client with your root cert installed, browse to your vCenter server from your browser, you should receive no certificate errors using either the FQDN or the hostname. To further test it’s working, log on with the vCenter client – you should get no more annoying certificate errors!

Next up is SRM, VUM and ESXi certificate configuration.

resxtop and disk adapter counters

Category : ESX, ESXi, VMware

Run in to a small bug using resxtop within the VMware vMA.

When looking at disk adapter information, all counters for non local adapters display as 0. This is the same in ESX and ESXi.

image

I’ve raised this as an SR with VMware and they have replicated the issue in their labs and passed it to Engineering. I’ll post an update when I get one.

Slow ESXi boot from cold or standby

Category : ESXi, VMware

Ran in to an issue before Christmas whereby ESXi would take over 10 minutes to boot. The issue appeared to be with regards to certain LUNs timing out during the rescan operation.

Upon further investigation, the LUNs causing the issue were RDMs connected to a MSCS cluster. The workaround for this was to set the Scsi.UWConflictRetries from 1000 (default) to 80. Whilst this shortens the boot time, it’s still relatively long and really worrying when utilising DPM.

KB1016106 covers this topic in full.

View 4.0 – black screen upon login

Category : VDI, View

I’ve been running a proof of concept lately with View 4.0 and Windows 7 and have had a constant showstopper issue (experimental… I know!).

Using PCoIP, 80% of the time when the end user logs in they will be greeted by a black screen for a couple of seconds and then the session will quit. Logging back in works as normal.

Looking at the View 4.0 release notes there are a few mentions of black screens but only one relevant to Windows 7:

When View Client attempts to connect to a Windows 7 desktop using PCoIP, a blank black screen will appear instead of the Windows Security dialog box if the Windows 7 desktop fails to perform single sign-on, for example, if the desktop does not join the domain.

At first, I thought this issue may have been one with my template and not deploying properly through Composer, but after testing through the console this was quickly ruled out.

With the release of View 4.0.1 comes a rather interesting KB (KB1016961) from VMware.

This KB refers to the same SSO issues mentioned above but this time indicates that a legal disclaimer can trip up the SSO process! The workaround is to disable any disclaimers.

Definitely one that will trip up a few POCs up in the early stages I feel.