This post is the third in the series: Designing a Virtual Infrastructure that Scales.
In Part 2, Speak to the people, I went through some communication ideas to involve more people in the information gathering stage to ultimately be able to put together a better infrastructure
In this post I’m tackling the things you need to be thinking about when you consider VDI.
So…VDI, the promised solution to all your IT needs. No PCs on desks, thin clients, zero clients, happy clients, automated provisioning, stateless VMs, thin apps, streaming.
VDI is certainly a very different way of delivering IT to clients, it can be seen as terminal services on steroids, using some of the benefits of shared resources but allowing separation when you need it.
Why is VDI any different from just having VM workstations which people connect to?
This post is the second in the series: Designing a Virtual Infrastructure that Scales.
In Part 1, Taking Stock, I talked about looking at your current environment and seeing where you need to get to by doing a bit of crystal ball future capacity planning combined with understanding your current infrastructure limitations.
In this post I’m going to talk about something that isn’t done enough in infrastructure projects and that’s actually talking to real life people.
Many enterprise IT departments are pretty big places aften spread across the globe working in different timezones in multiple separate vertical silos. You quite possibly may not have met everyone in your own team let alone know what everybody else does in your office.
If you’re going to think about an infrastructure change to support a much bigger virtual environment, isn’t it worth looking at the really super-duper-bigger picture. Unless you know anything and everything (and there are some of you that may do!) you really should be getting other people involved from the very beginning to see if they would like to jump on the bandwagon and make changes to their environment for the greater good.
I recently had the privilege of presenting at the London VMware User Group meeting, #LonVMUG where I talked about some of the things you should be thinking about when scaling your virtual infrastructure.
I’ve turned part of the presentation into a series of posts, going through some of the aspects you should be considering when your virtual environment demands bigger, better, faster, more!
Part 1, Taking Stock
Part 2, Speak to the People
Part 3, Scaling for VDI
Part 4, Designing Thinking
Part 5, So, after all that…
Designing a Virtual Infrastructure that Scales: Part 1, Taking Stock
Going virtual is all about sharing resources. You are no longer constrained by one server or workstation running on one physical piece of hardware. The benefit is less physical kit to look after and better utilisation of resources but the detriment is when you share, you need to share nicely. In a shared environment one VM can be greedy and take more than its fair share and your other VMs suffer.
It’s not just sharing nicely that you need to consider but also building your VMs so they need less so there’s more to go around.
VDI is all about maximising the use of your physical hardware. To be cost effective (if you can with VDI!), you want to run as many workstations on a physical host as you can without sacrificing individual VM performance.
So, if your VMs are greedy with what they need you are going to be paying more for hardware. Wasting resources on physical workstations may not cost that much more but move your workstation into your datacenter and then see how much money you will be wasting.
VMware has released a new Broadcom bnx2x driver today and made it available through Update Manager.
The update looks like it fixes the critical issues referenced in my previous post.
What is very strange though is the 4.1 bundled version number was:
The new version number is:
See the difference, a small little 2. So this looks like a very minor release. What is the 1.60 driver all about then?
Does this minor 1.54-2 release fix the issues with the built in driver but not fix SmartLink / DDC. Does the 1.60 driver fix the issues with the built-in driver or just fix SmartLink / DDC?
I haven’t been able to find any more information on what the 1.60 driver fixes or breaks as there doesn’t seem to be any published information about it.
I’m very happy these drivers are now being released through Update Manager which is the easiest deployment method although you can still use PowerCLI to deploy them but why release 1.60 and then release 1.54-2 later?
I’ve said it before: Come on everyone…VMware, Broadcom, HP need to get together and sort this out!