WilliamLam.com

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

vGhetto VMworld 2011 Charity Bike Ride

08.13.2011 by William Lam // 1 Comment

Continuing the tradition of the VMworld Fun Run started by Duncan Epping back in 2010, VMworld 2011 will include both a fun run and new this year, a bike ride run in Las Vegas. This year, the VMworld 2011 Red Rock Canyon Bike Ride and Fun Run event will not only be for recreation but will also be for charity! The bike ride will be 23 miles and the fun run will be approximately an hour and distance will vary based on your speed. Also the event will be starting at 5am on Monday 29th, so make sure you recover from the VMworld Underground party the night before. 

The registration fee for the fun run is $110 USD and bike ride is $150 USD, which in my personal opinion is quite steep. I still think the event is worthwhile and this will be a great way to get some exercise, especially since I won't be able to ride my road bike as I normally do throughout the week. If you are attending VMworld 2011 in Las Vegas, you should consider taking part in this event for a great cause. All proceeds and registrations will be donated to the Friends of Red Rock Canyon, a group of volunteers who help to preserve the Red Rock Canyon in Nevada.

Okay, so here is the challenge I pose to the VMware and virtualization community: If you would like to see me to ride the 23 miles for Friends of Red Rock Canyon, please consider sponsoring me by clicking on the link provided below. All proceeds collected will be donated to Friends of Red Rock Canyon and I will also get my employer to match the final amount.

*** Please RT, re-post and share this with your colleagues, friends and vendors! If you would like to sponsor me to ride in this event or would like to donate to a worthy cause, please consider donating. ***

Click on the "Donate" button below to donate, any amount will help as this is for charity! 

Categories // Uncategorized Tags // vmworld

When Can I Run Apple OSX on vSphere 5?

08.12.2011 by William Lam // 9 Comments

There was a recent post from the famous Scott Drummonds about Running Apple OSX Lion on vSphere 5 and Scott provided his interpretation/opinion of Apple's EULA on virtualizing Apple OSX. Though the EULA can be somewhat confusing, it is true that with the release of vSphere 5, you now can run OSX 10.7 (Lion), 10.6 (Snow Leopard) and 10.5 (Leopard) as a supported guestOS in ESXi 5.

...but there is a catch (there's always a catch)

UPDATE: As of vSphere 5.1, the Apple Mac Pro is now fully supported on running on ESXi 5.1, to get more details, please take a look at this article.

The caveat is that in allowing VMware to run OSX as a virtual machine on vSphere 5, the physical hardware that ESXi 5 is running on MUST be Apple hardware and specifically the XServe 3.1. For those of you who do not follow Apple's hardware closely, the XServe line was recently EOL as of January 31, 2011 and that brings up an interesting problem. If you wanted to virtualize Apple OSX, you would have had to have purchased XServes prior to January 31st or start looking on Ebay with your corporate card 😉

Now, the Apple EULA is not the only thing that is regulating this requirement, in addition, VMware had to implement a software check within ESXi 5 to ensure that the physical hardware is in fact Apple hardware before allowing you to properly boot up an OSX virtual machine. The check looks for the SMC (System Management Controller) when an OSX virtual machine is being powered on and if this check fails, you will get an error and the virtual machine will be powered off automatically. The presence of the SMC is a new property that is exposed in the vSphere 5 API under "hardware" section of the ESXi host.

The property will either return true or false on whether SMC is present. You can easily check your ESXi 5 host by using the vSphere MOB and pointing your browser to the following URL:

https://[esxi5-hostname]/mob/?moid=ha-host&doPath=hardware


Now you can easily determine whether or not your physical host can support running Apple OSX VMs.

As I understand from the beta, only XServer 3.1 will be officially supported and you will not be able to install ESXi 5 on older versions of the hardware. I have also heard mixed results on folks being able to install ESXi 5 on Mac Mini's and Mac Pro's. At this point, hopefully Apple has a change of heart and will update their EULA to allow ESXi 5 to run on "currently available" Apple hardware such as Mac Mini and Mac Pro.

Categories // Uncategorized Tags // ESXi 5.0, mac, osx, vSphere 5.0

How to Persist Configuration Changes in ESXi 4.x/5.x Part 2

08.10.2011 by William Lam // 5 Comments

Continuing from part 1 of How to Persist Configuration Changes in ESXi 4.x/5.x Part 1, here is another method which I prefer when trying to persist configuration changes in ESXi. When ESXi boots up, it loads it's filesystem into memory which the modules to be loaded up are determined by the configuration found in /bootbank/boot.cfg and /altbootbank/boot.cfg for the two respective partitions (primary / backup).

UPDATE: You can now persist configuration files such as firewall rules and others using the new VIB Author Fling, please take a look at this article for more details.

Here is an example of ESXi 4.x default boot.cfg:

~ # cat /bootbank/boot.cfg
kernel=b.z
kernelopt=
modules=k.z --- s.z --- c.z --- oem.tgz --- license.tgz --- m.z --- state.tgz --- vpxa.vgz
build=4.1.0-348481
updated=1
bootstate=0

Here is an example of ESXi 5.x default boot.cfg:

~ # cat /bootbank/boot.cfg
bootstate=0
kernel=tboot.b00
title=Loading VMware ESXi
kernelopt=no-auto-partition
modules=b.b00 --- useropts.gz --- k.b00 --- a.b00 --- ata-pata.v00 --- ata-pata.v01 --- ata-pata.v02 --- ata-pata.v03 --- ata-pata.v04 --- ata-pata.v05 --- ata-pata.v06 --- ata-pata.v07 --- block-cc.v00 --- ehci-ehc.v00 --- s.v00 --- ima-qla4.v00 --- ipmi-ipm.v00 --- ipmi-ipm.v01 --- ipmi-ipm.v02 --- misc-cni.v00 --- misc-dri.v00 --- net-be2n.v00 --- net-bnx2.v00 --- net-bnx2.v01 --- net-cnic.v00 --- net-e100.v00 --- net-e100.v01 --- net-enic.v00 --- net-forc.v00 --- net-igb.v00 --- net-ixgb.v00 --- net-nx-n.v00 --- net-r816.v00 --- net-r816.v01 --- net-s2io.v00 --- net-sky2.v00 --- net-tg3.v00 --- ohci-usb.v00 --- sata-ahc.v00 --- sata-ata.v00 --- sata-sat.v00 --- sata-sat.v01 --- sata-sat.v02 --- sata-sat.v03 --- scsi-aac.v00 --- scsi-adp.v00 --- scsi-aic.v00 --- scsi-bnx.v00 --- scsi-fni.v00 --- scsi-hps.v00 --- scsi-ips.v00 --- scsi-lpf.v00 --- scsi-meg.v00 --- scsi-meg.v01 --- scsi-meg.v02 --- scsi-mpt.v00 --- scsi-mpt.v01 --- scsi-mpt.v02 --- scsi-qla.v00 --- scsi-qla.v01 --- uhci-usb.v00 --- imgdb.tgz --- state.tgz
build=5.0.0-441354
updated=1

As we learned from the previous article, the cron'd /sbin/auto-backup.sh generates a local.tgz which is then converted to state.tgz which contains all files automatically backed up by VMware. This file is loaded up along with other modules as part of the boot process. Understanding this, allows us to take advantage of this feature for persisting our own configuration files.

Here is an example use case for creating .ssh directory for SSH keys and persisting a script
(ghettoVCB.sh) in /bin for an ESXi 4.x host:

Step 1 - Re-create the modified directory structure and files in a temporary local path which will then be tarred and gzip. An example would be the following:

Actual change:
/.ssh/authorized_keys
/bin/ghettoVCB.sh

Temporary local directory structure of change:
/tmp/.ssh/authorized_keys
/tmp/bin/ghettoVCB.sh

Note: It is very important to ensure that the modified files get the stickybit permission set. As noted in the last article that upon a change, the visorFS will automatically create a special file to denote it for backup but also it allows the file to be writable at some later point for custom files being added.

Step 2 - You will use the tar utility to tar/gzip the contents in a file with extension .tgz. One thing to note, the file name including the extension must not exceed 12 characters. In our example, we made two changes and re-created the local structure under /tmp. We will need to change into /tmp directory and tar up the contents by using the following command:

/tmp # tar -czvf ghetto.tgz .ssh/ bin/
.ssh/
.ssh/authorized_keys
bin/
bin/ghettoVCB.sh

Now you should have the contents of .ssh and bin within your *.tgz file. To verify and view the contents, you can run the following command:

/tmp # tar -tzvf ghetto.tgz
drw------- 0/0 0 2011-08-10 04:10:11 .ssh/
-rw------T 0/0 399 2011-08-10 04:10:11 .ssh/authorized_keys
drwxr-xr-x 0/0 0 2011-08-10 04:10:24 bin/
-rwxr-xr-t 0/0 46973 2011-08-10 04:10:24 bin/ghettoVCB.sh

Step 3 - Next we need to copy the *.tgz file into /bootbank and modify the /bootbank/boot.cfg to ensure our new module is included in the boot up process

cp /tmp/ghetto.tgz /bootbank

Here is what the modified ESXi 4.x boot.cfg should look like after:

kernel=b.z
kernelopt=
modules=k.z --- s.z --- c.z --- oem.tgz --- license.tgz --- m.z --- state.tgz --- vpxa.vgz --- ghetto.tgz
build=4.1.0-348481
updated=1
bootstate=0

The next time you reboot the system, you will automatically have your .ssh directory containing your SSH keys and the ghettoVCB script under /bin directory.

Now this is great for an inline modification, but what about creating custom configuration files and including that as part of a default kickstart installation? What about something like custom firewall rules in ESXi 5? In the following example, we'll include a custom firewall rule called "virtuallyGhetto.xml" which will be stored in /etc/vmware/firewall when the contents of the module is extracted.

Step 1 - We of course need to create the XML file containing the firewall rule and create the directory structure in which it will be unloaded to.

/tmp/etc/vmware/firewall/virtuallyGhetto.xml

Step 2 - Next we'll tar up the local contents

[root@air tmp]# tar -zcvf ghetto.tgz etc/
etc/
etc/vmware/
etc/vmware/firewall/
etc/vmware/firewall/virtuallyGhetto.xml

Step 3 - This new package will need to be stored on you installation server which will be reachable via http using wget and as part of the %firstboot stanza in your ESXi 5 kickstart. It will download the *.tgz file and append the entry in /bootbank/boot.cfg configuration file. Here are the entries that should go into your kickstart:

# Adding custom files to boot argument (e.g. custom firewall rules,etc)

wget http://air.primp-industries.com/esxi5/ghetto.tgz -O /bootbank/ghetto.tgz
sed -e '/modules=/s/$/ --- ghetto.tgz/' -i /bootbank/boot.cfg

Note: If you add custom files that are located under /etc and you have the stickybit enabled on your file, changes made will persist upon the next reboot by either manually running /sbin/auto-backup.sh or letting it run via cron. If you add custom files that are not located under /etc, any change you make must be periodically updated in your custom *.tgz file else the next reboot, the original file will be loaded.

Categories // Uncategorized Tags // ESXi 4.1, ESXi 5.0, vSphere 4.1, vSphere 5.0

  • « Previous Page
  • 1
  • …
  • 511
  • 512
  • 513
  • 514
  • 515
  • …
  • 560
  • Next Page »

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