virtualbox.org

Hi this is my first post so hopefully I have given enough info for you to help answer my question.

I have a windows 10 host with two instances of windows 10 installed on separate partitions. I would like to boot the second instance in virtual box.

Highlighted in blue is the Host OS partition and orange is the Guest:

Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 451 MB
Partition 2 Reserved 16 MB 552 MB
Partition 3 Primary 475 GB 569 MB
Partition 4 Recovery 819 MB 476 GB
Partition 5 Primary 244 GB 476 GB
Partition 6 Primary 1141 GB 721 GB

So as per the instructions: virtual box dot org /manual/ch09.html#rawdisk I attempted to create a VMDK image pointing to partition 5 with the following command:
.\VBoxManage.exe internalcommands createrawvmdk -filename win10.vmdk -rawdisk \\.\physicaldrive0 -partitions 5 -mbr win10.mbr

But I get the following error:
VBoxManage.exe: error: Cannot open replacement MBR file 'win10.mbr' specified with -mbr: VERR_FILE_NOT_FOUND
VBoxManage.exe: error: The raw disk vmdk file was not created

If I remove the -mbr part of the command two files are successfully created.

One called win10-pt.vmdk (48kb) and

win10.vmdk (1kb)

Code: Select all

# Disk DescriptorFile
version=1
CID=cbcea3dc
parentCID=ffffffff
createType="partitionedDevice"

# Extent description
RW 63 FLAT "win10-pt.vmdk" 0
RW 923585 ZERO 
RW 204800 ZERO 
RW 2048 ZERO 
RW 32768 ZERO 
RW 2048 ZERO 
RW 997369534 ZERO 
RW 322 ZERO 
RW 1679038 ZERO 
RW 322 ZERO 
RW 512000000 FLAT "\\.\physicaldrive0" 1000214528
RW 2394812416 ZERO 
RW 2191 ZERO 
RW 33 FLAT "win10-pt.vmdk" 63

# The disk Data Base 
#DDB

ddb.virtualHWVersion = "4"
ddb.adapterType="ide"
ddb.geometry.cylinders="16383"
ddb.geometry.heads="16"
ddb.geometry.sectors="63"
ddb.uuid.image="7809b9bd-33f5-42a7-b863-41d56df11de8"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.uuid.modification="00000000-0000-0000-0000-000000000000"
ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000"

So where might I be going wrong? Do I need to create an MBR file and point the command at it and if so how do I do that?

Thanks

The error looks straightforward: the file win10.mbr bin file (which you need to have created somehow) does not exist. Can you demonstrate otherwise? And how did you create it?

Also your partition map in the VMDK looks needlessly complex to me. E.g. what's with all the consecutive ZERO regions? Why not just fold them down into one? Or none?

What's with the 63 sector start extent? AFAIK that's a relic from XP days, Win10 doesn't have 63 sector alignments any more. What it does have is a boot manager.

I would expect to see just two partitions plus the boot sectors, expressed as VMDK extents something like this (I'm assuming your Win10 expects to see GPT partitions):

Code: Select all

RW <size in sectors> FLAT "win10.mbr"
RW <size in sectors> FLAT "\\.\physicaldrive0" <offset of boot partition>
RW <size in sectors> FLAT "\\.\physicaldrive0" <offset of windows partition>

Though to be honest I'm pretty sure this won't work either, that you'll need to provide a custom boot partition too. I don't really know (never needed to find out) what's in that partition so I can't advise on that.

If it was me I'd consider ways to create a Win10 VM from scratch such that the main Win10 partition is the same size as the physical one. Then I'd chop the virtual disk image into pieces to be used as VMDK extents. However even that wouldn't be enough since GPT identifies partitions using UUIDs, and I expect Win10 references those when looking for partitions to mount, so you'd have to relabel the virtual partitions with the physical UUIDs.

All in all - much easier said than done.

One problem that might be a killer:

MrSnake wrote:I have a windows 10 host
...
VBoxManage.exe internalcommands createrawvmdk

It looks like you're trying Raw Disk Access. Windows host requires the whole disk being accessed raw to be offline in the Windows Disk Management. And you can't offline the disk that is booting the host OS.

This poster reports getting Windows 10 in Virtualbox and bare metal, but it may be on two separate physical host disks: viewtopic.php?f=7&t=98410

Hi, no I haven't created a MBR file as I'm not sure how to. I was hoping it would be created automatically like the two VMDK files where.

I can't comment on the contents of the VMDK files, as I mentioned they where created by the vboxmanage.exe command. Although I have seen many people post videos online of this working successfully but they are usually just accessing an entire external drive or are using a Linux host.

Scott I'll have a read of that thread you posted. Seems like what he is trying to do is what I want too.

MrSnake wrote:I was hoping it would be created automatically like the two VMDK files were.

The only file created is the .vmdk header (a text file as you already know), to match the parameters you provided. There's no smarts to it, and in fact I prefer to create the header myself by copying and editing another - the VBoxManage command doesn't really save me much time.

If you take a naked partition then you have no boot sector(s). That means you need to create them. That means you need to know how - and in the case of a Win10 boot manager boot of a GPT partition, I don't know how.

But as Scott says, raw disk to a partition probably won't work on Windows hosts anyway. You caught me off guard have two Win10 installations like that. For some reason I was thinking dual Linux / Win10 boot, with Linux the main one.

I hope you understand that getting the OS to boot is only the first hurdle. The VM is a separate PC so it won't be possible to activate the VM without deactivating the physical copy.

Why did you create two Win10 boots on a single PC? If you don't really need that then turning the second Win10 into a VM should be relatively straightforward: just P2V the entire drive and then delete the unwanted partitions. You'll need a lot of intermediate disk space of course.

And oh yes, just for clarity: if part of your thinking is that you want raw disk access because you think it will be faster - it will not. Raw disk access bypasses host OS caching and so I predict will usually be slower.

I guessed I might have thrown you off a bit because its not something I would normally do either!

Strange thing is when I run the command it creates two files. One named win10.vmdk and one named win10-pt.vmdk the latter is a binary file of some kind and is larger in size.

Some background:
The OS I'm trying to boot was installed and customised with vehicle diagnostics software and the Indy software installer is particular about not installing it on a VM. This is a massive pain because I'm locked in a sandbox when I boot that OS and all my other tools are on my main OS or in VM's.

I have enough disk space to do P2V so I'm going to try that. If you guys have a recommended method that would be great otherwise ill just do some googling.

I have in the past converted the install to a VM using VMware converter but as soon as I booted and installed VMware tools on the VM it went down hill. It must detect that some how and activates what appears to be clunk software that must be hidden in the OS. It makes the start menu transparent and everything glitches out like crazy, I've never seen anything like it. It changes Windows into to high contrast mode and becomes totally unusable. You cant even get to click on anything to change it back.

MrSnake wrote:It must detect that some how

Then you'll probably encounter the same problem with VirtualBox anyway. While the virtual disk image (the VMDK + the physical disk partition) may have a physical touch, the virtual machine (all the virtual hardware except the virtual disk) is easily recognizable as part of a VM by any software running on the guest OS.

MrSnake wrote:It makes the start menu transparent and everything glitches out like crazy

I don't think that's intentional behaviour. Intentional behaviour would just say "VM Detected - Not Going to Run".

It sounds similar to a problem that VirtualBox users get in Win10, and it's worked around by turning off "Transparancy Effects" in Win10's display settings.

virtualbox.org

9.7.1.2. Access to Individual Physical Hard Disk Partitions

9.7.1.2. Access to Individual Physical Hard Disk Partitions

Re: 9.7.1.2. Access to Individual Physical Hard Disk Partitions

Re: 9.7.1.2. Access to Individual Physical Hard Disk Partitions

Re: 9.7.1.2. Access to Individual Physical Hard Disk Partitions

Re: 9.7.1.2. Access to Individual Physical Hard Disk Partitions

Re: 9.7.1.2. Access to Individual Physical Hard Disk Partitions

Re: 9.7.1.2. Access to Individual Physical Hard Disk Partitions

Re: 9.7.1.2. Access to Individual Physical Hard Disk Partitions