ServrBasedComputing Vs VDI

[mreferre]

There have been some discussions lately about the differences (and value) of an SBC (Terminal Services) solution compared to a VDI solution.

VDI really has no "competition" when it comes to 1-to-1 mapping (i.e. private Guest images where the end-user could do whatever he/she wants) but when it comes to the usage of "VDI pools" some folks argue that the technical challenges associated to create a VDI pool are not much different compared to the challenges associated to a Terminal Services solution. Specifically you have to use roaming profiles in both cases, you need to lock down both the Terminal Services and the VDI pool vm's etc etc etc. On the other hand there is little to gain from a VDI pool deployment compared to a standard Terminal Services solution.

I don't want this to become the "Terminal Services Vs VDI" thread....... but yet I'd like to try to list a number of situations (that perhaps you bumped into) where a VDI pool solution would be much easier to implement and would be much more flexibile from an end-user perspective than a standard SBC solution.

Massimo.

[sgrinker]

Massimo

I do like the idea of the thread first off. In regard to implementations where this would be easier and more flexible in our eyes has always been developers, testers, and training rooms. Yes we could obviously create a SBC environment on the Citrix farm for a lot of the training needs (in fact I have on special occasions for certain needs), but the VDI solution would be so much better. It allows for each user to be able to work on their own system making changes as needed and doesn't require the locked down environment to the degree of TS/Citrix. Then if a machine gets to the point of no return, create a new VM using an already established template. Same would go for our software testers and developers, but that seems to be the most often reffered to case for VDI. We haven't gotten this implemented fully yet, but the early pilot showed good signs. We'll actually be starting up the larger project within the coming months.

As for both SBC and VDI, I think that software virtualization is going to be key as we move forward. The combination of roaming profiles, virtualized apps, virtualized OS/machines, and even down to vitrual drives (Ardence) will all begin to play a larger part in this world. Once all of these start to combine and meld even more, we should get to the point that a user could literally work from anywhere and get access to the same environment (or at least to some extent.) I know that this will never be 100% true for all apps in all situations, but there is just so much more possibility on the way in the not too distant future.

Steve

[paramd]

Even though conceptually pooled VDI desktops are shared across users and may need to be locked down, they offer better application compatibility than shared desktops in terminal services.

1) Better application to application compatibility

2) Better application to OS compatibility

Now, I know these are just regular advantages of VDI but they are even more valid in the pooled environment when compared to terminal services.

[djwoodard]

I'm considering VDI specifically because some of our apps will not work in an SBC environment. Seems to me that this could allow me to continue using low-maintenance thin client devices and still provide the necessary desktop to run legacy apps.

[mreferre]

Steve, I like the idea of "create a pool from a non locked-down template and let users use it .... when a vm gets to a point of no return you would re-provision it". Interesting. Well someone might argue that from a TCO perspective you would loose some advantages (you always would need to search for / respond to unusable vm's) and also the customization that a user did might get lost at the next logon due to the fact that in a pool he/she won't get the same vm (likely).

Just trying to do the "Devil's advocate" here ..........

Massimo.

[mreferre]

So what you paramd/djwoodard seems to be saying here is that ... the simple fact that VDI pooling requires the use of roaming profiles doesn't strictly mean that you will be facing all compatibility issues one would face in a Terminal Services environment. I agree.

So while Roaming Profiles introduce a certain level of complexity and application compatibility (i.e. I know of applications that do NOT store user-oriented settings where they should in the user Profile for example) the nature of shared and multinstantiated applications on the same OS (like in Terminal Services) introduces a much higher level of complexity and compatibility.

Makes sense.

If others have different angles of view or experiences please post .......

Massimo.

[sgrinker]

Massimo

All good points, and very true. Although in a training room scenario a user would typically use a machine for one "class" and then typically wouldn't need the same machine for the next class. This is of course assuming this class occurs in one session, and there will obviously be acceptions to the rule.

For us though the largest and best target for our first VDI group would be our software testers. We currently have individuals in all of our remote offices all around the nation that are part of our software testing team. When anything new is about to be released, they fill the role of one of our early pilot groups. Each of them currently has a secondary machine (in most cases a laptop) that can receive the changes in an isolated (non production) environment. Depending on the specifics these machines do need to be re-imaged from time to time. This either requires remote management on our part on all of the machines, or involving the local techs in each office. With VDI and the centralized management, we will be able to apply changes to these machines MUCH easier.

Although the scenario I just decribed does not necessarily lend itself to pooled VDI's in all cases, I tend to like the idea of pooled that become assigned in that case. I know a few brokers have that ability, but it's slightly different than the traditional pooled concept being discussed.

Steve

[sgrinker]

I agree, and in most cases you end up spending more money on additional servers in order to silo the applications in the SBC/TS/Citrix world. I'm speaking from experience on that one, as we tend to have a good number of servers that simply support 1-2 applications. We are moving a lot of these toward VM Citrix servers for obvious reasons, but still it requires an additional system.

On the contrast though switching to the pooled VDI concept means more management of multiple machines. Realistically this isn't an issue if you have good enterprise management solutions in place. However, it does bring is back to the TCO converstation. I still think that application virtualization will lend itself to helping both VDI and SBC as it is able to address application compatibility at a whole new level. Of course I don't think it's completely there yet, so can't be considered a complete soution... yet.

Steve

[dsalinasd]

My take on this is..The steps to move the user community to a pooled desktop is very similar in the steps to move the user community to a locked down desktop, which is some of the same steps to move to a Server Based Desktop (either Citrix or Terminal Services). We have struggled for years to take away user power/admin rights, ie take away the users ability to install their own applications. In the pooled VM, as well as Server Desktop, you have the same situation, a user cannot install their own software., ie user revolt.... If the promises of Softricity, Citrix Streaming, AppSream, etc application virtualization are true then compatibility issues on Server Based Desktop are gone. Which leads me back to, why would you want to do a Pool?

I agree with sgrinker about the use cases for developers and testing to have VM Pools for sure, but small amounts of use cases ..Also, Brian Madden makes more points on this on http://www.brianmadden.com/content/content.asp?id=682 ... I don't know if 2-4% of user cases in a particular company though..That seems very low..

I can totally understand the Private VM model though where you can support an end user that needs/must/and probably most likely wants to install their own software. That to me is the power of VDI. If only we can get that model optimized where the disk isn't the size of a desktop disk times the number of users, plus we can patch a Private VM in one spot, versus patching X hundreds of VMs, then I think VDI will fly..Something like Ardence or Neoware Image Manager (Qualstyem) or Wyse Image Manager that supports a persistent updatable cache of OS Stream disk..

[sgrinker]

Brian Madden just posted a "part II" of the SBC, VDI, Streaming article...

http://www.brianmadden.com/content/content.asp?id=685

[CoreyIT]

Although this is an old post I would like to bring this back to the front for further collaboration. I am curious what those with experience and some time under their belt now have to say, with VDI having become more prodiminent in the past year.

From a business case scenario and administration standpoint I have a hard time seeing how VDI is really that much more advantages over a TS environment. Here's why:

With a TS environment you are managing a much smaller pool of applications. In other words you are only managing the applications per terminal server and not per virtual instance of a users desktop. In other words, using VDI still requires the expenses of an application management product such as Altiris or Microsoft's System's Center for software deployment, patching and metering.

I have a hard time understanding how just deploying thin clients pointing to a virtual desktop is really saving that much money. For example in our TS environment we have been simply turning older systems into thin clients or removing all applications and only leaving rdc or the citrix ica client. Basically turning the machines into dummy terminals. As these machines die we replace them with thin clients. As far as savings in power goes...I have a hard time seeing the true benefits with so many other power hungry devices in a building such as general AC, heat, ceiling fans, desktop lamps, space heaters, fridges, internal lighting, etc.

Thirdly, is support. Support in my opinion is still no easier. Most issues stem from software. In which case it still requires a visit to the desk. If a support tech takes control they either block the user by using an rdc session, or you are paying to use a third party support product for remote control. In most cases I would NOT have my desktop admins access to the VI client to take direct console control on VM's anyhow.

Fourth is space requirements. A lot of space requirements. You are now not only saving users data to the network you are saving their vd as well. Now I understand and appreciate the use of templates but that is not always a viable option if spreading that across a cluster. So now you are going from mere megabytes in some cases to gigabytes of storage space requirements.

Scalability. We are able to run 30-50 on most of our TS and citrixservers. They are average machines - quad cores with 16-24gb of memory, but compared to the cost of esx licensing, windows OS licensing and then the heavier hardware requirements to run those VM's..and getting maybe half the connections....again its kind of hard to justify. In our environment we run clustered and load balanced configurations which eliminates the spof.

Now with that being said there certainly is a place. Software development, testing and qa. And instances where software is incompatible with a TS based environment. I would however think that in most environments this more of a rare one of occassion then a common fact.

Im not against idea..since we have about 50 client os instances hosted in our esx environment for dev and qa. I just wanted to share my experiences and opinions and see how others felt.

[TomHowarth]

Although this is an old post I would like to bring this back to the front for further collaboration. I am curious what those with experience and some time under their belt now have to say, with VDI having become more prodiminent in the past year.

From a business case scenario and administration standpoint I have a hard time seeing how VDI is really that much more advantages over a TS environment. Here's why:

With a TS environment you are managing a much smaller pool of applications. In other words you are only managing the applications per terminal server and not per virtual instance of a users desktop. In other words, using VDI still requires the expenses of an application management product such as Altiris or Microsoft's System's Center for software deployment, patching and metering.

Not true, VDI desktops are deployed from a preconfigured template. also there is not of the applications compatibility issues surrounding TS environments under VDI as VDI is a 1 to 1 relationship.

I have a hard time understanding how just deploying thin clients pointing to a virtual desktop is really saving that much money. For example in our TS environment we have been simply turning older systems into thin clients or removing all applications and only leaving rdc or the citrix ica client. Basically turning the machines into dummy terminals. As these machines die we replace them with thin clients. As far as savings in power goes...I have a hard time seeing the true benefits with so many other power hungry devices in a building such as general AC, heat, ceiling fans, desktop lamps, space heaters, fridges, internal lighting, etc.

your deployment method is just as valid under VDI. please do not confuse VDI with VDM, VDI is a concept and can utilist any number of brokers of which VDM is only one. removing 1000 PC desktop devices from the environment and replacing them with TC will significantly reduce the power comsumption of a building even taking into account the increase heat generation of the ESX Hosts.

Thirdly, is support. Support in my opinion is still no easier. Most issues stem from software. In which case it still requires a visit to the desk. If a support tech takes control they either block the user by using an rdc session, or you are paying to use a third party support product for remote control. In most cases I would NOT have my desktop admins access to the VI client to take direct console control on VM's anyhow.

Dameware. VNC. into the template is deployed as the XP guest is provisioned

Fourth is space requirements. A lot of space requirements. You are now not only saving users data to the network you are saving their vd as well. Now I understand and appreciate the use of templates but that is not always a viable option if spreading that across a cluster. So now you are going from mere megabytes in some cases to gigabytes of storage space requirements.

the use of NetApp Thin Lun Provisioning can significantly reduce storage sizes

Scalability. We are able to run 30-50 on most of our TS and citrixservers. They are average machines - quad cores with 16-24gb of memory, but compared to the cost of esx licensing, windows OS licensing and then the heavier hardware requirements to run those VM's..and getting maybe half the connections....again its kind of hard to justify. In our environment we run clustered and load balanced configurations which eliminates the spof.

there are many applications that cause significant issue under a TS environment, there are alievated with the deployment of Virtualised Desktops. A similarly speced Quad core ESX host could probably run a similar amount of XP guests, remember that there is a lower memory requirement. .

Now with that being said there certainly is a place. Software development, testing and qa. And instances where software is incompatible with a TS based environment. I would however think that in most environments this more of a rare one of occassion then a common fact.

Im not against idea..since we have about 50 client os instances hosted in our esx environment for dev and qa. I just wanted to share my experiences and opinions and see how others felt.

Tom Howarth

VMware Communities User Moderator

[tarnett]

One thing that made our choice easy in this was we used TS/Citrix and they were great. But if you loose the citrix box every user is affected. I have had users crash their vm and it only affected the user not all 50. Now with that being said this would be the same as loosing a host. From my experience that has only happend a few times. I think the argument is valid but when you take into account the upfront cost of citrix I still think VDI/VDM is going to be more cost effective.

Tony Arnett

Sr. System Engineer

Pentair Water Pool and Spa

1620 Hawkins Ave.

Sanford NC, 27303

Office: 919 566 8003

Fax: 919 566 8910

tony.arnett@pentairwater.com

[CoreyIT]

Not true, VDI desktops are deployed from a preconfigured template. also there is not of the applications compatibility issues surrounding TS environments under VDI as VDI is a 1 to 1 relationship.

I am perplexed by this statement. Either you have little experience in an enterprise setting or you are mistaken. Do you honestly think that rolling out a new VM from a template to each user every time you apply a patch to a piece of software, upgrade a package, make a configuration change or bring new software into you enterprise is the answer? If you have more then a couple hundred users I can guarantee you are going to be looking at software management packs for rolling out and standardizing application delivery across your clients. In a terminal services environment you might have a handful of instances of an application which can be administerd one to one. In a VD environment that is no different then having individual workstations that need to be managed and secured. The licensing costs for these management suites are astronimically ridiculous. And so is the licensing costs for one to one ratios (which you can get discounts for TS environments) and OS licenses vs. per user licensing.

By the way,in 15 years of working with Terminal Services, Citrix and 2x I have come across very few instances where applications that were incompatible with a TS environment. In almost all cases where they were not it was because of basement programming - in which case I share no sympathy for the readily documented structure for correctly writing a program to work in a TS environment. And I am not talking about some software which is just limited in nature such as cad or graphic packages. Not all software has a place in this kind of environment anyways.

Aside from that there were some other valid points, but your first comment...I dont know.

[TomHowarth]

Not true, VDI desktops are deployed from a preconfigured template. also there is not of the applications compatibility issues surrounding TS environments under VDI as VDI is a 1 to 1 relationship.

I am perplexed by this statement. Either you have little experience in an enterprise setting or you are mistaken.

I find this statement rather offensive. I have not questioned your ability or previous experiance. for your information I have significant experiance in an Enterprise. but that is irrelevant.

Do you honestly think that rolling out a new VM from a template to each user every time you apply a patch to a piece of software, upgrade a package, make a configuration change or bring new software into you enterprise is the answer?

And how do you do it is your current enterprise, either by visiting every desktop with a disk or via RIS or another deployment method if this infrastructure is in place you reuse your previous investment. another advantage is the machine can be left running without incuring extra power cost enabling updates to be run out of hours, rather than having then run on a users login causing poss of work during the standard working day. and yes your above comment is exactly what I would do in a non persistant pool.

If you have more then a couple hundred users I can guarantee you are going to be looking at software management packs for rolling out and standardizing application delivery across your clients.

You have obviously missed the point of none-persistent pools.

In a terminal services environment you might have a handful of instances of an application which can be administerd one to one.

I would be putting alot more revision testing into patching and managing a TS environment than a VDI environment.

In a VD environment that is no different then having individual workstations that need to be managed and secured.

True but a correctly configured Template and Security GPOs will lessen that. in a secure enterprise this would be the case anyway. this is also the case in a TS envrionment or do you not think that is the case? and you have no requirement for AD fudges like loopback policies.

The licensing costs for these management suites are astronimically ridiculous. And so is the licensing costs for one to one ratios (which you can get discounts for TS environments) and OS licenses vs. per user licensing.

Agreed on Licensings cost, but these are dropping. and you get less of the TS kick back from users.

By the way,in 15 years of working with Terminal Services, Citrix and 2x I have come across very few instances where applications that were incompatible with a TS environment.

You have been very lucky. in my experiance of TS, and Citrix (since WinVeiw) I have had to shoehorn many none compatible stragegic (to the client) applications onto TS.

In almost all cases where they were not it was because of basement programming - in which case I share no sympathy for the readily documented structure for correctly writing a program to work in a TS environment.

So you have never dealt with the majority of HR and payroll applications;), You would get short shrift as a consultant with that attitude. it may be ok as a enterprise support operative. but to "Share no sympathy" If I was a client I would soon show you the door.

And I am not talking about some software which is just limited in nature such as cad or graphic packages. Not all software has a place in this kind of environment anyways.

CAD and Graphic applications are excepted.

Aside from that there were some other valid points, but your first comment...I dont know.

Tom Howarth

VMware Communities User Moderator