We finally decided to move our content over from our ghetto web page - http://engineering.ucsb.edu/~duonglt/vmware/ over to Google's free blogspot. This move not only helps us to organize our content and benefit from automatic RSS feeds, but it also makes the content searchable.
This site will still focus primarily on VMware automation using the various scripting APIs and SDKs. We hope you like the new layout and we look forward to sharing our scripts with the VMware community!
Monday, May 31, 2010
Saturday, May 29, 2010
vSphere Tips and Tricks Part 1
Disclaimer: Ensure these changes have been thoroughly tested and confirmed with VMware support prior to rolling out into production. Most of these changes and tips may be undocumented by VMware, test at your own risk!
Map Service Console/COS VMDK to specific ESX host (useful if you boot from SAN):
[root@everest ~]# grep -i "hostname" /vmfs/volumes/everest-local-storage/esxconsole-49a095a4-204d-c7ba-9bb8-001f29c7b048/logs/sysboot-vmkernel-late.log
0:00:00:06.289 cpu1:4105)Config: 363: "HostName" = "everest.primp-industries.com", Old value: "localhost" (Status: 0x0)
Retrieve VmId from vmware-cmd similiar to that in vimsh/vmware-vim-cmd (only available on classic ESX, not sure why it's not in vCLI):
[root@everest ~]# vmware-cmd /vmfs/volumes/d32c5a97-e039bdbf/vCenter-ESX4.02172009/vCenter-ESX4.02172009.vmx getid
getid() = 32
VMware FT statistics and debugging utility
Available after some patch set, generally 4.0u1+
[root@esx-5 ~]# ft-stats
Usage: ft-stats [-hvf] [-c] [-l] [-n ] [-d ] [-s ] [-w ]
-h, --help Show this message
-v, --verbose verbose output
-f, --force Continue even if version check fails
-c, --cache Use VSI cache file
-l, --list list FT VMs
-n, --iterations Print stats for n iterations
-d, --delay Print stats every n secs (default:5)
-s, --snapshot Collect stats for n secs
-w, --world Print stats for worldID
Note: This tool is intended to assist in troubleshooting and should only be used
with direction by VMware support. All other use of this tool is unsupported.
esxupdate - Query for installed/retired packages with undocumented "--vib-view" option
[root@himalaya ~]# esxupdate --vib-view query
--------------------------------------VIB ID------------------------------------- Package State -----------Timestamp------------
rpm_vmware-esx-drivers-scsi-fnic_400.1.1.0.109.2vmw-2vmw.1.9.208167@x86_64 installed 2010-01-06T12:24:38.100201-05:00
rpm_acpid_1.0.4-9.el5_4.2@x86_64 installed 2010-04-02T17:09:44.566014+00:00
rpm_samba-client_3.0.33-3.15.el5_4.1@x86_64 installed 2010-04-02T17:09:44.171847+00:00
rpm_nss_3.12.3.99.3-1.2157.vmw@x86_64 installed 2010-04-02T17:09:41.148547+00:00
rpm_initscripts_8.45.19.EL-1.2442.vmw@x86_64 installed 2010-04-02T17:09:36.911452+00:00
Change default COW (copy on write) disk growth value
Query (Default is 16MB):
[root@himalaya ~]# esxcfg-advcfg -g /COW/COWDiskSizeIncrement
Value of COWDiskSizeIncrement is 32768
Set (e.g. 256MB):
[root@himalaya ~]# esxcfg-advcfg -s 524288 /COW/COWDiskSizeIncrement
Value of COWDiskSizeIncrement is 524288
The input value for changing COWDiskSizeIncrement is in sectors
Easy formula is (SIZE_IN_MB)*(1024)*(2) = SECTOR VALUE
Map Service Console/COS VMDK to specific ESX host (useful if you boot from SAN):
grep -i "hostname" /vmfs/volumes/[datastore]/[esxconsole-datastore-uuid]/logs/sysboot-vmkernel-late.log
[root@everest ~]# grep -i "hostname" /vmfs/volumes/everest-local-storage/esxconsole-49a095a4-204d-c7ba-9bb8-001f29c7b048/logs/sysboot-vmkernel-late.log
0:00:00:06.289 cpu1:4105)Config: 363: "HostName" = "everest.primp-industries.com", Old value: "localhost" (Status: 0x0)
Retrieve VmId from vmware-cmd similiar to that in vimsh/vmware-vim-cmd (only available on classic ESX, not sure why it's not in vCLI):
vmware-cmd /vmfs/volumes/[datastore]/[path_to_vm]/vm.vmx getid
[root@everest ~]# vmware-cmd /vmfs/volumes/d32c5a97-e039bdbf/vCenter-ESX4.02172009/vCenter-ESX4.02172009.vmx getid
getid() = 32
VMware FT statistics and debugging utility
Available after some patch set, generally 4.0u1+
[root@esx-5 ~]# ft-stats
Usage: ft-stats [-hvf] [-c
-h, --help Show this message
-v, --verbose verbose output
-f, --force Continue even if version check fails
-c, --cache
-l, --list list FT VMs
-n, --iterations
-d, --delay
-s, --snapshot
-w, --world
Note: This tool is intended to assist in troubleshooting and should only be used
with direction by VMware support. All other use of this tool is unsupported.
esxupdate - Query for installed/retired packages with undocumented "--vib-view" option
esxupdate --vib-view query
[root@himalaya ~]# esxupdate --vib-view query
--------------------------------------VIB ID------------------------------------- Package State -----------Timestamp------------
rpm_vmware-esx-drivers-scsi-fnic_400.1.1.0.109.2vmw-2vmw.1.9.208167@x86_64 installed 2010-01-06T12:24:38.100201-05:00
rpm_acpid_1.0.4-9.el5_4.2@x86_64 installed 2010-04-02T17:09:44.566014+00:00
rpm_samba-client_3.0.33-3.15.el5_4.1@x86_64 installed 2010-04-02T17:09:44.171847+00:00
rpm_nss_3.12.3.99.3-1.2157.vmw@x86_64 installed 2010-04-02T17:09:41.148547+00:00
rpm_initscripts_8.45.19.EL-1.2442.vmw@x86_64 installed 2010-04-02T17:09:36.911452+00:00
Change default COW (copy on write) disk growth value
Query (Default is 16MB):
[root@himalaya ~]# esxcfg-advcfg -g /COW/COWDiskSizeIncrement
Value of COWDiskSizeIncrement is 32768
Set (e.g. 256MB):
[root@himalaya ~]# esxcfg-advcfg -s 524288 /COW/COWDiskSizeIncrement
Value of COWDiskSizeIncrement is 524288
The input value for changing COWDiskSizeIncrement is in sectors
| UNIT SECTORS | COW GROWTH SIZE |
|---|---|
| 32768 | 16MB |
| 65536 | 32MB |
| 131072 | 64MB |
| 262144 | 128MB |
| 524288 | 256MB |
| 2097152 | 1024MB |
| .... | .... |
Easy formula is (SIZE_IN_MB)*(1024)*(2) = SECTOR VALUE
Getting started with vMA
Documentation
What is vMA?
vMA Forum:
You will find latest Downloads, Reference Documentation and Community Discussions and links to resources.
Downloads
Setting up vMA to be a syslog server by Simon Long
vi-fastpass
How to clone vMA:
Backup & Restore vMA + vi-fastpass DB:
Scripts and Tools
vGhetto Script Repository:
New tools and scripts to add/manage ESX(i) and vCenter targets on vMA 4.x:
vMA Compatible Agent/Scripts(Third Party) Community List:
Health check reports on your VMware environment:
Host and VM shutdown with UPS integration using vMA:
Backup VMs using vMA:
Utilize vi-fastpass On vMA to run Perl script without clear text password:
Tweaks
Hot add memory to vMA or other supported Linux guestOSes using vSphere ESX(i) 4.x:
How to increase/resize vMA Disks:
Offline patching of vMA 4.x:
How to install VMware VDDK on vMA:
Reconfigure networking on vMA:
vMA & Active Directory:
Removing stale targets from vMA:
Enable root account:
Edit /etc/passwd using vi
sudo vi /etc/passwd
Change
root:x:0:0:root:/root:/sbin/nologin
to
root:x:0:0:root:/root:/bin/bash
What is vMA?
- Here is a video explaining vMA on VMware KBTV
vMA Forum:
You will find latest Downloads, Reference Documentation and Community Discussions and links to resources.
Downloads
- vMA 4.x Download - Supports ESX(i) 3.5u2/4.x and vCenter 2.5/4.x
- VIMA 1.0 Download - Supports ESX(i) 3.5u2+
Setting up vMA to be a syslog server by Simon Long
vi-fastpass
- vMA 4.1 - Authentication Policy (fpauth vs adauth)
- How to configure and use vMA's vi-fastpass with fpauth and adauth on vSphere 4.1
- How to automate & cron vi-fastpass scripts on vMA 4.1
How to clone vMA:
Backup & Restore vMA + vi-fastpass DB:
Scripts and Tools
vGhetto Script Repository:
New tools and scripts to add/manage ESX(i) and vCenter targets on vMA 4.x:
vMA Compatible Agent/Scripts(Third Party) Community List:
Health check reports on your VMware environment:
- VMware vSphere Health Check Report - vMA 4.x
- VMware Health Check Report - VIMA 1.0
Host and VM shutdown with UPS integration using vMA:
Backup VMs using vMA:
Utilize vi-fastpass On vMA to run Perl script without clear text password:
Tweaks
Hot add memory to vMA or other supported Linux guestOSes using vSphere ESX(i) 4.x:
How to increase/resize vMA Disks:
Offline patching of vMA 4.x:
How to install VMware VDDK on vMA:
Reconfigure networking on vMA:
vMA & Active Directory:
Removing stale targets from vMA:
Enable root account:
Edit /etc/passwd using vi
sudo vi /etc/passwd
Change
root:x:0:0:root:/root:/sbin/nologin
to
root:x:0:0:root:/root:/bin/bash
Getting started with the vSphere SDK for Perl
Step 1. Visit the vSphere SDK for Perl Home Page
You will find latest Downloads, Reference Documentation and Community Discussions and links to resources.
Step 2. Become familiar with vSphere SDK for Perl Resources:
Step 4. Develop and create your own scripts and utlities using the vSphere SDK for Perl
Become familiar vSphere 4.0 API Reference documentation
Step 5. Learn how to get started with writing your own Perl script using vSphere SDK for Perl
You will find latest Downloads, Reference Documentation and Community Discussions and links to resources.
Step 2. Become familiar with vSphere SDK for Perl Resources:
- Support Information: vSphere, VI 3.x SDK - Support Information
- VMware Code Central (Sample Code) : vSphere SDK for Perl
- Take a look at Getting Started with vSphere SDKs document
- Try some of the esxcfg-* commands bundled with the vCLI/RCLI
Step 4. Develop and create your own scripts and utlities using the vSphere SDK for Perl
Become familiar vSphere 4.0 API Reference documentation
Step 5. Learn how to get started with writing your own Perl script using vSphere SDK for Perl
- This VMware document is a little out dated but it still all applies to writing your own Perl scripts using the vSphere SDK for Perl
vSphere ESX 4.0 - Crash VM Bug?
We recently discovered an anomaly while backing up one of our development VMs using ghettoVCB.sh. When attempting to back up this powered on VM, the backup was successful however oddly, we were left with a powered off VM immediately following the first VMDK clone operation. After some investigation, we found that the problematic VM contained virtual disks spread across two datastores with dissimilar blocksizes (1MB and 2MB).
The VM configuration alongside its main OS disk was stored on the datastore with a 1MB blocksize while it’s data disk (>256 GB) resided on the other datastore which was initialized with a 2MB blocksize. We came to the conclusion that this might have had something to do with the VM configuration residing on a datastore with a blocksize that was smaller than what is needed for the larger VMDK (which was on a datastore with an ample blocksize). Manually snapshotting this VM apparently fails however different behavior was experienced when the commands are executed from a script.
Believing that this was a corner case, we decided that it was best practice to keep all VMFS volume block sizes consistent. This was to be remediated at a later time.
Today we noticed a blog post http://www.yellow-bricks.com/2009/08/24/vsphere-vm-snapshots-and-block-size/ from Duncan Epping regarding the snapshot issue. This may not be a corner case as we thought so we wanted to share this finding with everyone.
If you have a similar configuration from above, it is guaranteed that the VM will crash if you run a script that tries to take a snapshot of the described VM and then subsequently exports the VMDK using vmkfstools.
Here is a video displaying the symptoms decribed from above:
http://engineering.ucsb.edu/~duonglt/vmware/crashVM
Output from script execution on VM: Quentin:
[root@himalaya ~]# ./crashVM.sh Quentin /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/Quentin-clone.vmdk
thinking, give me a few ...
The power state of VM: "Quentin" is On
Extracted VmId and locating VM configured datastore (which should live on a smaller VMFS block size)
Located VMDK: "/vmfs/volumes/himalaya-local-SAS.Savvio/Quentin/Quentin.vmdk"
Trying to create snapshot ... (this should fail)
Create Snapshot:
Trying to vmkfstools copy "/vmfs/volumes/himalaya-local-SAS.Savvio/Quentin/Quentin.vmdk" (this should REALLY fail! right?)
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/himalaya-local-SAS.Savvio/Quentin/Quentin.vmdk'...
Clone: 9% done.
Download crashVM.sh script
The VM configuration alongside its main OS disk was stored on the datastore with a 1MB blocksize while it’s data disk (>256 GB) resided on the other datastore which was initialized with a 2MB blocksize. We came to the conclusion that this might have had something to do with the VM configuration residing on a datastore with a blocksize that was smaller than what is needed for the larger VMDK (which was on a datastore with an ample blocksize). Manually snapshotting this VM apparently fails however different behavior was experienced when the commands are executed from a script.
Believing that this was a corner case, we decided that it was best practice to keep all VMFS volume block sizes consistent. This was to be remediated at a later time.
Today we noticed a blog post http://www.yellow-bricks.com/2009/08/24/vsphere-vm-snapshots-and-block-size/ from Duncan Epping regarding the snapshot issue. This may not be a corner case as we thought so we wanted to share this finding with everyone.
If you have a similar configuration from above, it is guaranteed that the VM will crash if you run a script that tries to take a snapshot of the described VM and then subsequently exports the VMDK using vmkfstools.
Here is a video displaying the symptoms decribed from above:
http://engineering.ucsb.edu/~duonglt/vmware/crashVM
Output from script execution on VM: Quentin:
[root@himalaya ~]# ./crashVM.sh Quentin /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/Quentin-clone.vmdk
thinking, give me a few ...
The power state of VM: "Quentin" is On
Extracted VmId and locating VM configured datastore (which should live on a smaller VMFS block size)
Located VMDK: "/vmfs/volumes/himalaya-local-SAS.Savvio/Quentin/Quentin.vmdk"
Trying to create snapshot ... (this should fail)
Create Snapshot:
Trying to vmkfstools copy "/vmfs/volumes/himalaya-local-SAS.Savvio/Quentin/Quentin.vmdk" (this should REALLY fail! right?)
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/himalaya-local-SAS.Savvio/Quentin/Quentin.vmdk'...
Clone: 9% done.
Download crashVM.sh script
HP Remote Graphics Software ESX/ESXi VDI Tricks
Multiple Displays:
This (option found on: sanbarrow.com however unsupported it may be by VMware and/or HP) is by far the most useful feature we've discovered while testing HP's RGS display protocol in our VDI environment. It works in versions pre-ESX3.5 however we don't remember how far back the compatibility stretches. From what we can recall, this does not work in ESX 3.0. This option has been tested with HP Remote Graphics Software Sender version 5.1.5 running on Windows XP SP2 and SP3 and is being used daily with dual 1280x1024 screens on an HP thinclient.
To enable multiple displays for virtual machines in ESX 3.5, insert the following into the .vmx file or use the "Configuration Parameters" in the VI client that corresponds to the virtual machine:
svga.numDisplays = "x"
where x is the number of displays including the primary display. In the case of this example, it should be set to 2.
The PC version of HP's Remote Graphics Software only supports 2 screens so please set it accordingly. Afterwards, connect to the virtual desktop using the RGS Receiver and enable the second screen as if on a physical workstation. This option will allow you to fully expand windows in their respective screens without using special display spanning software (Go RGS!!).
Issues:
- When connecting to the virtual desktop using the RGS Receiver, the video will be somewhat corrupted if any of the displays on the virtual desktop is set to 32bit. This can be fixed by setting the display depth to 16bit for both screens. The problem seems to be related to the VMware SVGA driver as the corruption can be seen to occur inside the VI client console.
- The second display can not sit directly above the first display. To fix this, set the second (secondary) display to be below the first (primary) display and align the entire virtual display to the top of your physical display layout.
- Some little icons don't fully display. It is pretty annoying when it happens but we've seen this seldomly occur when using the VI client (or the Device Manager as another example) inside the virtual desktop on the primary screen. Moving the VI client (or affected application) over to the secondary screen or clicking on the icons (if possible) will sometimes fix it...
Additional Settings:
svga.vramSize = "25165824"
svga.maxHeight = "1200"
svga.maxWidth = "1920"
These settings are documented in the HP RGS documentation and are needed to increase the virtual machine's display resolution capability (to 1920x1200) and video memory size (to 24MByte). Please be aware that this option imposes additional memory overhead for the virtual machine being modified. Please size the parameters accordingly to your VDI setup.
RGS on Windows 7 on vSphere
After the Windows 7 RC came out, we were naturally inclined to throw it into our ESX3.5 environment. The main aim was to test it using RDP 7 (the VI console is a tad bit unresponsive because the SVGA driver isn't compatible) but we realized that only Windows 7 has the RDP 7 client so in turn, you would need another Windows 7 box (physical) to connect to the Windows 7 VM with RDP 7 (inefficient and no fun to say the least). So instead of installing 7 on a physical box, we decided to go the unconventional (or more affectionately, ghetto) route: get RGS running on 7.
The first issue in our quest to get a "rich remote Windows 7 desktop user experience" is the SVGA II video driver. RGS relies on the underlying "virtual" video card to display information. Video performance without the SVGA driver, as it stands, is quite simply crap and would continue to be so through RGS. To get around this problem, this virtual machine was pushed over to vSphere (with motivation from Eric Sloof's ntpro.nl article) and it's virtual hardware/VMware tools upgraded.
- Make sure the SMBIOS.reflectHost = "true" parameter or licenses are installed where appropriate
- Connect to the console of the virtual machine
- Installing the RGS sender (we used v5.1.5) on 7 can be accomplished by setting the compatibility mode of the installer to Windows XP SP2 (or SP3). Don't enable single sign-on. Upon reboot, the service will not start because of missing dependencies.
- Go to the installation directory and set the rgsender.exe compatibility mode to Windows XP SP2 (for performance reasons, oddly, SP3 gives laggy remote desktop response).
- Run rgsender.exe
- The screen will then lock, so unlock it in the VI console (if you try to connect using the RGS Receiver at this point, you'll get a blank screen)
- Log in using the RGS Receiver
- Enjoy the somewhat rich remote Windows 7 desktop user experience without RDP 7 (somewhat because advance graphics features needing acceleration won't work due to SVGA II limitations)
Issues encountered so far:
While usable, this ghetto rig isn't practical and should be used for demo or testing purposes only.
- Collaboration sessions with another user will not work because the dialogue does not pop up
- UAC notifications pause the screen because RGS can not display it, you need to go to the console to click out of it. A quick fix is to disable the UAC notification all together
- If at any point 7 locks the screen while you are away from it, you won't be able to log in. Doing the console walk of shame is the only way to unlock it so far or one can turn off the "lock when away from computer" feature all together.
- The sound may be distorted, turn the volume down to fix this. The output audio is oddly using the microphone input...
- Disconnecting from the virtual desktop will leave it unlocked. While this is good because you can log back in (until 7 locks itself), please be advised that the virtual desktop is vulnerable to others that have VI client console access.
- Although vSphere was used for this, RGS may run on Windows 7 in ESX 3.5 but without the SVGA II driver (not tested).
- We pulled this RGS setup all the way up to 1920x1200 with good results. We haven't tried dual screens yet although it may take some effort to do so because the second display is not coming up in the virtual machine.
And for fun, this post was created using Windows 7 with RGS through a VPN connection over wireless. But of course an image does not do it justice.
HP RGS (v5.2.5) on Windows 7 on vSphere (Addendum)
Thanks to a tip from Greg Hughes, he has noted that the latest version of HP RGS can be installed onto Windows 7 without using the workarounds noted above. Due to the licensing changes, the parameter:
SMBIOS.reflectHost = "true"
is no longer needed in the .vmx file.
Some issues encountered during this run:
- Screen blanking does not work. RGS does not even give a warning that the screen is visible at the console.
- The sound may be distorted, turn the volume down to fix this.
- RGS icon does not show up on task bar.
- If the system is locked on the console side, the RGS session will lock of course. Entering the password on the RGS session will unlock the session however mouse control is cut from the RGS session. Enabling remote keyboard/mouse may solve this however the RGS icon is not available on the taskbar. There may be another way to enable it...
We have included a quick demo of RGS 5.2.5 running on Windows 7. The recording program that we used made the video a little sluggish (as can be seen from the not-so-smooth mouse movements which should otherwise be smooth when using RGS regardless of connection quality).
Somewhat rich remote Windows 7 desktop user experience? You be the judge:
http://engineering.ucsb.edu/~duonglt/vmware/RGSonSeven
This (option found on: sanbarrow.com however unsupported it may be by VMware and/or HP) is by far the most useful feature we've discovered while testing HP's RGS display protocol in our VDI environment. It works in versions pre-ESX3.5 however we don't remember how far back the compatibility stretches. From what we can recall, this does not work in ESX 3.0. This option has been tested with HP Remote Graphics Software Sender version 5.1.5 running on Windows XP SP2 and SP3 and is being used daily with dual 1280x1024 screens on an HP thinclient.
To enable multiple displays for virtual machines in ESX 3.5, insert the following into the .vmx file or use the "Configuration Parameters" in the VI client that corresponds to the virtual machine:
svga.numDisplays = "x"
where x is the number of displays including the primary display. In the case of this example, it should be set to 2.
The PC version of HP's Remote Graphics Software only supports 2 screens so please set it accordingly. Afterwards, connect to the virtual desktop using the RGS Receiver and enable the second screen as if on a physical workstation. This option will allow you to fully expand windows in their respective screens without using special display spanning software (Go RGS!!).
Issues:
- When connecting to the virtual desktop using the RGS Receiver, the video will be somewhat corrupted if any of the displays on the virtual desktop is set to 32bit. This can be fixed by setting the display depth to 16bit for both screens. The problem seems to be related to the VMware SVGA driver as the corruption can be seen to occur inside the VI client console.
- The second display can not sit directly above the first display. To fix this, set the second (secondary) display to be below the first (primary) display and align the entire virtual display to the top of your physical display layout.
- Some little icons don't fully display. It is pretty annoying when it happens but we've seen this seldomly occur when using the VI client (or the Device Manager as another example) inside the virtual desktop on the primary screen. Moving the VI client (or affected application) over to the secondary screen or clicking on the icons (if possible) will sometimes fix it...
Additional Settings:
svga.vramSize = "25165824"
svga.maxHeight = "1200"
svga.maxWidth = "1920"
These settings are documented in the HP RGS documentation and are needed to increase the virtual machine's display resolution capability (to 1920x1200) and video memory size (to 24MByte). Please be aware that this option imposes additional memory overhead for the virtual machine being modified. Please size the parameters accordingly to your VDI setup.
RGS on Windows 7 on vSphere
After the Windows 7 RC came out, we were naturally inclined to throw it into our ESX3.5 environment. The main aim was to test it using RDP 7 (the VI console is a tad bit unresponsive because the SVGA driver isn't compatible) but we realized that only Windows 7 has the RDP 7 client so in turn, you would need another Windows 7 box (physical) to connect to the Windows 7 VM with RDP 7 (inefficient and no fun to say the least). So instead of installing 7 on a physical box, we decided to go the unconventional (or more affectionately, ghetto) route: get RGS running on 7.
The first issue in our quest to get a "rich remote Windows 7 desktop user experience" is the SVGA II video driver. RGS relies on the underlying "virtual" video card to display information. Video performance without the SVGA driver, as it stands, is quite simply crap and would continue to be so through RGS. To get around this problem, this virtual machine was pushed over to vSphere (with motivation from Eric Sloof's ntpro.nl article) and it's virtual hardware/VMware tools upgraded.
- Make sure the SMBIOS.reflectHost = "true" parameter or licenses are installed where appropriate
- Connect to the console of the virtual machine
- Installing the RGS sender (we used v5.1.5) on 7 can be accomplished by setting the compatibility mode of the installer to Windows XP SP2 (or SP3). Don't enable single sign-on. Upon reboot, the service will not start because of missing dependencies.
- Go to the installation directory and set the rgsender.exe compatibility mode to Windows XP SP2 (for performance reasons, oddly, SP3 gives laggy remote desktop response).
- Run rgsender.exe
- The screen will then lock, so unlock it in the VI console (if you try to connect using the RGS Receiver at this point, you'll get a blank screen)
- Log in using the RGS Receiver
- Enjoy the somewhat rich remote Windows 7 desktop user experience without RDP 7 (somewhat because advance graphics features needing acceleration won't work due to SVGA II limitations)
Issues encountered so far:
While usable, this ghetto rig isn't practical and should be used for demo or testing purposes only.
- Collaboration sessions with another user will not work because the dialogue does not pop up
- UAC notifications pause the screen because RGS can not display it, you need to go to the console to click out of it. A quick fix is to disable the UAC notification all together
- If at any point 7 locks the screen while you are away from it, you won't be able to log in. Doing the console walk of shame is the only way to unlock it so far or one can turn off the "lock when away from computer" feature all together.
- The sound may be distorted, turn the volume down to fix this. The output audio is oddly using the microphone input...
- Disconnecting from the virtual desktop will leave it unlocked. While this is good because you can log back in (until 7 locks itself), please be advised that the virtual desktop is vulnerable to others that have VI client console access.
- Although vSphere was used for this, RGS may run on Windows 7 in ESX 3.5 but without the SVGA II driver (not tested).
- We pulled this RGS setup all the way up to 1920x1200 with good results. We haven't tried dual screens yet although it may take some effort to do so because the second display is not coming up in the virtual machine.
And for fun, this post was created using Windows 7 with RGS through a VPN connection over wireless. But of course an image does not do it justice.
HP RGS (v5.2.5) on Windows 7 on vSphere (Addendum)
Thanks to a tip from Greg Hughes, he has noted that the latest version of HP RGS can be installed onto Windows 7 without using the workarounds noted above. Due to the licensing changes, the parameter:
SMBIOS.reflectHost = "true"
is no longer needed in the .vmx file.
Some issues encountered during this run:
- Screen blanking does not work. RGS does not even give a warning that the screen is visible at the console.
- The sound may be distorted, turn the volume down to fix this.
- RGS icon does not show up on task bar.
- If the system is locked on the console side, the RGS session will lock of course. Entering the password on the RGS session will unlock the session however mouse control is cut from the RGS session. Enabling remote keyboard/mouse may solve this however the RGS icon is not available on the taskbar. There may be another way to enable it...
We have included a quick demo of RGS 5.2.5 running on Windows 7. The recording program that we used made the video a little sluggish (as can be seen from the not-so-smooth mouse movements which should otherwise be smooth when using RGS regardless of connection quality).
Somewhat rich remote Windows 7 desktop user experience? You be the judge:
http://engineering.ucsb.edu/~duonglt/vmware/RGSonSeven
Cloudafied Desktops: HP RGS on Amazon EC2
Provided is a quick recording of how RGS (v5.1.5) performs on a "cloud" hosted machine when playing Flash and Quicktime videos. The capture software that we used made the video a little sluggish (as can be seen from the not-so-smooth mouse movements which should otherwise be smooth when using RGS regardless of connection quality). User interface performance was crisp and interaction was very near to the all important “local feel” (which is uncharacteristic of RDP connections).
A Windows AMI configured as a "High-CPU Medium (c1.medium)" instance type was selected for this session. The HP RGS image quality was arbitrarily set to 50% to conserve bandwidth and processing load. As this is an initial proof of concept, we did not optimize the image quality parameter and as so it will be left as an additional exercise in the future. Due to time constraints, common office productivity software was not tested and demonstrated on the cloudafied desktop however we strongly believe that RGS would perform well in this area as most common office productivity software is static and thus not bound by the CPU and connection bandwidth requirements necessary for dynamic multimedia content.
We believe that performance can be improved because the EC2 hosted Windows machine is not running an optimized video driver, that is, it is using the standard Windows VGA adapter driver. This drawback limits the maximum desktop size to 1280x1024 (without explicit hacks to increase the resolution capability if at all possible). Additionally, an older version of RGS was used during testing on an operating system not intended for desktop use (although changing processor scheduling and memory usage parameters may improve apparent desktop performance); newer versions of RGS running on the intended platforms may offer improved performance. Despite these drawbacks, multimedia performance was still surprisingly satisfactory.
And now to the video:
http://engineering.ucsb.edu/~duonglt/vmware/RGSonEC2
A Windows AMI configured as a "High-CPU Medium (c1.medium)" instance type was selected for this session. The HP RGS image quality was arbitrarily set to 50% to conserve bandwidth and processing load. As this is an initial proof of concept, we did not optimize the image quality parameter and as so it will be left as an additional exercise in the future. Due to time constraints, common office productivity software was not tested and demonstrated on the cloudafied desktop however we strongly believe that RGS would perform well in this area as most common office productivity software is static and thus not bound by the CPU and connection bandwidth requirements necessary for dynamic multimedia content.
We believe that performance can be improved because the EC2 hosted Windows machine is not running an optimized video driver, that is, it is using the standard Windows VGA adapter driver. This drawback limits the maximum desktop size to 1280x1024 (without explicit hacks to increase the resolution capability if at all possible). Additionally, an older version of RGS was used during testing on an operating system not intended for desktop use (although changing processor scheduling and memory usage parameters may improve apparent desktop performance); newer versions of RGS running on the intended platforms may offer improved performance. Despite these drawbacks, multimedia performance was still surprisingly satisfactory.
And now to the video:
http://engineering.ucsb.edu/~duonglt/vmware/RGSonEC2
Subscribe to:
Posts (Atom)