My son has a large extended family and lots of friends that come over to his house. All of them like to use the computer to get online and/or play games. However, they rarely bring their own computers and always ask to borrow his family computer. Not to mention he has three kids of his own who will soon be old enough to start using computers on their own. He would like to set up an area in his family room that is like a small computer lab. However, he doesn't really want to set up and manage ten different computers. I told him he could save a lot of money and time by setting up something using VirtualBox. I did some investigating and found OpenThinClient.org which can potentially provide thin client access to VirtualBox virtual machines running on a central server via RDP.
Does anyone here have experience with this kind of setup? Is it really possible to play games on a VM over an RDP connection over a network?
VirtualBox, OpenThinClient, and RDP for small computer lab
-
GrantRobertson
- Posts: 2
- Joined: 27. Dec 2009, 05:12
- Primary OS: MS Windows XP
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Ubuntu
Re: VirtualBox, OpenThinClient, and RDP for small computer lab
Bottom line, DX gaming over RDP *does not* work, even running at GigE speeds, and even if the game itself is running on true metal. Just watching what my HTPC is showing over VNC on a GigE network (Traffic going through 3 GigE switches - I have machines all over the house 
) is pathetically slow. Depending on the series of frames, I'll get anywhere from 0.5 to 3 FPS. Watching a video be rendered from an AVI to the screen is extremely light-weight on the CPU/Graphics card compared to full real time rendering of ANY game. If you can get DX/OpenGL running in a VM, you're further ahead going that route than RDP.
Lets look at the pros and cons of several different methods of using, or not using VBox in a multi-computer home based environment
* One host, many OS's running at once with thin clients RDPing to respective guest
* One host to run a network share for many OS's with semi-decent client hardware
* The host IS the client
* Forget about virtualization
One host, many OS's running at once with thin clients RDPing to respective guest
Having the impression that "TEN" machines is out of proportion to what could possibly be setup, to be honest, you'll need a VERY strong machine to handle this kind of computing power if there is going to be heavy CPU activity such as gaming, regardless of how basic the game. More so in CPU department than the memory department. Bare minimum memory for each guest would be 256meg for an XP guest. Multiply that by 10 machines and you'll need 2.5gig of memory, plus whatever is supposed to use for the host OS. Reasonable, yeah - for memory, but, finding a cheap system with 10 CPUs, or going dual quad core CPUs to give you 8 cores, if all 10 guests are in use, you're looking at pretty serious serious equipment. Now lets talk about the networking. GigE. Gotta be. Feeding a video feed 10 times all at once at 100mbit isn't going to provide the best option without a lot of jumps and blips and perhaps even screen ghosting. Not to mention gaming is pretty much out because of that very first paragraph. However, having the guest OS's in one spot does make it easy for backups when the guests aren't running. Worst case scenario in the case of the server just up-and-crashing because of a motherboard malfunction only means you'll have to reload one OS and put the 10 guest images back in place. But that'd mean all guests are down until the repair is complete.
One host to run a network share for many clients with semi-decent hardware
This probably would be more reasonable to do as now your bottleneck would be at the hosts hard drive instead of memory and CPU. First, the CPU work load would be on the client machine, and not on the host. Second, you still have the perk that you can easily backup from one location, pending the OS isn't in use. Third, pegging the GigE network is going to be harder to do than pegging CPU requirements on the host. However, you're still SOL on the gaming aspect as doing any sort of DX/OpenGL gaming is a HUGE resource issue, and you're sooner to peg the HDD on the host prior to pegging the network. You'd need a massive client in respects to hardware to even BEGIN to deal with virtualizing DX in a decent manor. Even then some games would just flat-out not run because its virtualized. The advantage, if gaming isn't a concern, is that it won't matter what the client hardware is for any of the guest OS's as the guest OS just sees the guest hardware. That means that each guest image can be run on any of the client machines at any time with reservation that the particular guest OS is currently NOT running on another client. I can't be sure if it is possible to run the same image multiple times without some severe data corruption.
The host IS the client
You can install a skinny linux OS and have VBox running on each. You could copy all the images from a central machine to the client and have the client run VBox with any image. Then everything is contained within that box itself. Perks to this is that now you won't be dependant on anything outside that client machine. Aside from that, each client can run any OS at any time independant of each other. If running Microsoft software, legality becomes a question as the Microsoft license agreement states that each license can only be run on one machine (Technically motherboard) at one time. Backups can also be pushed to a central repository as well so things can backed up as one single unit. With this setup, the younger kids can have their educational OS that plays toddler/preschool games, teenagers of the family can use the wordprocessing and the internet as needed, and parents can have their own OS to do their banking and stuff that the kids can't get into as easily, and each image can be run on *ANY* available locally on that machine. There are only two things I can think of that'd be a problem. If one image is run on two or more clients at the same time on the same network and the image hasn't been modified so that it has a different host name, minor network snags start to rear their ugly head. The other problem would be that if any kind of work, be it homework or Quickbooks, were to be done on one guest, it'd only be stored on that guest. Again, and still -- true DX/OGL gaming is still out of the question as the rendering is still slow.
Forget about virtualization
This is the true gaming solution. The only problem is that backups become a chore. If the machine does die or viruses kill the OS, you are looking at a full reload of the whole OS, and pending backups, everything is lost and time spent on a complete reload of the OS and software. However, gaming is available, of course depending on the real hardware. With the previous options, if snapshots are done regularly, reverting back is just a few mouse clicks. Imaging the clients HDD can be done to another drive as an image or a sector by sector copy, or to DVD(s) or to a network share all via external tools such as Norton Ghost or other freeware utilities, however, if a machine replacement is required and you can't find the EXACT same hardware, those images are pretty much useless. Norton Ghost (I think it was version
had a tool that if the image was stored on a network, you could manage the data within the image (If it was FAT32 - Read Only for NTFS based images) Beyond that gloom, YOU CAN DO GAMING!!
Conclusion
So there you have it. Every possibly combination that I can think of to do what your son could possibly do for a "multi-machine community based home network setup". Unfortunately, no matter which way you slice it, there *IS* going to be some sort of management involved periodically for backups and regular maintenance of the machine. However, what I would really suggest is setup the current "Family" machine to be the parents machine and have it run the OS it came with. No virtualization. Use that family machine to store the images of guest operating systems and let each client copy the images locally, and run the 3rd option above.
) is pathetically slow. Depending on the series of frames, I'll get anywhere from 0.5 to 3 FPS. Watching a video be rendered from an AVI to the screen is extremely light-weight on the CPU/Graphics card compared to full real time rendering of ANY game. If you can get DX/OpenGL running in a VM, you're further ahead going that route than RDP.Lets look at the pros and cons of several different methods of using, or not using VBox in a multi-computer home based environment
* One host, many OS's running at once with thin clients RDPing to respective guest
* One host to run a network share for many OS's with semi-decent client hardware
* The host IS the client
* Forget about virtualization
One host, many OS's running at once with thin clients RDPing to respective guest
Having the impression that "TEN" machines is out of proportion to what could possibly be setup, to be honest, you'll need a VERY strong machine to handle this kind of computing power if there is going to be heavy CPU activity such as gaming, regardless of how basic the game. More so in CPU department than the memory department. Bare minimum memory for each guest would be 256meg for an XP guest. Multiply that by 10 machines and you'll need 2.5gig of memory, plus whatever is supposed to use for the host OS. Reasonable, yeah - for memory, but, finding a cheap system with 10 CPUs, or going dual quad core CPUs to give you 8 cores, if all 10 guests are in use, you're looking at pretty serious serious equipment. Now lets talk about the networking. GigE. Gotta be. Feeding a video feed 10 times all at once at 100mbit isn't going to provide the best option without a lot of jumps and blips and perhaps even screen ghosting. Not to mention gaming is pretty much out because of that very first paragraph. However, having the guest OS's in one spot does make it easy for backups when the guests aren't running. Worst case scenario in the case of the server just up-and-crashing because of a motherboard malfunction only means you'll have to reload one OS and put the 10 guest images back in place. But that'd mean all guests are down until the repair is complete.
One host to run a network share for many clients with semi-decent hardware
This probably would be more reasonable to do as now your bottleneck would be at the hosts hard drive instead of memory and CPU. First, the CPU work load would be on the client machine, and not on the host. Second, you still have the perk that you can easily backup from one location, pending the OS isn't in use. Third, pegging the GigE network is going to be harder to do than pegging CPU requirements on the host. However, you're still SOL on the gaming aspect as doing any sort of DX/OpenGL gaming is a HUGE resource issue, and you're sooner to peg the HDD on the host prior to pegging the network. You'd need a massive client in respects to hardware to even BEGIN to deal with virtualizing DX in a decent manor. Even then some games would just flat-out not run because its virtualized. The advantage, if gaming isn't a concern, is that it won't matter what the client hardware is for any of the guest OS's as the guest OS just sees the guest hardware. That means that each guest image can be run on any of the client machines at any time with reservation that the particular guest OS is currently NOT running on another client. I can't be sure if it is possible to run the same image multiple times without some severe data corruption.
The host IS the client
You can install a skinny linux OS and have VBox running on each. You could copy all the images from a central machine to the client and have the client run VBox with any image. Then everything is contained within that box itself. Perks to this is that now you won't be dependant on anything outside that client machine. Aside from that, each client can run any OS at any time independant of each other. If running Microsoft software, legality becomes a question as the Microsoft license agreement states that each license can only be run on one machine (Technically motherboard) at one time. Backups can also be pushed to a central repository as well so things can backed up as one single unit. With this setup, the younger kids can have their educational OS that plays toddler/preschool games, teenagers of the family can use the wordprocessing and the internet as needed, and parents can have their own OS to do their banking and stuff that the kids can't get into as easily, and each image can be run on *ANY* available locally on that machine. There are only two things I can think of that'd be a problem. If one image is run on two or more clients at the same time on the same network and the image hasn't been modified so that it has a different host name, minor network snags start to rear their ugly head. The other problem would be that if any kind of work, be it homework or Quickbooks, were to be done on one guest, it'd only be stored on that guest. Again, and still -- true DX/OGL gaming is still out of the question as the rendering is still slow.
Forget about virtualization
This is the true gaming solution. The only problem is that backups become a chore. If the machine does die or viruses kill the OS, you are looking at a full reload of the whole OS, and pending backups, everything is lost and time spent on a complete reload of the OS and software. However, gaming is available, of course depending on the real hardware. With the previous options, if snapshots are done regularly, reverting back is just a few mouse clicks. Imaging the clients HDD can be done to another drive as an image or a sector by sector copy, or to DVD(s) or to a network share all via external tools such as Norton Ghost or other freeware utilities, however, if a machine replacement is required and you can't find the EXACT same hardware, those images are pretty much useless. Norton Ghost (I think it was version
had a tool that if the image was stored on a network, you could manage the data within the image (If it was FAT32 - Read Only for NTFS based images) Beyond that gloom, YOU CAN DO GAMING!!Conclusion
So there you have it. Every possibly combination that I can think of to do what your son could possibly do for a "multi-machine community based home network setup". Unfortunately, no matter which way you slice it, there *IS* going to be some sort of management involved periodically for backups and regular maintenance of the machine. However, what I would really suggest is setup the current "Family" machine to be the parents machine and have it run the OS it came with. No virtualization. Use that family machine to store the images of guest operating systems and let each client copy the images locally, and run the 3rd option above.
-
GrantRobertson
- Posts: 2
- Joined: 27. Dec 2009, 05:12
- Primary OS: MS Windows XP
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Ubuntu
Re: VirtualBox, OpenThinClient, and RDP for small computer lab
Wow! Thank you. That was a complete article. You should post that to a blog somewhere.
In the end I guess I will recommend that he just use imaging to keep the systems clean. He can partition the drives on the individual machines and set up the games so that they save their data to the second partition. Then he can simply reapply the images to the machines as needed.
Again, Thanks,
Grant Robertson
In the end I guess I will recommend that he just use imaging to keep the systems clean. He can partition the drives on the individual machines and set up the games so that they save their data to the second partition. Then he can simply reapply the images to the machines as needed.
Again, Thanks,
Grant Robertson