VBoxManage createrawvmdk using custom MBR partition table

[Heidgear]

Hi,
I'm trying to connect a virtualbox virtual machine to a physical partition on my host's hard-drive. Using the -mbr parameter you can pass a custom MBR to the virtual disk, but the problem is that only the bootloader of that MBR is taken into consideration while the partition table from the file is ignored and the one from the host's hard-drive is used instead.
The reason I want to specify a custom partition table is so that I can change my "active" partition because Windows Vista (and 7 I guess) refuses to install in a non-active partition and I want to be able to install Vista from within VirtualBox on a desired partition on my physical hard-drive, without having to mess with my real hard-drive's MBR.
Hope this makes sense.

Now, from a fast look at the relevant code, it seems like this is not possible currently (correct me if I'm wrong) but I think it would be useful for the reason I showed above (if feasible).

Thanks

[mpack]

I'm trying to connect a virtualbox virtual machine to a physical partition on my host's hard-drive. Using the -mbr parameter you can pass a custom MBR to the virtual disk, but the problem is that only the bootloader of that MBR is taken into consideration while the partition table from the file is ignored and the one from the host's hard-drive is used instead.

Hmm. I've not tried it, but that isn't what the manual says. The manual says that the partition table in the replacement MBR is stored unmodified and can be completely different from the partition table used by the host. Have you tried it?

[Heidgear]

Well, the virtualbox user manual I got (from virtualbox.org download page) reads like this:

In some configurations it may be necessary to change the MBR code of the created
image, e.g. to replace the Linux boot loader that is used on the host by another boot
loader. This allows e.g. the guest to boot directly to Windows, while the host boots
Linux from the “same” disk. For this purpose the -mbr parameter is provided. It
specifies a file name from which to take the MBR code. The partition table is not
modified at all, so a MBR file from a system with totally different partitioning can be
used.

I interpret this as "use a MBR file to load an external bootloader but leave partitions as in the host's hd". This makes sense if you consider that the whole purpose of creating a VM linked to a partition is to use a specific *physical* partition on your hard drive, meaning that it would make little sense to change partition information (like offset or size) and indeed the only thing I need to change is the active partition.

[mpack]

I interpret this as "use a MBR file to load an external bootloader but leave partitions as in the host's hd". This makes sense if you consider that the whole purpose of creating a VM linked to a partition is to use a specific *physical* partition on your hard drive, meaning that it would make little sense to change partition information (like offset or size) and indeed the only thing I need to change is the active partition.

You are indeed accessing a physical partition, but the offset of that partition in the virtual disk need not be the same as its offset in the physical disk, in fact it won't be unless you are access the whole disk rather than a partition.

Consider this VMDK structure (not using actual VMDK syntax, instead using a syntax I'm making up on the spot for clarity) :-

VMDK_Descriptor::-
Extent(1):FLAT_FILE,image=local_MBR_and_track0.bin,size=63 sectors
Extent(2):RAW_PHYSICAL,image="\\PhysicalDrive.Partition1",size=1000000 sectors

Notice that the "partition1" extent starts on the host drive wherever it actually starts (only the host OS knows or cares where that is). However in the virtual VMDK drive it starts at sector 63. In this case you would indeed need a replacement MBR with partition table showing that this partition starts at LBA 63, and my interpretation of the -MBR option described in the manual is that it is intended to cater for situations like this.

[Heidgear]

Well but the fact is that I've tried to replace the MBR partition table to change the active partition but it does not work. What I did is I simply dumped the MBR from my physical hard-drive, then opened it up in a hex editor and changed the active partition (it's pretty easy, just change a 0x00 to a 0x80 and do the opposite to inactivate the other partition). Then specified this file for the -mbr parameter but once I start the vista installation, accessing a shell and using the diskpart.exe tool it clearly says that the active partition is the old (incorrect) one, so it seems like it ignores my custom MBR partition table.

[Heidgear]

Ok, in doubt I opened the .vmdk file to check and noticed that the first 512 bytes are exactly like the first sector of an hard-drive and they are exactly like my MBR on my physical hard drive, seems like it ignored the MBR I passed (at least for those 2 bytes I changed). So I made the same 2 bytes change but this time directly into the .vmdk file and I'm trying now to see if it works.

Update: It worked! It's installing
Update2: Ok, managed to install and boot the VM successfully

[mpack]

Well done. If you are sure that VBox behaviour doesn't match the manual then perhaps you should log it on the bugtracker. You would need to give an exact example of the command you used.

[Heidgear]

Well, as I read it in the user manual my understanding is that partition information is not used from the MBR when creating virtual hard disks linked to physical partitions, so I don't think it should be reported as a bug. Maybe just a missing feature to specify which of the partitions need to be considered "active" but as I've shown is pretty easy to do this manually with an hex editor anyway.

One note is that although the virtual machine worked perfectly, booting directly into this new Windows partition (from the host machine) doesn't work. But this is actually a problem on the Windows side as it probably goes into some kind of hardware conflict. If I finish the installation and reboot the VM and log-in into the VM Windows, then reboot into the physical partition, the system chokes somewhere and I get a permanent non-responding black screen. If instead I halt and power off the virtual machine after the setup has finished but before the first reboot after the installer has done (basically the step in which Windows configures basic stuff and creates initial user etc.), then the system does boot correctly but gives an error at start, something like "Windows could not complete the installation. To install Windows on this computer, restart the installation ".

I'm not sure if this has something to do with having run the installer on the VM or if Windows just doesn't like my partitions layout or the fact that I use GRUB for the bootloader, or again the fact that the partition I installed it onto is not active on the physical drive (it is so only in the virtual disk).
My main concern for installing Windows directly from the host machine is that it might screw my other partitions up, especially considering it's an OEM recovery disk and so I fear (although not much likely) it could even pretend to recover the initial state the computer was on when I bought it.

[Heidgear]

Ok, I got everything working now. What you have to do is simply to set the Windows partition as active on the physical hard drive as well, before booting into Windows to complete the OS installation. This can be done in multiple ways, in my case I just added the option to the GRUB loader settings using:

Code: Select all

parttool (hd0,1) boot+

This tells GRUB to set the partition 1 on the first hard drive as being the active partition (note: this is valid for GRUB2+, was makeactive in previous versions).