WilliamLam.com

How to Run Windows 8 on vSphere 5 (for reals)

by // 7 Comments

Awhile back I wrote an article about running Windows 8 on vSphere 5, but the trick did not work. There was an issue during the installation that caused a system panic in the OS and prevented Windows 8 to be installed. VMware did not officially support Windows 8 as a guestOS in vSphere 5 as Windows 8 itself was not released, only a developer preview was available.

It looks like VMware has been hard at work to get support for Windows 8 running on the vSphere 5 platform and I recently got a tidbit that the issue was resolved in a recent ESXi 5 patch. Make sure you keep this on the DL .... they maybe watching 🙂

Disclaimer: VMware still does not officially support Windows 8 on vSphere, this is mainly for educational and testing purposes. Do not use this in a production environment

Here are the five easy steps to run Windows 8 on ESXi 5

  1. Download and install ESXi500-201112001 (patch02) from VMware patch repository.
  2. Create either a Windows 7 or Windows 2008 R2 regular VM (must be either of these guests)
  3. Edit your VM and under "Hardware->Video Card" enable 3D graphics support (this is required if you plan on running VMware Tools). You will also need to use e1000 network driver, VMXNET3 does not work
  4. Install Windows 8 using ISO
  5. Sit back and wait for the installation to complete. 

Here are a few screenshots of Windows 8 running on ESXi 5

So there you have it, you can now run the developer preview of Windows 8 on vSphere 5!

FYI - VMware does have a KB article regarding Windows 8 on vSphere which I hear will be updated very shortly. Be sure to follow it for the full details when it is updated.

UPDATE: 

If you decide to install VMware Tools (which you should always), after a reboot, you may notice the system just sitting on the splash screen and not allowing you to login. The fix is to enable 3D graphics support. Power down your Windows 8 VM and edit the settings under Hardware->Video Graphics and check the 3D box and then power back on your VM.

Using a VNC Client to Connect to VMs in ESXi 5

by // 10 Comments

The ability to connect to a virtual machine using a VNC client has been available since the early days of VMware GSX as described by this VMware KB article. The required .vmx configuration can also be applied to virtual machines running on ESX(i), but is not officially supported by VMware. With ESXi 5, this continues to work but there is one additional caveat users should to be aware of, which is the new firewall that has been introduced in ESXi 5.

In addition to the three .vmx configurations:

  • RemoteDisplay.vnc.enabled = [true|false]
  • RemoteDisplay.vnc.port = [port #]
  • RemoteDisplay.vnc.password = [optional]

Users need to also enable the ports selected for each virtual machine on the ESXi firewall. Here is an example of a firewall rule that needs to be created:

Take a look at this blog post for details on configuring custom firewall rules including persisting the custom rules upon a system reboot.

Here are a few screenshots of configuring the .vmx configurations and using a VNC client to connect to the powered on virtual machine.

Only the first two .vmx configurations are required, if you do not set a password, anyone can connect to the virtual machine as long as they know the hostname/IP Address of your ESX(i) host and port.

To connect to a specific virtual machine, you will specify the hostname/IP Address of the ESX(i) host and port for the given virtual machine. If you set a password, you will need to also provide that before you can connect.

Please be aware of the limitations and security concerns of using VNC. VMware Remote Console or standard RDP/SSH should still be considered for virtual machine remote access.

ghettoVCB + ghettoVCB-restore Updates

by // 6 Comments

I finally got a chance to finish up the documentation on some of the new feature enhancements and bug fixes for both ghettoVCB and ghettoVCB-restore this weekend. One of the biggest change is both ghettoVCB and ghettoVCB-restore are now bundled together and ghettoVCB-restore is now being version controlled on github just like ghettoVCB. This has been on the backlog for awhile and I am sorry it took this long to get implemented.

Here are the release notes for the enhancement/fixes for both ghettoVCB + ghettoVCB-restore. Hope you enjoy these updates and if you have any issues, please report them on the ghettoVCB VMTN group.

ghettoVCB 

Enhancements:

  • ghettoVCB & ghettoVCB-restore is now packaged together and both scripts are versioned on github
  • ESXi 5 firewall check for email port (Check FAQ #33 for more details)
  • New EMAIL_DELAY_INTERVAL netcat variable to control slow SMTP servers
  • ADAPTER_TYPE (buslogic,lsilogic,ide) no longer need to manually specified, script will auto-detect based on VMDK descriptor file
  • Using symlink -f parameter for quicker unlink/re-link for RSYNC use case
  • Updated documentation, including NFS issues (Check FAQ #19 for more details including new VMware KB 1035332 article)

Fixes:

  • vSphere 4.1 Update 2 introduced new vim-cmd snapshot.remove param, this has now been updated in script to detect this new param change
ghettoVCB-restore

Enhancements:

  • Support for ESX(i) 5.0
  • Combined ghettoVCB + ghettoVCB-restore scripts
  • ghettoVCB-restore is now versioned on github