How to easily fix virtualbox removable drives being used as physical drive vmdk's when they get unplugged/replugged? - powershell

Question

I am using removable thunderbolt (NVMe) drives that are partitioned/configured for bare metal boot drives in Virtualbox. The idea is that I either boot this drive bare metal or in Virtualbox.
When un-plugging/re-plugging removable drives in Windows, my Virtualbox rawvmdk files consistently break. The reason I found is that there is no guarantee how Windows may path your physical drive each time or where you plug it in. And you can't just create rawvmdk's for all the likely paths because Virtualbox machines can't have a broken vmdk file. Each time it breaks, I have to get just right the particulars of how to correctly re-create the rawvmdk file, and the right order of configuration of the virtual machine. It takes a bunch time/frustration to figure this out each time. I need an easy and consistent way to start the machine.
The following powershell script I worked on looks up the windows path for a hardcoded drive serial number, and does everything necessary to replace the broken rawvmdk file with a working one. The script shows the serials for all the host machine's physical drives each time it runs:
echo "*** This powershell script finds a raw drive by its serial number, and then attaches it to a desired vbox virtual machine***"
echo "*** When VBOX loses its track on the drive, between unplug/replug, this will fix it for that serial."
echo "*** Must be run as administrator ***
"
echo "Here are all the drives we can find:"
Get-Disk |Format-Table -Autosize -Property DeviceID, Model, Path, Partitions, SerialNumber
#This is the Serial number we're looking for:
$SERIAL = "6479_110F."
echo "Attempting to attach Drive Serial Number: $SERIAL
"
#Get the Drive Path for that Serial
$DrivePath = Get-Disk | Where-Object -Property SerialNumber -eq $SERIAL | Select -ExpandProperty "Path"
if ( $null -eq $DrivePath )
{
echo "Could not find your hardcoded serial number"
} else
{
# Where we want to put the rawVMDK file
$VMDKStorage = "C:\VirtualBox VMs\LaCie_Drive\"
cd "$VMDKStorage"
# The Target Vbox VM to attach the rawvmdk
$MachineName = "Ubuntu"
# Arbitrary name for controller.
$ControllerName = "NVMe"
#The Filename to call the rawvmdk
$FileName = "Firecuda.vmdk"
#Clean up the Target Machine of the non-working image.
echo "Attempting to remove specified vmdk hdd from target machine"
Start-Process -FilePath "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" -ArgumentList "storageattach $MachineName --storagectl $ControllerName --port 0 --device 0 --medium none" -NoNewWindow -Wait
# Remove the Virtualbox traces of the File
Start-Process -FilePath "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" -ArgumentList "closemedium $FileName --delete" -NoNewWindow -Wait
echo "Creating the new RawVMDK File"
Start-Process -FilePath "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" -ArgumentList "internalcommands createrawvmdk -filename $FileName -rawdisk $DrivePath" -NoNewWindow -Wait
echo "Adding the now supposedly working RawVMDK to Target Machine"
Start-Process -FilePath "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" -ArgumentList "storageattach $MachineName --storagectl=NVMe --port 0 --device 0 --type hdd --medium=$FileName" -NoNewWindow -Wait
echo "You now can start the Machine up normally from VirtualBox."
# I found I don't need to start VBox with admin privledges for my VM to work.
}
I did find that when plugging my drive in one particular port on my machine that windows wanted to call my drive an entirely different serial number. After changing this code's serial number to correct for that, I found that I also had other problems. Namely that the kernel did not recognize any of the LVM configuration that contained my drive root (/). What it appears is that on this computer port, linux cannot identify these partitions as nvme partitions, and that this mucks up the boot configuration pretty badly (I was stuck in initramfs). I believe this a USB-C port and that the drive has some alternative hardware to make the drive "work". I really want the drive to operate at NVMe speeds, so I'm just going to avoid this port.
Hope this helps someone.