Enhancement: booting via hypervisor from pre-existing media, such as from a /dev/diskN

[markmi]

This is related to some other requests but is more specific in a way I do not see referenced. It is analogous to something I used to do with Hyper-V (version 1) when it was handy for my context back then. I had boot media used to boot FreeBSD directly, that I'd also boot via Hyper-V under Windows 10 Pro when I was using Win10Pro for other reasons/purposes from other media. (The request is more generic, despite my using that FreeBSD context as the form of example I use.) This was very handy for the context/time and would be again.

Taking the historical example that into somewhat more macOS terms, imagine media (the example is via USB3) with:

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *240.1 GB   disk2
   1:                        EFI EFI                     52.4 MB    disk2s1
   2:                FreeBSD UFS                         215.9 GB   disk2s2
   3:               FreeBSD Swap                         24.1 GB    disk2s3

So, an UEFI context. It would be nice to be able to boot such a thing under a hypervisor. (Again: FreeBSD is over specific here, although I'd like to be able to use FreeBSD this way.) In this, the EFI partition contains the EFI loader that knows how to deal with the content of other partitions in order to load and start the kernel involved (that is in the UFS partition for the FreeBSD example).

Note: In my context, such media is moved between systems to boot any of a number of them at will. The hypervisor use would just be one more place to move the media to.

Both x86_64 and aarch64 would be of interest (native for each, not emulated, at least for my context), although I'd likely use aarch64 more often if both were available.

I'll note that I'm fine for it being used via an advanced form of use that required, say, sudo use to establish a sufficient context. (That is just an example for illustration.) Similarly, if I had to find the right /dev/diskN name to use each time. (The GPT label text would be handier by being stable even when N is not a fixed value from use to use.)

I will note that /Volumes/ and the finder do not necessarily end up with anything for such media in macOS but diskutil does for anything I'd be interested in.

[osy]

You may be able to mount the USB drive inside the VM and try to boot from it. If you want to share some of the USB drive with macOS, it is not possible (see #5027, #5051, #5169, etc)

[markmi]

Just to be explicit: I was not suggesting any sharing of the USB drive content with macOS, or /Volumes/... content with the hypervisor booted system.

I'm unclear on the pre-VM-boot "mount the USB drive inside the VM" but I'll see if I can figure out what that is referring to (for how to possibly do such). Part of the issue is that normal terminology has one mount a file system that is in a partition, such as /dev/disk2s1 's EFI file system. Getting access at the /dev/disk2 level would not normally be called a mount of /dev/disk2 that I'm aware of.

Thanks for the references.

[markmi]

Looks like the BETA VZDiskBlockDeviceStorageDeviceAttachment used with VZVirtioBlockDeviceConfiguration might be part of this (given some means of assigning the likes of a "/dev/rdisk42" to the VM to the exclusion of other VMs or the host macOS over a period of use).

[markmi]

VZDiskBlockDeviceStorageDeviceAttachment is no longer Beta (for macOS 14.0+). But it still documented as having the status of needing to involve privilege escalation that is not allowed in apps distributed on the Mac App Store. So, it seems that UTM is unlikely to ever depend-on/use VZDiskBlockDeviceStorageDeviceAttachment.