WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

vSphere ESX 4.0 - Crash VM Bug?

05.29.2010 by William Lam // Leave a Comment

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

Categories // Uncategorized Tags // ESX 4.0, snapshot, vSphere 4.0

HP Remote Graphics Software ESX/ESXi VDI Tricks

05.29.2010 by William Lam // Leave a Comment

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

Categories // Uncategorized Tags // ESX 4.0, hp rgs, vdi

  • « Previous Page
  • 1
  • …
  • 558
  • 559
  • 560

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025