 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Forum / Virtual PC / August 2007[Request] Remote Control of Guest Operating Systems Using RDP
Hi, I'd like to request that the next version of Virtual PC allow some type of terminal services (using RDP perhaps) such that multiple people can access the guest operating systems running inside Virtual PC on a machine. This should work the same as using RDP to access a computer in the sense that it should redirect sound and provide full screen abilities over the network. My QA department currently uses VMWare running on a Linux server, which has 2GB RAM and dual processors. We decided to go with this approach because we need the ability to have several QA Engineers remotely access the virtual operating systems running on this "VMWare server". Since Linux has excellent support for remote access (we use Cygwin, tunneling the X window packets through SSH and using the local machines X-window server for processing). However, testing of sound is a big issue with our department. The applications we test with this "VMWare server" require us to test sound. We installed four sound cards so that up to four QA Engineers can test sound at one time. VMWare allows selecting which sound device to use for a particular guest operating system. The problem is that in order to test the sound coming from the speakers the engineers must be in the vicinity of the server. Engineers testing apps on a Windows XP guest operating system benefit from RDP in that the Windows XP guest is remotely started on the server, and then the engineer uses RDP (with the redirect sound option) to test the app. This allows the engineer to stay in their office and not have to go the lab for testing. So, I'd like to request that in the next version of Virtual PC you have a feature such that people can RDP into the Virtual PC service/app and use any guest operating system remotely (and should allow for redirection of sound). I don't need RDP access to the host machine, therefore I'd like the Virtual PC product to provide it's own RDP server access. Are there any other people on this forum that think this would be a good idea? > I'd like to request that the next version of Virtual PC allow some type > of terminal services (using RDP perhaps) such that multiple people can > access the guest operating systems running inside Virtual PC on a > machine. Been there, doing it right now. We have to occasionally provide support for older versions of the MS Solomon accounting system, which do not co-exist on the same workstation, so we have a single workstation with several virtual machines each running XP and a different Solomon client. We don't have any problems using RDP to get into the virtual machine. RDP access (single or multi-user) is a function of the OS, not the underlying (virtual) hardware. Jack Peacock I understand RDP is an OS feature/service. But, I'm asking for the ability to RDP directly into the VPC, not the host. Although the setup you describe certainly works, it works only as long as you use Windows XP as the guest, then RDP directly into the guest OS. Or, if the host is a Windows XP, Win2K or Win2K3 server then you can RDP into the host, run VPC and then use the guest. The problem I have with these setups are: 1) It's not feasible to expect that everyone will be using just Windows XP as the guest operating system if RDP access is required. I test on everything from OS/2 to Windows XP, so obviously I can't RDP into each virtual OS I need tested. 2) If Windows XP Pro is used as the host, RDP access is limited to one person at one time. Again, this does not work in a QA department where multiple engineers need access to the guest operating systems. 3) If Windows 2K or Windows 2K3 is used, certainly terminal services can be enabled and allow access simultaneously to VPC. However, the cost of this (because of licensing) ultimately renders this option dead in the water. The other option with this scenario would be to create admin accounts on the server and let everyone who needs VPC access RDP into the machine. But having so many admin accounts logging into the server just to use VPC seems overkill and probably a security risk, besides thinking what happens if one of these admins decides to change something on the server (for good or worse) that affects everyone else? So that's how I see it. I don't want RDP access from the host OS, I'd prefer VPC to provide it directly. Certainly they could modify VPC to provide this. In the meantime I'll keep using VMWare on our Linux box except for sound redirection as I mentioned. > Been there, doing it right now. We have to occasionally provide support for > older versions of the MS Solomon accounting system, which do not co-exist on [quoted text clipped - 3 lines] > multi-user) is a function of the OS, not the underlying (virtual) hardware. > Jack Peacock > 1) It's not feasible to expect that everyone will be using just Windows > XP as the guest operating system if RDP access is required. I test on > everything from OS/2 to Windows XP, so obviously I can't RDP into each > virtual OS I need tested. So what you are looking for is a video device driver that output to RDP (or VNC or whatever) instead of to a virtualized VGA chipset. The problem is, how do all those OSes talk to it? It's not a piece of hardware that can be emulated, because there is no video chipset that outputs to ethernet instead of a monitor. A virtual machine is a static hardware environment...one VGA, one disk driver, one CPU chipset...adding new hardware only complicates the matter (though I would like to see some kind of USB virtualization, and the ability to talk to dongles on the parallel port in order to bring up old DOS based CAD systems). A ideal testing environment minimizes variables extraneous to what's being tested. In this case VPC has a clean set of hardware that doesn't vary, even if I move it to another workstation. Adding in new device drivers now complicates the matter; the program failed on a GDI, was it the program itself or something in the RDP pseudo-device emulation? I'd rather contend with one device driver, an S3 Trio that's a known quantity and has some usage to get out the emulation bugs. With new hardware emulation for an RDP video out there would have to be a new device driver for every OS used on the virtual machine; wouldn't that actually be worse than what you have right now? Where would an OS/2 or Netware driver come from? If RDP isn't possible, what about VNC? Jack PEacock I don't think you understand me. I'm not saying they should reinvent the wheel and add new device drivers for video support as you mention. I'm saying they should use the existing RDP service that Windows provides, provide hooks into that, and allow users to RDP into the VPC shell directly, bypassing the host, and allow multiple user access. That's all. I'm sure this could be done. Whether they'd want to do this...that's another matter. Perhaps it's just a pipedream. > So what you are looking for is a video device driver that output to RDP (or > VNC or whatever) instead of to a virtualized VGA chipset. The problem is, [quoted text clipped - 19 lines] > If RDP isn't possible, what about VNC? > Jack PEacock Connectix VPC 5.2 had a VNC client. I remember hearing it was removed during the VPC 2004 development for security reasons. Perhaps they will be able to come up with an alternative in a future release. Have you sent your request to mswish@microsoft.com yet? Scott > I don't think you understand me. I'm not saying they should reinvent > the wheel and add new device drivers for video support as you mention. [quoted text clipped - 31 lines] >> If RDP isn't possible, what about VNC? >> Jack PEacock > I don't think you understand me. I'm not saying they should reinvent the > wheel and add new device drivers for video support as you mention. I'm > saying they should use the existing RDP service that Windows provides, > provide hooks into that, and allow users to RDP into the VPC shell > directly, bypassing the host, and allow multiple user access. The "hooks" are the problem. The nature of a virtual machine is that it provides a hardware environment, not software. What do the "hooks" correspond to in hardware? RDP in Windows intercepts the video driver at the OS level; it does not represent a separate VGA chipset. How would an out of the box MS-DOS 6 install talk to an RDP hook? Does VPC intercept the INT 10 calls used by DOS and redirect them to RDP? Okay, but then what happens if you boot Win 3 or OS/2, or you run a DOS program that directly writes to VGA memory? They have hardware video drivers, not INT 10 calls. How do you talk to RDP? Add an API? Great, but how does an existing driver in Netware or OS/2 know about VPC APIs? I see a lot of posts asking for VPC APIs of some sort or another, but that violates the whole concept of a virtual machine. The P4 or Athlon CPU doesn't come with magic APIs built into the chip, nor should the virtual CPU. The API is the level of support for the virtualized hardware. Jack Peacock I am having good results doing this vi pcAnywhere. I haven't tried any of the freebie remote control programs; but I don't see any reason the wouldn't work... Guido >-----Original Message----- >Hi, [quoted text clipped - 38 lines] >idea? >. > Hi, > [quoted text clipped - 36 lines] > Are there any other people on this forum that think this would be a good > idea? sncglhur nlgcem pnilwb xkusga qjibcd ipxru twnfjmq > Hi, > [quoted text clipped - 36 lines] > Are there any other people on this forum that think this would be a good > idea? bbfjcu6kleiaczo3 [URL=http://www.774035.com/179849.html] txeoxsh5yfh9ya3 [/URL] 1elz5cdb0hg9 > Hi, > [quoted text clipped - 36 lines] > Are there any other people on this forum that think this would be a good > idea? bbfjcu6kleiaczo3 http://www.948262.com/1057348.html 1elz5cdb0hg9 > Hi, > [quoted text clipped - 36 lines] > Are there any other people on this forum that think this would be a good > idea? bbfjcu6kleiaczo3 tt7bqskzlwdbzk2l 1elz5cdb0hg9 |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.