I am a big fan of virtualization of operating systems. It allows for easy testing and obviously running multiple operating systems on one machine. At my company, we use VMWare ESX for infrastructure virtualization, but for my own use (professionally and personally) I really like Oracle’s VirtualBox. It is fast, reliable, and best of all, free.
As I work for a large, centrally managed company, we unsurprisingly use a standard (Windows) operating system across all of our hardware. As a right-thinking computer user, this is clearly not acceptable. While I wish I could just discard the standard company system image, I cannot do so. For my daily work, I am a Linux fan (Fedora is my distribution of choice). Virtualization allows me to merge those two worlds in a relatively harmonious way. My end goal is to run my company’s OS image inside a virtual machine on top of my preferred Linux installation. But getting there can be a challenge.
Installing an OS inside a VM is straight-forward and not worthy of a blog post but that does not help me particularly because I need to use the company-provided imaging tool that not only sets up the OS, but installs all of the corporate software and settings. This is done using a pretty slick tool (name intentionally withheld) that handles everything once the computer is registered on the back end by our IT staff.
This works great if I am installing onto the bare metal. Otherwise, there are challenges. Below is a slightly dramatized version of my install process. I don’t tell every iteration I tried but hopefully it is helpful to someone.
Once I got my new machine, I happily blew away the company OS install and got Linux working. (After making a backup, what kind of heathen do you think I am?) VirtualBox, check. Got bootable image of system imaging tool, check. Here we go.
Unknown computer
Well, I guess that makes sense. Our IT staff registered the physical machine; their backend would know nothing about a VM running on top of it. I pondered what they could use to identify the machine. Obvious choices included:
- MAC Address
- Hardware Serial Number
- CPU Serial number (ick)
I decided to start with MAC address as that was the easiest to change in the VM. I wanted to make the VM use the same MAC address as the computer itself. In order to do that, however, I had to change the computer to use a different one temporarily, as having duplicate MAC addresses on the same physical network will cause problems. (I am using bridged networking.) So, I changed the MAC address of the computer using ifconfig to something new. (I just incremented the last byte by 1.) And then copied the original one into VirtualBox. This can be done under the advanced settings for the network adapter.
I rebooted into the imaging software again and, success, it started imaging the machine. I was quite pleased with myself. Sadly, it was short-lived. The imaging utility put the OS on the virtual machine but then died once it had booted into Windows and wanted to start installing further software.
In reviewing the logs, I saw the same sort of error as I had gotten originally, that the computer was not recognized by the back end system. This seemed odd as It got part of the way through the install. It appeared that at this later stage of the install the tool used a different set of information to identify the computer on which it was running.
A specific section of the log file caught my eye
-------------------------------------------------------------------------
Make: Innotek GmbH Model: VirtualBox Mfg:
Serial Number: 0
- - - - - - - - - - - - - - - - - - - - - - - - -
I could see where this might cause a problem as these are not representative of the actual hardware. These values are returned to an operating system by examining the Desktop Management Interface (aka, DMI) of the PC. Thankfully, I researched VirtualBox and there is a way to set the values that it provides to a child OS. In order to determine what values to use, I used the linux dmidecode tool. This provided a list of the underlying values I would need:
# dmidecode 2.12
SMBIOS 2.7 present.
35 structures occupying 1856 bytes.
Table at 0x54E3F000.
Handle 0x0010, DMI type 0, 24 bytes
BIOS Information
Vendor: Hewlett-Packard
Version: L70 Ver. 01.10
Release Date: 06/24/2014
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 8192 kB
[truncated]
Buried in the advanced section of the VirtualBox manual is a section entitled Configuring the BIOS DMI information which outlines the commands to set all of these values. I ended up setting more than I probably needed. (I had to wrap these commands, pull onto 1 line each if you need to run them.)
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor"
"Hewlett-Packard"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVersion"
"L70 Ver. 01.10"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiBIOSReleaseDate"
"06/24/2014"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor"
"Hewlett-Packard"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiSystemProduct"
"HP ZBook 15"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiSystemVersion"
"A3009DD10203"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiSystemSerial"
"XXXXXXXXXXX"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiSystemSKU"
"F9Y23UP#ABA"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiSystemFamily"
"103C_5336AN G=N L=BUS B=HP S=ELI"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiSystemUuid"
"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiBoardVendor"
"Hewlett-Packard"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiBoardProduct"
"string:1909"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiBoardVersion"
"KBC Version 94.51"
VBoxManage setextradata "M3065"
"VBoxInternal/Devices/pcbios/0/Config/DmiBoardSerial"
"XXXXXXXXXXXXX"
(I removed the actual serial number from the listing above.)
After this, I reran the imager for what turned out to be the final time and everything worked.
In the end it turned out to be a bit more work than I outlined above, but the critical steps were covered. I found it both a very frustrating and fun experience (once I got it working). A great puzzle to solve. It shows the power of virtualization software and how it is very unwise to trust what hardware tells you about itself as it is easy to manipulate.