I have an idea...can it work?

sabregen

sabregen

Fully [H]
Joined
Jun 6, 2005
Messages
19,501
I've got some interesting clients at work. Many are migrating off of old systems, and are looking specifically at ESX/vSphere 4 implementations on a variety of hardware. One of the things that keeps coming up is the ability to do desktop virtualization (which, of course, we can already do), but in a very specific way. Here's the basic idea:

IBM BladeCenter H Chassis
- quad 2900w PSUs
- dual copper Passthrough modules (for 10GbE connectivity to blades)
- dual optical passthrough modules (for 4Gb FC SAN connectivity to blades)

IBM BladeCenter HS22 blades
- dual Intel Xeon Quad 2.93GHz
- 48GB PC3 per blade
- 4Gb QLogic FC dual port HBA (expansion slot 1)
- 10Gbps dual port NIC (expansion slot 2)
- boot from SAN

IBM DS5300
- dual PSU
- dual controller
- 4Gb FC host connectivity
- 60TB 15k storage

QLogic 5802v's
- 4Gb FC SFPs for now
- 2+2 stack with 20Gbps ISLs

vSphere 4
- ESX host machines (HS22's) boot from SAN
- no local VMFS3 partition in the default 5GB boot LUN
- resource pool by department
- HA, DRS, vMotion, Storage vMotion, vServer implementation

Thin client terminal at the user desk
- on users desks
- physical connectivity would likely be 1Gbps SX optical to network switches
- needs to be able to integrate seamlessly with vSphere / vDI (or whatever they're calling it now)
- user environment automatically provisioned at thin-client power-on

The last line item is the big part. The rest of it, I know how to do. How do we get a thin client, or terminal to automatically fire up a Vista/XP desktop user environment beingrun under vSphere4, and automatically save/turn off that VM when the user is done (logs off, turns off terminal....whatever)? Can this be done?
 
Last edited:
You buy VMware View and use an automatically provisioned pool. When the user logs in it'll spin up a new desktop. When they log off you set the pool to power down the VM..or put it in suspend. vSphere does not work with View right now. That will come later this year..so for now you have to use VI3.
 
I hear what you guys are saying, and I understand that View would likely solve the issue. However, with most thin clients being PXE or otherwise network booted devices....how would the back end work? Here's my thoughts, so far:

Blades > SAN > running vSphere 4 >Resource Pool with FT enabled for PXE boot servers

PXE boot servers give out network images based on user authentication, which is SLDAP backed

SLDAP login on terminal device pulls down network environment for the user, whatever terminal they log into, giving them the ability to roam to any device they like, or are authorized on.

It would be ideal to leverage View to do this, but given that the terminals/thin clients are almost always PXE booted, how could View be used? Anyone have an idea? I'm certainly open.
 
why do you need pxe boot?
Use a wyse terminal or the like, or whatever system they have lying around as a thicker client.

edit: the vms are linked clones.
 
Shouldn't the desktop broker do this through the authentication anyways?

ie hrgoon1 logs into the broker, hrimage1 fires up a vm.

or accmathlete4 logs in and acctimage2 fires up.

What are the thin clients vendors? Wyse clients support PXE boot. The PXE config for the thin client should just pop up the desktop broker login.
 
I don't know what isn't clicking in my head. It's like I need a picture drawn, and I ate all of the crayons. Anyone want to get technical for me, and give me the backend workings explaination?
Posted via [H] Mobile Device
 
sabregen said:
I don't know what isn't clicking in my head. It's like I need a picture drawn, and I ate all of the crayons. Anyone want to get technical for me, and give me the backend workings explaination?
Posted via [H] Mobile Device
Click to expand...

lol. Sure - tomorrow. I just had to transfer a call, and it took over 30 minutes. I'm dead.
 
I think you will need 2 PXE servers, 1 to manage the View brokered sessions, and another to control the thin client configuration.

You could manually configure the thin clients to launch the broker.
 
geiger said:
I think you will need 2 PXE servers, 1 to manage the View brokered sessions, and another to control the thin client configuration.

You could manually configure the thin clients to launch the broker.
Click to expand...

The view sessions do not need a pxe server. Their "pxe" server is the ESX host itself, and linked-clone vms.
 
You're overcomplicating this. View is an overlay to ESX and, really, Virtual Center. It provides a broker, the Connection Server, between the desktop VMs and the clients. It doesn't use PXE to spin up desktop VMs. Other products, like Citrix XenDesktop use Provisioning Server which does this, but VMware's solution is much simpler.

To build a desktop image you create your template VM, just like you always do, then take a snapshot. When you create your desktop pool you tell that pool which snapshot to use. When a new desktop VM is spooled up it is based on the snapshot and therefore uses very little disk space for each desktop VM.

User logs in to the thin client (or software client). They authenticate against the Connection Server/Broker. Broker enumerates their group membership in AD. Matches group membership to available pools. Gives the user a list of pools. User picks one. Broker looks to see if there is an available desktop VM in that pool. If there is the broker points the client to that VM and off you go. If not the broker tells Virtual Center to spin up another desktop VM (again..based on a snapshot). Once that VM is up the client connects. No PXE. No streaming a boot OS to a VM. It's all done inside ESX/Virtual Center.
 
NetJunkie said:
You're overcomplicating this. View is an overlay to ESX and, really, Virtual Center. It provides a broker, the Connection Server, between the desktop VMs and the clients. It doesn't use PXE to spin up desktop VMs. Other products, like Citrix XenDesktop use Provisioning Server which does this, but VMware's solution is much simpler.

To build a desktop image you create your template VM, just like you always do, then take a snapshot. When you create your desktop pool you tell that pool which snapshot to use. When a new desktop VM is spooled up it is based on the snapshot and therefore uses very little disk space for each desktop VM.

User logs in to the thin client (or software client). They authenticate against the Connection Server/Broker. Broker enumerates their group membership in AD. Matches group membership to available pools. Gives the user a list of pools. User picks one. Broker looks to see if there is an available desktop VM in that pool. If there is the broker points the client to that VM and off you go. If not the broker tells Virtual Center to spin up another desktop VM (again..based on a snapshot). Once that VM is up the client connects. No PXE. No streaming a boot OS to a VM. It's all done inside ESX/Virtual Center.
Click to expand...

Me mumbles about needing coffee, and points at this.

The one additional thing - if you want, many use things like a Wyse terminal (a monitor/keyboard/network connection to a view session) to connect to view, which DOES pxe boot it's minimal OS, but that's not required either.
 
sabregen said:
found this: http://www.wyse.com/solutions/vmware/index.asp

Looks good. Part of my personal issue with the model is that I've never deployed on thin clients....so I'm trying to wrap my head around it.
Click to expand...

They boot some minimal login manager and ask for a user/pass, that's about it - then they simply go straight out and connect via a pseudo-rdp session to an ESX VM, and use that as an actual desktop. They're nothing more than an RDP terminal :)
 
lopoetve said:
They boot some minimal login manager and ask for a user/pass, that's about it - then they simply go straight out and connect via a pseudo-rdp session to an ESX VM, and use that as an actual desktop. They're nothing more than an RDP terminal :)
Click to expand...

Right. They present a windows-like login box. User logs in.. Authentication passthrough happens in the background. Really nothing to it. There is usually a thin-client manager app which handles firmware updates and stuff to them, but doesn't worry about the day to day usage.
 
You must log in or register to reply here.
Back
Top