2

I'm a bit confused here.

I just installed a new 128GB SSD on a Windows PC and then created a 50GB partition on that drive. I did not format it, so that it is labeled "50,00GB RAW" in the "Disk Management" utility.

It is located at \\.\PhysicalDrive0, I used VBoxManage internalcommands listpartitions -rawdisk \\.\PhysicalDrive0 to see if the partition is visible to VirtualBox.

I then used VBoxManage internalcommands createrawvmdk -filename "C:\Users\USERNAME\VirtualBox VMs\Disks\ssd370-p1.vmdk" -rawdisk \\.\PhysicalDrive0 -partitions 1 to create a vmdk representing that partition.

Then I created a new Virtual Machine and instead of creating a new hard disk, I chose "Use an existing virtual hard disk file," where I selected the beforementioned vmdk.

I mounted the Ubuntu iso as a CD and booted the VM.

I had to try this a couple of times. My main problem was that the vmdk presents itself as a 119,24GB drive, so the creation of the linux partition failed. On one attempt I told the installer, while doing a manual partitioning process during the install, that it should create a partition of 48GB, which is below the 50GB size I used in windows. This worked.

I rebooted the VM and it still worked, which leaves me a bit confused.

During the install I told it to install GRUB. Am I wrong in my assumption that some booting/GRUB-related stuff makes use of the MBR? I mean, something in the install process would need to have written something to the MBR.

Is VirtualBox emulating the MBR? Or has it written a MBR into that partition and shrunk the rest a bit?

I also tried to do a sudo fstrim -v /, which ends with a FITRIM ioctl failed: Operation not supported. Is this normal?

Also, I skipped the creation of a swap partition; could I have created one of 2 GB in size? Should I redo all the installation procedure, create a partition of 45GB and a swap of 3-4GB? Would that work?

Would I be better off using a 50GB vmdk file instead of using the RAW partition?

1
  • I occasionally use VirtualBox on Ubuntu, though I prefer the free VMware Player. I've never used a raw partition, so I cannot answer as to how it works: I can't see any benefit unless you want to have the option of booting direct at some point. The great advantage of a VMDK file is the ease of expansion if it becomes full; also a simple file copy will make an accurate back-up if the VM is supended. Related arguments apply to swapping: the only benefit of a partition is that it allows hibernation (I can't imagine this is relevant to a VM); whereas a swap file is easily made larger when needed.
    – AFH
    Commented Mar 20, 2016 at 13:41

1 Answer 1

3

The -partitions param of createrawvmdk does NOT work as the way you thought. Instead of exposing the partition(s) you specified as disk(s) to the guest, it exposes the whole disk to the guest just like when you did not specify the -partitions param. The only difference is, it masks the partitions you did not list so that you cannot read or write on them. You can use an ADDITIONAL image as the MBR for the guest, but it's limited to the boot code part (the guest will stick with the partition table on the raw disk). See 9.9.1.2. Access to individual physical hard disk partitions for details: https://www.virtualbox.org/manual/ch09.html#rawdisk

enter image description here

GRUB does write boot code to the MBR if it is installed with the target i386-pc (which is for BIOS/CSM booting). However, if it's installed with one of the EFI targets (x86_64-efi/i386-efi), it will put EFI executable on the EFI System Partition instead.

For the FITRIM ioctl to work, VirtualBox need to do proper SCSI passthrough (like, for example, Hyper-V does), so that the guest can identify and send commands to the disks (or, for SATA disks, the SCSI-ATA Translation Layer of Windows, which will translate SCSI UNMAP commands to ATA DSM/TRIM commands for SATA SSDs, for example) directly. As of VirtualBox 5.0, none of its storage controllers provides raw disk access in that level. It can be confirmed by checking and comparing outputs of sg3_utils (sg_vpd -a, sg_readcap -16 and sg_inq) on the Linux guest and the Windows host.

4
  • thanks, but is the -paritions doing any remapping? the partition I used was the first one on the drive, so did this make it easier for me? if it would have been a partition starting at the middle of the drive, would I need to write down the value of the starting point in order to use it in the installer? Or could I just say "create a 16gb partition" during the installation and Virtualbox would calculate the offset? I mean, I had two partitions on the drive, yet the installer said it was one big chunk, as big as the entire drive.
    – Daniel F
    Commented Mar 21, 2016 at 10:49
  • That's strange. You should see that there are two partitions on the guest as well. It's just the one(s) that you didn't list in the -partitions param will be "masked" so that you can't read or write on them. See this: ptpb.pw/BEfo.PNG
    – Tom Yan
    Commented Mar 21, 2016 at 18:01
  • Just edited my answer. I hope it's clearer now. Btw you sure you didn't specify the wrong drive for the -rawdisk param?
    – Tom Yan
    Commented Mar 21, 2016 at 18:15
  • Yes, I'm certain it was the correct drive. The size did match (~128GB), and the two partitions (both of exactly 50GB) were correctly seen in VBoxManage internalcommands listpartitions. All other drives are 2TB,4TB and a 100GB SSD ("C:\\") which is intact, else the PC wouldn't boot anymore. Thanks a lot for your effort.
    – Daniel F
    Commented Mar 21, 2016 at 20:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .