Jul

12

2010

Desktop virtualisation is easy, yet hard

With RemoteFX becoming more of a reality, it got me thinking in to the way VDI is misunderstood and hyped.

As has been proclaimed before, VDI is seen as the silver bullet for IT’s desktop management woes. IT reclaims control of the desktop and therefore decreases opex whilst increases customer satisfaction/perception and everyone lives happily ever after. Almost. It’s only part of the puzzle.

To really make a virtual desktop solution sing, you need to concentrate on the user. Initially ignore the broker, ignore the hypervisor, ignore the infrastructure…. look at your applications, user profiles and user data and work backwards.

What is the point of having an elastic infrastructure that can weather the most demanding of user scenarios if your apps are still provisioned in an antiquated way.

What is the point of having the best protocol, so your user’s can enjoy YouTube during their lunchtimes if it takes them 30 mins to log on in the morning because their profiles are huge.

Not a lot…

Comments : (1)

May

13

2010

Don’t forget this…

AntiVirus isn’t glamorous. Therefore the this press release will likely be forgotten pretty quickly.

Summarised, it’s McAfee’s collaboration with Citrix to provide centralised protection for virtual desktops. This shouldn’t be underestimated.

This is just another step in abstracting another painful part of the user’s environment from the OS provider greater control, simplified creation and increased predictability of the end user experience. Apps, profile, files/data, and AV. What’s next?!

Comments : (0)

May

12

2010

Where art though CVP…

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?

Comments : (0)

Apr

29

2010

New kit, new kit, new kit

Having ordered a DataDomain DD880 with over 50TB of storage and having had it sat on the floor for a month, it’s finally in the racks – albeit with no power.

IMAG0053

We’ll be using EMC Networker with it and utilising 10GbE.

Expect further updates once it’s in.

Comments : (0)

Apr

26

2010

Integrating vCenter in to your own PKI

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.

Comments : (2)

Mar

31

2010

Introduction to the PCoIP Management Console

Last week I received a shiny Wyse P20 for a proof of concept using VMware View 4. Having been testing with Windows Embedded Standard Edition thin clients and standard desktop machines, I was keen to see how these Zero Clients compared.

image

Upon receiving the terminal, I downloaded the Teradici PCoIP Management Console. This software is actually a VMware workstation VM which a quick import in to vCenter sorted out.

After booting the VM, you’re presented with a fairly standard configuration screen to set the password, hostname, IP and so on.

image

Logging on with a web browser, the management console is fairly clean and simple.

image

The management is split in to three main components, devices, groups and profiles. The idea being that you assign a profile to a group – add devices to that group and the policy should cascade to the end client.

The end clients register with the management console by using a DNS-SRV record. Using Windows DNS, this can be set by creating a new record, selecting ‘Other New Records’ and then Service Location (SRV).

imageimage

The SRV record required the service name to be _pcoip-tool and the host to be populated with the hostname of the PCoIP Management Console.

Clicking Update DNS SRV records verifies that the DNS-SRV record is propagating.

image

The video below has a quick run through of adding a client, attaching a profile and a couple of other features.

The simplicity of this configuration is impressive – from never having touched a PCoIP thin client, I had it being centrally managed, with cascaded policies and automated firmware deployment within 30 minutes.

Next up is the actual performance review of the Wyse P20 utilising View 4.0 with PCoIP….

Comments : (4)

Previous