View question

[abouaicha]

Do All the Thin Clients have to have their own VMs?

How and Who assigns IPs to Thin Clients?

When Thin Clients get their Image, does the Image assume the IP address?

Do all Thin Clients have to have a VMs associated with it?

In terms of Antivirus patching is done only to the master VM?

Thank you for clarifying...

[tacticsbaby · Accepted solution]

Lots of good questions. Lets try to answer them one by one.

Q: Do All the Thin Clients have to have their own VMs?

A: No, unless you use your thin client as a kiosk you may have multiple VMs. Think of the VM as being attached to the user. If the VM is persistent then that VM and any others that are used by a user become his and he will get the same VM every time he logs into a persistent pool.

Q: How and Who assigns IPs to Thin Clients?

A: Assigning an IP to a thin client is the same as a regular desktop. You may use DHCP or static IP and assign either in the same way you manage your regular desktops. Remember you will still need an IP for the VM itself.

Q: When Thin Clients get their Image, does the Image assume the IP address?

A: All a thin client is doing is connecting to the VM in your data center. As I stated in the previous answer you will need to assign an IP address to the VM as well either through DHCP or static IP in the same manner in which you manage your physical desktops.

Q: Do all Thin Clients have to have a VMs associated with it?

A: A thin client is just a connection device for the end user to access the VM. For the most port there is no VM assigned to the thin client. As the administrator you create the desktop pool, entitle users and then the users connect to the VMs in the pool through the thin clients. In most cases, a thin client is no more connected (meaning assigned) to the VM than your TV at home is connected/assigned to your favorite tv show.

Q:In terms of Antivirus patching is done only to the master VM?

A: This is the subject of a rich and lively discussion. If you use full virus scan clients on your VMs I believe you could update them by doing updating the Defs in the master image and doing a recompose to deploy them to the pool. You could also set you clients to update after hours to save on bandwidth. In our environment we are going to use McAfee MOVE. MOVE allows us to shrink the memory and CPU requirements for AV in our environment by being optimized for virtual environment. Hence the name MOVE --- McAfee Optimized for Virtual Environments. This way you put the scanning engine and definitions on a virtual appliance and thin AV clients on your VMs. This can help you run more VMs on each host.

You are welcome and I hope I have helped. Good luck with your project.

[abouaicha]

Great information,

One more think. if I have a project for 1000 seats should I have 1000 VMs? (knowing that only 70% of users/TCs will be connected at one time should I just count for 700 VMs?)

Thanks in advance

[mittim12]

If you are using floating pools then you only need to account for the concurrent users.   If using floating pools you will definitely need to consider some type of profile management tool.

[abouaicha]

One more clarification: The VM needs to have an IP address and the TC will be assigned an IP via DHCP/Static... when the TC is assigned to the VM, does the VM lose its original IP and is now presented with IP the TC was assigned ? still not clear.  Thanks

[tacticsbaby]

If you have a requirement for 1000 seats then you will need 1000 VMs. However since you said that at any given time only 700 of that 1000 will likely be using a VM. There are a number of things to consider here:

1) Of those 700 users what is the turn over? What I mean is that if 700 of the 1000 users logged in at say 8 am, how many of the remaining 300 users are likely to also login during that day. What I am driving at is even though only 700 users will be logged in at one time the remaining 300 users will still needs to have resources available shoud they needs their VMs. If you have only 700 out of 1000 VMs provisioned or just powered on you are going to use more iops when the additional VMs are provisioned or powered on. In our environment we provisione everything up front and leave them running.Too many people logging on at the same time can cause a login storm which is BAD.

2) Are you or will you be using persisten or non-persistent VMs? If you are using non-persistent pools then you will have login storms whenever a user logs in and his profile is recreated on a different VM. If you use a persistent pool, this is less of an issue because once the user logs in for the first time the heavy lifting of creating the user profile is completed.

Hope this helps. 

[tacticsbaby]

Both the TC and the VM need a different IP address.