"can't use 64bit LBA" windows VM can't boot

[knguyen]

hi
I was trying to have windows-server-2003-64bit to take full advantage on high-performance raid-controller by using VBoxManage to grant VM permission upon a physical partition (/dev/sdb)

That physical partition /dev/sdb is actually a disk array of 40TB (raid6, 128kb stripe, 64bit LBA)

I added a SCSI Controller into the VM and then register the .vmdk image file.

The first boot is successful, the windows-guest was able to 'see' disk-1 under diskmgmt.msc .I was also able to convert disk-1 to GPT disk (so that it can fully use the entire 40TB).

The problem came in when I rebooted the VM. It hang up and could never get into the windows screen. I checked VM log and see this:

Code: Select all

int13_harddisk: function 42. Can't use 64bits lba

I've been searching around for solutions, but not luck!
any insight will be greaT!!
thanks1

[Sasquatch]

It would appear that 64 bit LBA isn't supported by VB. Please open a ticket in the Bugtracker (separate account needed) and request this feature to be added. Or, which is also possible, that the VMDK needs to be recreated. Have you tried that yet?

[knguyen]

Thanks for the reply
yeb! I've tried many times.
It worked though, i was able 'convert to GPT" via diskmgmt.msc from Windows-host.
However, subsequent reboot thereafter will fail.

any suggestion will be great!
thanks!

[Sasquatch]

That's because the change is not completed yet. The array needs to be reinitialized in order to get the effects. This means a reboot and that reloads the VMDK. That's the point when VB gives up. There is no support for hard drives larger than 2 TB. I've tried to create a normal partition table and a partition on a 12 TB array, but it failed because the partition table type is limited to 4 TB partitions.
You need to file a bug report. Do link to the report here for reference.

[knguyen]

hey
The array had been initialized in the past, using LBA 64 to support >2TB file-system.
With physical windows and physical linux, I was able to use GPT and XFS to hold up to 44TB-partition. So that, I was thinking the same thing can be achieved with VirtualBox

[Sasquatch]

But that's because your hardware is made for that. VB's emulated hardware isn't.

[knguyen]

I see!
just created/submitted a ticket!

[Sasquatch]

What's the ticket number? Link to it here for reference.

[knguyen]

#7415 = ticket number
I've place a link to this post in the report

[Technologov]

knguyen: As a workaround, I recommend you to create a small system image of Windows 2003, and access data using VBox "Shared Folders". (or SMB/NFS)

[knguyen]

hey thanks!
I've been aware of that solution .
My concern is performance as I'd really like to take advantage on the high-end raid controller.
NFS/shared-folder might have some performance penalty, yes?

[knguyen]

another update on this issue

1. I ended up re-initialize the entire 40-TB array in fedora-core host.
2. setting as RAID5, 64-bit LBA, 128KB stripe
3. use VBoxManage to create and register raid5.vmdk, bound to /dev/sdb (associated with the newly created array)
4. Use VirtualBox to add vmdk into the VM. I used 'SCSI controller' though. SATA won't work

THe VM does see the vmdk as another disk. I was able to convert the disk into GPT. The format failed, however.

[thesnake]

I'm bumping this old thread because it deals with a bug in VB that has never been fixed. Details are on the ticket page (find a ling above since I cannot post URLs).

[mpack]

I see no bug described above. 64bit LBAs don't exist for a legacy BIOS: that isn't a bug, it's a permanent fact, it will never change unless perhaps time travel is invented. Your VM would need to use an EFI BIOS and GPT partitions, which isn't supported by all guest OS - in particular Windows doesn't work with the VBox EFI BIOS.

[sobomax]

I see no bug described above. 64bit LBAs don't exist for a legacy BIOS: that isn't a bug, it's a permanent fact, it will never change unless perhaps time travel is invented. Your VM would need to use an EFI BIOS and GPT partitions, which isn't supported by all guest OS - in particular Windows doesn't work with the VBox EFI BIOS.

That's rather disappointing. The EDD int13 spec adds support for 64-bit LBA specifically without any reference to UEFI or anything like that (in fact IMHO it pre-dates that), so basically VB is diverging from most "real" BIOSes out there which can handle 64-bit EDD LBAs just fine. At the very least, the handling for that condition should be improved - instead of locking the emulator solidly (in fact it even blocks ctrl-alt-delete), the i/o function should just return error when 64-bit LBA is detected. Right now, it prevents operating system from booting even if all the boot loader code is trying to do is to read backup GPT table, which is usually at the end of the physical volume. In most cases even if that cannot be read the boot would be able to proceed properly, as long as the kernel and other boot files are within the first 2TB, which in practice is a condition that can be easily satisfied.

-Maxim