troubleshooting Question

Terminal Servers - physical versus virtual - follow up on: http://www.experts-exchange.com/Software/Virtualization/Q_27980333.html

Avatar of Line One
Line One asked on
Virtualization
2 Comments1 Solution333 ViewsLast Modified:
Following up on https://www.experts-exchange.com/Software/Virtualization/Q_27980333.html I would like to know what the differences between physical and virtual TS's in a clustered farm in the following specific circumstances:

physical TS server freezes (freeze is distinguished from drastic slowdown in the following questions)
vs Core host of TS VM freezes
vs TS session freezes

physical server reboots
vs Core host of TS VM's reboots
vs TS VM itself reboots

What difference would the user see in these circumstances?  

Would a physical TS freeze mean users would be redirected to another node in the cluster? Or would it just be a stuck session?  If it was redirected how long would it take?

Would a freeze on a Core hosting VM's allow for TS access even though the host is not accessible? It seems I've seen that situation

In the case of a reboot of a physical TS, does it make a difference how long the reboot takes before the physical TS server is failed over?  

In the case of a virtualized TS, if the Core host reboots does it make a difference how the long the reboot takes before the VM is failed over?

It seems as well that drastic performance degradation as opposed to outright hardware failure on a TS physical or virtual will not cause failover.  Is that correct?

Also in the case of a constantly rebooting host - physical or Core host - would there not be problems with users being connected to the rebooting server during its up time window?

In the case of the host not rebooting but the TS VM rebooting constantly it seems one could quickly/simply bring the TS VM down and nobody would be able to log into it.  Agree/disagree?

And it would be quite possible then to simply add a dupe of the VM to the server - in fact, it could failover to another hosted VM on the server itself so there would be less performance issues caused by more people being redirected and logging into one of the other non-rebooting physical  TS servers in the cluster.  Make sense? Any problems I haven't given enough consideration to with the failover-on-the-same server VM scenario?

Also from my experiences drastic slowness/freezes are more common than physical failure in TS environments. Is that the sense of  responding Experts here as well?

Finally it seems to me that most of the time Dev and Test 'networks' that mimic the production network are pretty well defacto virtualized as there is a lot  of 'playing around' going on - there always seem to be new versions of programs that have to be deployed.  It seems then that if one has a physical TS farm then that there is a lot of converting virtual to physical to rollout a new 'version' and as well backing up the current production to become the new Test/Dev involves physical to virtual which makes rollback to a physical network more complicated. Again, fee free to debate - I am exploring and want to make sure that I am not simply agreeing with myself in my design choices.

Thanks in advance for all time put into answering the above.
ASKER CERTIFIED SOLUTION
Join our community to see this answer!
Unlock 1 Answer and 2 Comments.
Start Free Trial
Learn from the best

Network and collaborate with thousands of CTOs, CISOs, and IT Pros rooting for you and your success.

Andrew Hancock - VMware vExpert
See if this solution works for you by signing up for a 7 day free trial.
Unlock 1 Answer and 2 Comments.
Try for 7 days

”The time we save is the biggest benefit of E-E to our team. What could take multiple guys 2 hours or more each to find is accessed in around 15 minutes on Experts Exchange.

-Mike Kapnisakis, Warner Bros