Customizing ESXi ISO for RTL drivers

Since I had a laptop lying around with a broken video card and needed to do some VM experiments on it, I tried to deploy a recent VMware ESXi image on it but... ran into issues with the network card, a Realtek 8111/8168/8411 series, which the installer does not detect and thus is blocking.

So then I dug up a bit and found out that until ESXi 7.0 (which  you still have a change to inject a community-supported driver and produce a custom ISO from it. Normally there is an ESXi Customizer PS script that can help with it but, what do you know, you can't use unsigned PS files on some corporate laptops...

So then I turned back to this very targeted blog article and took the hard way, luckly still having the VMware PowerCLI at hand, to do it by hand in the PS shell.

The first hurdle to stumble over was fetching the VMware bundle files -- apparently VMware only offers the ISO images for "free" usage and the bundle files are kept for "licensed" users. Nevertheless, I was able to download the "security patches" bundle via the VMware Product patches page.

Then I had to work around some quirks about acceptance levels (VMware is serious about supported configurations both in hardware and in software) and some weird signature checks -- here is the "adapted" list of commands:

> Add-EsxSoftwareDepot "C:\...\esxi-customizer\drivers\net55-r8168-8.045a-napi-offline_bundle.zip", "C:\...\esxi-customizer\ESXi670-202004002.zip"
> Get-EsxImageProfile
Name                           Vendor          Last Modified   Acceptance Level
----                           ------          -------------   ----------------
ESXi-6.7.0-20200401001s-no-... VMware, Inc.    21-Apr-20 6:... PartnerSupported
ESXi-6.7.0-20200404001-stan... VMware, Inc.    21-Apr-20 6:... PartnerSupported
ESXi-6.7.0-20200401001s-sta... VMware, Inc.    21-Apr-20 6:... PartnerSupported
ESXi-6.7.0-20200404001-no-t... VMware, Inc.    21-Apr-20 6:... PartnerSupported
> New-EsxImageProfile -CloneProfile ESXi-6.7.0-20200404001-standard -name ESXi-6.7.0-20200404001-standard-RTL8111 -Vendor Custom
> Set-EsxImageProfile -ImageProfile ESXi-6.7.0-20200404001-standard-RTL8111 -AcceptanceLevel CommunitySupported
> Get-EsxSoftwarePackage | Where {$_.Vendor -eq "Realtek" }
Name                     Version                        Vendor     Creation Date
----                     -------                        ------     -------------
net55-r8168              8.045a-napi                    Realtek    16-Apr-18 9:2...

> Add-EsxSoftwarePackage -ImageProfile ESXi-6.7.0-20200404001-standard-RTL8111 -SoftwarePackage net55-r8168 -Force
> Export-EsxImageProfile -ImageProfile ESXi-6.7.0-20200404001-standard-RTL8111 -ExportToIso -filepath C:\...\esxi-customizer\VMware-ESXi-6.7.0-20200404001-RTL8111.iso -NoSignatureCheck

Mute your PC speaker (bell) under FreeBSD / VMware

If your daily job is taking place in an open-space shared office then most likely you will want your laptop/PC to be as quiet as possible in order not to disturb your co-workers. Unfortunately the FreeBSD console does employ quite a loud bell signal (beep) and lots of operations in the terminal are prone to trigger it (especially if you are accustomed to TAB completion).

To disable generating the bell sound in FreeBSD at the console you can set the following sysctl in /etc/sysctl.conf:

hw.syscons.bell=0

Unfortunately it does not work to set it in the bootloader (/etc/boot/loader.conf). However, if you're running under VMware there is another trick — add the following line to the .vmx configuration file of the VM in question:

mks.noBeep="TRUE"

Alternatively you can add it to on of the following configuration files to make the change global for all your VM's:

• Linux: ~/.vmware/config
• Windows: C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\config.ini

PS: to disable the bell in the X interface you need to run "xset b off".

Photos from SNW Europe 2009 conference

Here are a few pictures I made while participating at the SNW Europe 2009 conference:

• The conference (held at the Congress Frankfurt, Germany)
• Some slides from the conference

The conference gathered topics such as Storage, Cloud Storage and Services, Virtualization, Solid Storage, IT Management, etc.

Running oldie VMware Server 1.0.x on latest Ubuntu

If you're like me and hate to get along with the VMware Server 2.x resource hog then you will want to go for the older and more streamlined VMware Server 1.0.x (you will also get a real console client too).
Now if you do that on the modern Ubuntu distros then you will step into some troubles (Server 1.0.x shows its age). Most of them can be solved following the tips here (performance tips included!). However here are some more hidden gems:

• The latest 2.6.27 kernels have some changes which break the building of the VMware kernel modules (stub sources are really old anyway); use the patcher here (yes, it works for Server too).
• At least the MUI component assumes that /bin/sh is Bash, which on Ubuntu is really dash — this in turn will break setting the LD_LIBRARY_PATH environment and apache will complain for missing libraries; correct the shebang magig at the top of the initialisation file /etc/init.d/httpd.vmware.

Good luck. And don't forget that 1.0.x is really old and already obsoleted by VMware in favor of 2.0.x...

Network messup in Ubuntu Jaunty when using VMware

While I was testing a brand new Ubuntu Jaunty (9.10 alpha) installation on my Fujitsu-Siemens laptop to checkout whether it better reacts to the suspend issue, I stumbled over another problem: after installing VMware Workstation the network setup would get messed up at every boot requiring manual tweaking.

It turns out that the NetworkManager service, in its great wisdom, was trying to automatically initialize the vmnet1/vmnet8 virtual interfaces created by VMware (it's using them as network injection points for the VM machines and they are managed by the vmware startup script). That means running the DHCP client over them and acquiring some garbage IP settings (these settings are supposed to be acquired by the contained VMware virtual machines, not by the physical box!). Subsequently this was installing a phoney VMware default route and DNS server entries, overriding the expected wireless settings, which in turn renders networking useless.

It seems this new behavior may have been triggered by a change in the [un]managed mode of the NetworkManager service in Ubuntu Jaunty. However, trying to change the managed=true/false statement in /etc/NetworkManager/nm-system-settings.conf yielded no results.

Luckily you can easily fix this by adding specific configuration files in /etc/NetworkManager/system-connections/ to prevent NetworkManager from touching the VMware network interfaces. You can use the following commands (assuming you kept the default interface numbering):

cat > /etc/NetworkManager/system-connections/vmnet1 << EOF
[connection]
id=vmnet1
autoconnect=false
EOF

cat > /etc/NetworkManager/system-connections/vmnet8 << EOF
[connection]
id=vmnet8
autoconnect=false
EOF

VMware Workstation 6 and Ubuntu Gutsy 7.10 / Linux kernel 2.6.22-9

Had a rough time trying to make Workstation 6 work on Ubuntu Gutsy — the vmnet-only kernel module was failing to compile. After trying a few patches flying around VMware VMTN forums, I was finally able to use the vmware-any-any-update113 tarball to fix the problem.

Procedure:

1. Unpack vmware-any-any-update113.tar.gz
   

   $ tar xvfz vmware-any-any-update113.tar.gz


2. Copy over the vmnet.tar file into your VMware lib/modules sources directory
   

   $ cd vmware-any-any-update113
$ cp vmnet.tar /usr/lib/vmware/modules/source/


3. Run vmware-configure.pl

Good luck!

Digg this