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…

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?!

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?

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

Expect further updates once it’s in.

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

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.

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.

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.

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

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).

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.

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….

Back in the day (by that I mean 24 months or so ago), Data Centre FUD was pretty easy to weed out and could generally be taken with a pinch of salt.

Servers were a capex based commodity to run workloads, network for a lot of people began and ended with Cisco, people had began to clamber towards VMware for their hypervisor and generally the only pre-sales with a bit of bite came from the storage industry due to products actually having fundamental differences.

Life was simple.

Skip forward to today and the proven performance and reliability of the type 1 hypervisor has enamoured many a business. Only your rarer, super low latency apps tend to cause of sharp intake of breath from your virtualisation admin. To many, this means that the dream of a 100% virtualised Data Centre is a real possibility.

Gone are the days of disparate components. The talk now is about the full stack and the additional integration and simplified management that it can bring. No longer is the stack just a sum of it’s parts, it has to be more (think Power Rangers and Megazords!).

Sounds good doesn’t it? It is. However for customers, it’s a double edged sword.

There must be a far greater understanding of how each piece fits together that some smaller (and larger) organisations simply won’t have. Without this, unscrupulous salesmen can potentially spread FUD and influence decisions that may stop customers receiving the full benefits that their investment should bring. This isn’t necessarily from a technical standpoint – most vendors are good for this – it’s operational and should not be underestimated when it comes to the TCO of the system.

Ultimately, this FUD may stop a good investment from being a great investment. And that annoys me.

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

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.

First things first, I have no real world experience of UCS, but I have deployed a few C7000s. This is my get out of jail clause in case some of my UCS information is incorrect.

The report pits a HP C7000 with 6 BL460c G6 blades and one Flex-10 Ethernet Module against a Cisco UCS 5108 chassis with 6 B200 blades, two UCS 2100 Fabric Extenders in an active/passive configuration and a UCS 6100 Fabric Interconnect. The purpose of the report is to compare the available network bandwidth for bi-directional server to server transmissions in both a physical and virtual environment. It is worth noting that the report is sponsored by HP.

The C7000 blade chassis has 16 half height slots and eight backend IO slots. Each half height blade has two onboard NICs and capacity for one dual port mezzanine card and one quad port mezzanine card. The onboard NICs on G6 blades are 10GbE Flex-10 capable.

As can be seen in the diagram above, the onboard NICs map to bays 1 and 2, Mez 1 to Bays 3 and 4 and Mez 2 to Bays 5, 6, 7 and 8.

Having one Flex-10 Network module provides 10gb IO to each NIC with up to 4 virtual ‘FlexNICs’. Each FlexNIC can be carved from the physical NIC and dedicated a variable amount of bandwidth carved from the 10Gb. This module also provides a maximum of 8x10gb uplinks.

The UCS 5108 blade chassis has 8 half height slots and options for up to two UCS 2100 Fabric Extenders. Each Fabric Extender has a maximum of 4x10Gb uplinks but don’t forget, for this report, they are configured as active/passive. Each half height blade is pinned to one of these uplinks statically. Tolly had populated slots 3 to 8. In addition, it is worth remembering that all traffic from a blade has to be passed through the Fabric Extender (UCS 2100), up to the UCS 6100 and back down again.

To sum the test conditions up, the C7000 has a dedicated 10Gb port per each of the 6 blades, direct to the Flex-10 Network Module – that’ll be a 1:1 ratio right? The UCS 5108 has four 10Gb links up to the UCS 6100 to support 6 blades – or 1.5:1. This seems slightly skewed already.

Delving further in to the report (as much as you can delve in to 6 pages), two tests have been conducted. A physical to physical test and a virtual to virtual test. Baselines were conducted by sending traffic from an appointed blade to another in the chassis. Tolly levelled the Cisco test up by using blades 3 (Uplink C) and 5 (Uplink A) as well as 4 (Uplink D) and 6 (Uplink B). As these run on different uplinks, they receive dedicated bandwidth. Incidentally, Cisco won this baseline test by a “Doesn’t make a different in the Real World” margin.

Following the baseline, traffic from blades 7 (Uplink C) and 8 (Uplink D) were introduced. These share uplinks with blades 3 and 4. Contention you say? Surprise, that’s what Tolly’s results captured too!

For the virtual to virtual tests, virtual machines were VMotioned from blade 3 (Uplink C) to blade 5 (Uplink A). Again, Cisco won this baseline. They then conducted a migration between blade 3 (Uplink C) and blade 7 (Uplink C). Guess what they found. More bandwidth contention.

If you haven’t guessed it yet, as an HP customer, I find this report disappointing and bordering on insulting. It is based on the fact that all traffic occurs inside a single chassis and that active/active is the devils work. Can anyone point me to an Architect who has designed a production solution to run inside a single chassis please? No? Oh.

The fact that the uplink ratios aren’t equal off the bat is also dubious. “But we used 6 blades for both environments, that’s equal!”. Yes, but one chassis supports twice the amount of blades the other does, try it on a C3000 (NICs 1 and 2 on a C3000 go in to the same bay….). Why not use two Fabric Interconnects like any normal prod environment would?

In a proper production environment, communication occurs between blade chassis. This means uplinks to the aggregation layer must exist and with it comes contention. It isn’t a bad thing, it’s life. However this report makes it seem the work of the devil.

Let’s do some basic maths. A C7000, fully populated with half height blades will have 16x10Gb ports to the Flex-10 Network Module in Bay 1. I see that as 160Gb. Each Flex-10 Network Module has 8x10Gb uplinks. I see potential contention there.

But wait! You could be really smart and add a second Flex-10 Network Module to Bay 2. Each BL460c already has dual onboard 10Gb Flex-10 capable NICs. That way you could run 8 blades active/passive to bay 1 and 8 blades active/passive to bay 2. With 8x10Gb uplinks from each, you could truly achieve a 1:1 ratio to the aggregation layer. High 5! I’m trying to forget the fact I need to raise a PO to cover the 16x10Gb aggregation ports per blade chassis. And don’t tell me I could just utilise the internal 10Gb horizontal stacking between the bays as this might lead to contention!

The point is, bandwidth contention under certain conditions is always a risk depending on your cost, performance and availability requirements. All this test is showing me is that under certain configuration and loads, UCS can run in to contention. That’s fantastic, but I can prove this on a C7000 too.

What this test isn’t showing me is the apparent operational benefits of HP’s Bladesystem. That’s what I want as a customer. My problems are not one of tech they are operational and this is seemingly what Cisco are aiming to help me with. Oh well HP, it was a nice headline and any PR is good PR apparently. However, this customer has learnt far more about UCS by investigating these claims and I likes it. I likes it a lot [sic].