XP and Virtual Machine Hardware Versions
-
We have an XP VM running on an ESXi 5.5 host (recently upgraded to the latest ESXi) running on local storage. This VM is specifically for some programming software used in conjunction with our press brakes. This VM is running on VM hardware 8. The user that uses this VM for programming has to access the VM via VNC since the software requires a USB HASP to run. The HASP prevents anyone from using the software via RDP, so VNC was the way to go..
Since the ESXi upgrade, the video performance has been a little odd. Opening the software works fine, but some menus within the software will open, show the text you would expect, and then show up completely white on the screen. Once that happens you can take another window and drag it over the one that it solid white to show the text. I tried different VNC viewers with different connection speeds and even fewer colors but have not really found a solution. Yes, I realize it is XP, but if there's anything I can do to boost the video performance I would like to do it.
I did check processor usage (only using 1 vCPU, but I am not seeing that it is taxed in anyway). RAM usage is pretty normal (again, not taxed here), even at the limit of just over 3 GB usable by XP. IOPs on the server are not an issue to my knowledge. I tried increasing the video memory a little, but that did not really help. The VM is using the standard VGA adapter that VMWare Tools installs. I am not certain the VMware SVGA 3D adapter will even install in XP.
I'd appreciate any help people can offer on this one. Is the issue here because we have to connect via VNC, lack of video memory for the VM, the fact that we are running XP, etc.? Will a VM hardware version upgrade help or hurt here?
-
@NetworkNerd you could always clone / backup the VM prior to updating the hardware level just to test. Couldn't hurt.
-
Put it on VirtualBox and you'll get RDP back.
-
What about pcoip.
-
If you use the VM's console, do you get the same video issues?
-
@scottalanmiller said:
Put it on VirtualBox and you'll get RDP back.
The hypervisor isn't preventing RDP.
-
I've had this.
I resolved it by removing vmware tools. Rebooting. Installing the latest version of vmware tools.
Thanks,
G
-
@alexntg said:
@scottalanmiller said:
Put it on VirtualBox and you'll get RDP back.
The hypervisor isn't preventing RDP.
Didn't imply that it was. But it isn't providing it either. VirtualBox provides RDP directly from the hypervisors so no OS level lock out will do anything. Console redirect to RDP!!
-
@scottalanmiller said:
@alexntg said:
@scottalanmiller said:
Put it on VirtualBox and you'll get RDP back.
The hypervisor isn't preventing RDP.
Didn't imply that it was. But it isn't providing it either. VirtualBox provides RDP directly from the hypervisors so no OS level lock out will do anything. Console redirect to RDP!!
Ok. How does one do that without nesting VMs?
-
@alexntg said:
@scottalanmiller said:
@alexntg said:
@scottalanmiller said:
Put it on VirtualBox and you'll get RDP back.
The hypervisor isn't preventing RDP.
Didn't imply that it was. But it isn't providing it either. VirtualBox provides RDP directly from the hypervisors so no OS level lock out will do anything. Console redirect to RDP!!
Ok. How does one do that without nesting VMs?
Just select the RDP option instead of the VNC option when downloading VirtualBox. Remote console redirection is native to VirtualBox and Xen. There is nothing special to know.
-
@scottalanmiller said:
@alexntg said:
@scottalanmiller said:
@alexntg said:
@scottalanmiller said:
Put it on VirtualBox and you'll get RDP back.
The hypervisor isn't preventing RDP.
Didn't imply that it was. But it isn't providing it either. VirtualBox provides RDP directly from the hypervisors so no OS level lock out will do anything. Console redirect to RDP!!
Ok. How does one do that without nesting VMs?
Just select the RDP option instead of the VNC option when downloading VirtualBox. Remote console redirection is native to VirtualBox and Xen. There is nothing special to know.
Let me rephrase; you're suggesting running VirtualBox inside of ESXI?
-
@alexntg said:
@scottalanmiller said:
@alexntg said:
@scottalanmiller said:
@alexntg said:
@scottalanmiller said:
Put it on VirtualBox and you'll get RDP back.
The hypervisor isn't preventing RDP.
Didn't imply that it was. But it isn't providing it either. VirtualBox provides RDP directly from the hypervisors so no OS level lock out will do anything. Console redirect to RDP!!
Ok. How does one do that without nesting VMs?
Just select the RDP option instead of the VNC option when downloading VirtualBox. Remote console redirection is native to VirtualBox and Xen. There is nothing special to know.
Let me rephrase; you're suggesting running VirtualBox inside of ESXI?
No. Why would want to do that?
You're making something incredibly simple into something really complicated.
Just install CentOS. Toss on VBox with RDP. Done. VBox handles everything. No weird nesting. No reading in something odd. Just a normal VBox install.
-
@scottalanmiller said:
@alexntg said:
@scottalanmiller said:
@alexntg said:
@scottalanmiller said:
@alexntg said:
@scottalanmiller said:
Put it on VirtualBox and you'll get RDP back.
The hypervisor isn't preventing RDP.
Didn't imply that it was. But it isn't providing it either. VirtualBox provides RDP directly from the hypervisors so no OS level lock out will do anything. Console redirect to RDP!!
Ok. How does one do that without nesting VMs?
Just select the RDP option instead of the VNC option when downloading VirtualBox. Remote console redirection is native to VirtualBox and Xen. There is nothing special to know.
Let me rephrase; you're suggesting running VirtualBox inside of ESXI?
No. Why would want to do that?
You're making something incredibly simple into something really complicated.
Just install CentOS. Toss on VBox with RDP. Done. VBox handles everything. No weird nesting. No reading in something odd. Just a normal VBox install.
That's insane. No one should be running their production environment on VirtualBox. Replacing ESXi with that would result in a drop in performance, and it's not a Veeam-supported hypervisor.
-
@alexntg we are talking about running one XP desktop here. Keep some perspective.
-
@scottalanmiller said:
@alexntg we are talking about running one XP desktop here. Keep some perspective.
It's currently a VM running in an otherwise fine server architecture. You're suggesting adding another piece of hardware and a different virtualization platform for a minor video issue.
-
@alexntg said:
@scottalanmiller said:
@alexntg we are talking about running one XP desktop here. Keep some perspective.
It's currently a VM running in an otherwise fine server architecture. You're suggesting adding another piece of hardware and a different virtualization platform for a minor video issue.
And a major licensing issue.
-
@scottalanmiller said:
@alexntg said:
@scottalanmiller said:
@alexntg we are talking about running one XP desktop here. Keep some perspective.
It's currently a VM running in an otherwise fine server architecture. You're suggesting adding another piece of hardware and a different virtualization platform for a minor video issue.
And a major licensing issue.
All it takes is a single SA subscription or VDA license to fix. That's not major. The issue would still exist on VirtualBox.
-
@alexntg Is VDA still needed on a 1:1 scenario?
-
@scottalanmiller said:
@alexntg Is VDA still needed on a 1:1 scenario?
To start with, yes. The accessing device must be covered by either SA or VDA. If a Companion Subscription License (CSL) is added on to the VDA or SA for a user's primary device, they're able to use up to 4 additional devices to access the virtual OSE.
-
@alexntg said:
@scottalanmiller said:
@alexntg Is VDA still needed on a 1:1 scenario?
To start with, yes. The accessing device must be covered by either SA or VDA. If a Companion Subscription License (CSL) is added on to the VDA or SA for a user's primary device, they're able to use up to 4 additional devices to access the virtual OSE.
So you can't remote into a VM on your own desktop?