VirtualBox Windows host, Ubuntu guest installed on RAW partition

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?

Answer

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

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.