Drive Numbers Keep Changing!

[lloydsmart]

Hello. First, I think I should explain a little about what I use virtualbox for:

I have a HTPC with a bunch of hard drives in it that are formatted in XFS and contain media. This was fine when I used to run Ubuntu Linux, but now I use Windows 7, and I needed a way to access my XFS partitions.

What I did was setup a small VM using virtualbox that contained a minimal installation of Ubuntu Server, which accessed the XFS partitions and shared them over SMB. I can then access these SMB shares on Windows. Great.

My problem is to do with raw disk access. In order to get to the xfs partitions on my ubuntu guest, I had to create vmdk files for the raw hard drives. The command I used to do this was:

Code: Select all

VBoxManage internalcommands createrawvmdk -filename c: \Users\Lloyd\.Virtualbox\drive0.vmdk -rawdisk \\.\PhysicalDrive0

for drive 0, etc.

I did this with all six of the drives I wanted to use in Ubuntu, and intentionally left out the drive containing my Windows C partition, as I know that can cause serious damage.

All went fine and I got the shares up and running.

All was good until I restarted Windows.

Then I found that all my drive numbers had changed, and when I went to boot up the VM I found that it was trying to access my host's Windows partition, because its drive number had now changed in windows's "Disk Management"!

This has happened several times now and I need to know if there is some sort of workaround. Is there any way that I can either force Windows not to play around with the drive numbering, or else to tell VirtualBox not to use any vmdk that points to the C drive?

Thanks for any replies.

P.S. I'm new here so please go easy if I've missed something obvious, lol!

[lloydsmart]

*bump*

Anyone?

[butako]

Same problem here.
The PhysicalDrive# number changes after reboot of Windows7! Anyone found a solution? Is there an alternative static way of addressing the disks?

[BillG]

Quite an interesting discussion, but what does it have to do with VirtualBox? The fact that you are running Windows under VirtualBox does not automatically make a problem a VirtualBox problem. It is only a Vbox problem if the OS behaves differently from the same OS running on hardware.

[butako]

Hi Bill,
you are right, it is not a VirtualBox problem but a Windows problem (and I found articles on Microsoft's support site to suggest so).

However wondering if anyone else has experienced this problem and has some suggestions to fix/workaround? the vbox feature of using raw disk on Windows host OS is quite risky as is.

Just a suggestion, when creating the vmdk files using vboxmanage command there is a more reliable / static drive addressing method in Windows that Vbox could use than simply \\.\PhysicalDrive#?

Thanks

[alan242]

This has annoyed me off and on since I started using win 7 too. I think I might have a solution. However, it might not work for later versions of windows as Microsoft has been moving away from this functionality in the boot process.

In NT, 2000 and XP, BOOT.INI specified a ARC device name that was used to tell the boot loader where the primary partition was to boot from. ARC names are assigned at boot time from the controllers that are discovered. In order for the system to boot properly these assignments always had to remain static. Otherwise, windows would loose track of your disks. They will remain the same unless you do something like switch controllers or move the disk from one port to another on it's current controller. With newer boot manager, these device names are not used anymore for booting. However, windows still assigns ARC names in the NT object namespace to each disk and partition.

To find out the ARC names of your disks, you will need the WinObj utility from NTInternals/SysInternals. This utility will enumerate the objects in the NT and Win32 object namespaces.

Here's how to find out the corresponding ARC name to a \\.\PhysicalDrive#.

Open up Disk Management and get your current disk numbers. I have five drives. Currently I see:

Disk 0 - 64GB SSD
Disk 1 - 1.5 TB HD
Disk 2 - 250 GB HD
DIsk3 - Dynamic 289GB
DIsk4 - Dynamic 289GB

Next start WinObj and click on the GLOBAL?? folder. This is the Win32 namespace.

Scroll down to the PhysicalDrive# devices. You'll see something like:

Code: Select all

PhysicalDrive0  SymbolicLink   \Device\Harddisk0\DR0
PhysicalDrive1   SymbolicLink   \Device\Harddisk1\DR1
PhysicalDrive2   SymbolicLink   \Device\Harddisk2\DR2
PhysicalDrive3   SymbolicLink   \Device\Harddisk3\DR3
PhysicalDrive4   SymbolicLink   \Device\Harddisk4\DR4

Now expand the Device folder. You should see a Harddisk# folder for each device. If you look at each device folder, you'll see a DR# device object and symbolic links for each partition. If you have a different number of partitions on each drive, you can see how each folder relates to the drive.

Now that you know which drive is which in your system, click on the ArcName folder. You'll see something like:

Code: Select all

multi(0)disk(0)rdisk(0)                         SymbolicLink      \Device\Harddisk0\Partition0
multi(0)disk(0)rdisk(0)paritition(1)    SymbolicLink      \Device\Harddisk0\Partition1
multi(0)disk(0)rdisk(0)paritition(10)  SymbolicLink      \Device\Harddisk0\Partition10
multi(0)disk(0)rdisk(0)paritition(11)   SymbolicLink      \Device\Harddisk0\Partition11
...
multi(0)disk(0)rdisk(1)                         SymbolicLink     \Device\Harddisk1\Partition0
multi(0)disk(0)rdisk(1)paritition(1)   SymbolicLink      \Device\Harddisk1\Partition1
multi(0)disk(0)rdisk(1)paritition(2)   SymbolicLink      \Device\Harddisk1\Partition2
multi(0)disk(0)rdisk(1)paritition(3)   SymbolicLink      \Device\Harddisk1\Partition3
multi(0)disk(0)rdisk(1)paritition(4)   SymbolicLink      \Device\Harddisk1\Partition4
...

And so on depending on how many disks and partitions on each device.

You will need to take note of are the ARC entries that do not have a partition() qualifier and are linked to partition0 on a disk. These represent the entire disk.

At this point, you might want to reboot once or twice to see the PhysicalDrive# change around. When it does change, look at the ArcName folder in the NT namespace. The ArcName will not change, but the \device\Harddisk# it points to will change.

If you see both change, then this will not work for you.

If they links do stay static like they are supposed to, then you can proceed with the below.

Assuming you aready have a valid VMDK file, you just need to change the references. The syntax was the tricky bit.

In a VMDK file that references the entire 1.5 TB drive, I changed

RW 2930277168 FLAT "\\.\PhysicalDrive1" 0

to

RW 2930277168 FLAT "\\.\GLOBALROOT\ArcName\multi(0)disk(0)rdisk(1)" 0

GLOBALROOT is a special link that points out of the GLOBAL?? win32 namespace subset up to the root level of the NT namespace.

If you have a VMDK that references individual partitions, you need change each occurrance of PhysicalDrive in the file.

Save the VMDK file and start Virtualbox up. It should not complain about not not being able to validate any of the disks. If it does, stop and recheck the changes. If it does not complain, you should be able to boot the VM and the VM should be able to mount the disks or partitions.

Good Luck,

Alan

[FrederikB]

Same here. I was totally perplexed and puzzled at first . Win8.1 host Vbox5 LinuxMint guest. 2disks for Win, 3 raw for Vbox Mint. So total 5.
Added a new 4TB disk - a challenge on its own, I had gparted crashes, gpt errors etcetera but maybe I was hindered already by the drive# problem without noticing it. One has to realize before being able to understand and act. (Off topic: I put the 4TB in another host, USB disk would also have been good, booted with Mint liveCD and gparted was doing fine).

This 4TB is a WD Green and it starts slower than the Samsung Spinpoints I have otherwise. Although also each of the Samsungs have different startup speed - which in my case is fortunate. But the WD is always the last one so my Drive4 is always the WD4TB.
I noticed the drive shuffle happens when starting the host from a power down. A warm reboot brings (and after that other reboots leaves) them in the same order. Reading the msg I fear that Win8.1 and quite soon 10 will maybe not work on the Arcname/WinObj approach so I have not(yet) tested that.

In my case (stable behaviour, only 2 conditions) there are two simple solutions without fiddling with Arcnames: one is to reboot the host directly after starting (it shuffles the disks back to warm order) the other is to maintain different physical disk directories with different vmdks; one with the order 0,1 and 4 (warm reboot) and one with the 2,3 and 4 (start after power down). You obvioulsy need to define different vmdk sets created for and during the different disk orders, since the disks will have different UIDs which are written in the vmdks during the vboxmanage command.

The only thing with different sets is to have the correct SATA controller definitions in the Vbox GUI. That is a minute work.
Since I reboot the host just a few times per year, that isnt a big deal.
You just need to be aware.

[wistlo]

Same here. ...

In my case (stable behaviour, only 2 conditions) there are two simple solutions without fiddling with Arcnames: one is to reboot the host directly after starting (it shuffles the disks back to warm order) the other is to maintain different physical disk directories with different vmdks;

Same experience here with a 2 condition machine (i.e., two PhysicalDrives). In the past I've burned up a few hours recreating vdmks when mysteriously they simply stopped working. In 2016, I made careful notes that included which physical real-world drive mapped to a specific PhysicalDrive. (In Windows, "Physical" seems to be at the whim of a hardware race condition.) Today (2018), a hard crash from an extended power outage brought the two drives, at 1TB WD Blue and 4 TB WD Red, back up in opposite PhysicalDrive order. A warm boot brought them back in the expected order.

I run Windows 10 as the host with a guest Ubuntu to run a cloud storage backup using mounted LInux drives.

This thread saved me a lot of time, eight years after the original postings. I second the observation above that there is room for improvement in how vdmks are configured for Windows hosts.

[mpack]

I second the observation above that there is room for improvement in how vdmks are configured for Windows hosts.

And what would be your specific suggestion? Noting of course that the design of VMDK is controlled by VMWare, not VirtualBox.