Working with differencing disks in VirtualBox

For some time now I have been trying to make persistent differencing disks work in VirtualBox. The idea is to have one base disk with all the software that all the VMs you want to deploy needs. Typically the OS, all patches up until the time you created the base disk, common apps like Flash etc. You then generalize this disk. In the Windows world this means running the System Preparation Tool (sysprep.exe) to remove all machine specific data from a VM. Now you can use this disk as the starting point for several new VMs and save a lot of disk space. Typically all virtualization software is able to use a differencing disk, or delta disk, for each VM. This disk only stores the changes made to the base disk in a new disk file, without making any changes to the base disk itself.

In VirtualBox the immutable disk type is what you use for the base disk. Once it is generalized you change its type from normal to immutable. Whenever you create a new VM and connect the immutable disk to it; VirtualBox will create a differencing disk with the VMs changes. This is where I have been having problems. In my scenario I want to keep the VM state in the differencing disk file between reboots, but VirtualBox, by default, will reset the differencing disk on every power cycle of the VM if the VM is running with an immutable base disk. According to the documentation you can modify this behaviour with the VBoxManage.exe tool. Here’s how:

VBoxManage.exe modifyhd <differencing disk file or disk uuid> –autoreset off

This is what I have been doing with my differencing disks. When I later inspected the disk with VBoxManage.exe, it correctly stated that autoreset was indeed off. But whenever the VM power cycled the disk was reset and the autoreset flag was set back to on.

Initially I thought that maybe this was a bug in VirtualBox regarding the VHD disk format, which is what I use for all my VMs, but the same problem exists with VirtualBox’s own virtual disk format VDI. I also read several posts from other people struggelig with this functionality, but their problems were related to the actual use of VBoxManage.exe, were for different host OSs (I use Windows 7/8), or something else. The reason I kept on trying, though, was that some people were actually able to make it work.

At some point I found another disk type in VirtualBox, the multiattach type. I really had not used it before since all the documentation on how use persistent differencing disks in VirtualBox used immutable disks. This is what the VirtualBox documentation online has to say about the multiattach disk type:

An image in multiattach mode can be attached to more than one virtual machine at the same time, even if these machines are running simultaneously. For each virtual machine to which such an image is attached, a differencing image is created. As a result, data that is written to such a virtual disk by one machine is not seen by the other machines to which the image is attached; each machine creates its own write history of the multiattach image.

Technically, a “multiattach” image behaves identically to an “immutable” image except the differencing image is not reset every time the machine starts.

So there it was! The multiattach disk type is the one to use! I changed by base disk from immutable to multiattach and now my VMs keep their differencing disks across power cycles. It seems that even though VBoxManage.exe can change the autoreset type of a differencing disk that is running off an immutable disk; the flag is not honored and is reset on every power cycle. The question now is why you can actually change that flag when it will not be honored? Would be very simple to just inform the user that immutable disks will always reset, and that multiattach should be used if you want to keep the VM state.

Anyway, VirtualBox is a great product, and also free!

Here is the link regarding the disk types in VirtualBox:

Until next time!

Some Windows Virtual PC Notes

  • Press the DEL key to enter the VM BIOS
  • If you can’t install the Virtual PC Integration Components on Windows XP and you get a 1603 error in the log file; delete the c:\windows\system32\drivers\wdf01000.sys and retry the install.
  • Press SHIFT+ESC while the VM is starting to view the console instead of just the progress bar.
  • To mount a floppy image, use the scripts provided here:
  • Sysinternals’ Disk2Vhd is an excellent tool to P2V your machines into Windows Virtual PC. It even takes care of setting the correct HAL in the boot.ini file. Get it here:
    NOTE: The technique that Disk2Vhd uses will make it impossoble for you to install a Windows XP service pack. More info here:
  • If you need to run older OSs on Windows Virtual PC you can use the AV Additions from Virtual PC 2007. This will give you VM Additions support for Windows 2000 and DOS. Get the Virtual PC 2007 install file and extract it, then run an administrative install using msiexec.exe /a <path>. In the folder you specified you will find the ISO file with the VM Additions from Virtual PC 2007. Mount the file in your guest as you would any ISO file.
  • Microsoft has published a Windows Virtual PC Tips document: Windows Virtual PC Tips
  • The Windows Virtual PC blog can be found here:
  • The acronym RAIL means Remote Applications Installed Locally. RAIL technology is used to publish apps in the VM to the host.
  • The Windows Virtual PC Home page:

SCVMM P2V and ISA Server 2006

I recently upgraded my home network to Forefront Threat Management Gateway (TMG), retiring my old ISA Server 2006 server. I exported my ISA configuration and imported it into TMG, but to be on the safe side I decided to keep a copy of the server as a virtual machine. I used the P2V wizard in System Center Virtual Machine Manager (SCVMM) R2, but after I hit the Scan System button this error appeared:

VMM is unable to complete the request. The connection to the agent <ISA Server FQDN> was lost.

Ensure that the computer <ISA Server FQDN> exists on the network, WMI service and the agent are installed and running and that a firewall is not blocking HTTP and WMI traffic.

ID: 3157
Details: The RPC server is unavailable (0x800706BA)

Preparing to run the P2V wizard I had already created a new access rule allowing all traffic between the SCVMM and ISA Server computers, and disabled the Strict RPC compliance on the rule:

Apparently something was interfering with the RPC communication. Since my P2V rule was at the top of the Firewall Policy whatever was causing the problem had to be in the System Policy. I displayed the System Policy in the Firewall Editor and looked through each rule that specified RPC communication to the ISA Server. Turns out there was only one; the Microsoft Management Console (MMC) rule. To successfully perform a P2V of an ISA Server you need to disable the Strict RPC compliance setting. There was no way to do that in the MMC rule in the System Policy. Since all System Policy rules are processed before the Firewall Rules the MMC rule matched the RPC traffic and blocked parts of it necessary for P2V. I disabled the MMC rule, leaving only my P2V rule. Now the wizard worked correctly.