#Apple virtualization framework full
#Apple virtualization framework mac

The ‘ppi’ setting does not make any difference to what’s shown in the guest, with one exception. I also haven’t had any more crashes when creating VMs.

The appearance of the guest is then optimal. The ‘Snap’ command now correctly sets the size of the VM’s window. When I tick the ‘HiDPI’ setting, the guest’s total display size is double the stated dimensions and HiDPI mode is available. Nice work on this new beta - it is working perfectly in terms of display resolution. Many thanks for the hat tip in the article. Although I haven’t investigated further yet, I’m not sure whether you could run 5 VMs simultaneously at present. I also tried running more than two VMs simultaneously on an M1 Max, and it refused on the grounds of some resource limit.

#Apple virtualization framework full

Lightweight virtualisation does give full access to Metal and the GPU, although I don’t know how well that would share across so many VMs. You also have the problem of bandwidth on output, I suspect, where 5 minis are likely to beat a Studio Ultra hands down. I suspect that the VMs would have problems with the Jump connect audio, but that’s something you’d need to try out. If you were to have 1 Studio M1 Ultra, then you’d have something around 3-4 GPU equivalents and only 16 P cores.įor that sort of task, I think you’d need 4 vCPUs per VM, which would limit your Ultra to less than the 5 minis.

#Apple virtualization framework mac

If you were to have 5 M1 (or, soon, I hope) M2 Mac minis you’d have 5 GPUs and 20 P cores. I think it boils down to counting cores and GPUs. That’s an unusual and interesting question. Unfortunately, because of the limitations of the Virtualization framework, GUI Linux will require Ventura, but I also intend providing a command-line Linux for Monterey and later. I have other writing commitments over the coming week, and will then be returning to virtualising Linux. Viable beta 3 now gives you complete control to experiment as you wish.

for Recovery Mode, 1600 x 1000 at 80 ppi and no HiDPI.

once a VM has been fully installed and set up, 1600 x 1000 at 80 ppi with HiDPI turned on, and the Displays pane in the guest set to 1600 x 1000 HiDPI, for a completely crisp virtual display that also scales well even to full screen.

for the first run after installing macOS in a new VM, 1600 x 1000 at 80 ppi and no HiDPI.

I prefer running my VMs at a resolution of 1600 x 1000, so this is what I set Viable to: Worse still, there are two situations in which you can’t engage HiDPI: when a VM undergoes personalisation and configuration on its first run, and in Recovery mode (supported only on Ventura hosts). Unfortunately, when your VM first starts up with those dimensions, it will size its virtual display to 5120 x 2880 without HiDPI, and you have to engage 2560 x 1440 HiDPI in its Displays pane. So if you want the virtual display to fill a Studio display, set its dimensions to 5120 x 2880 rather than the nominal dimensions of the maximum window size, 2560 x 1440. When using a Retina display, one way to guarantee optimum clarity is to put the virtual display into HiDPI mode, normally by supplying doubled display dimensions. Careful choice of those can result in a virtual display which is scaled correctly but very slightly fuzzy, or one that is as crisp and clear as the host’s. When an app using Apple’s Virtualization framework configures the virtual display device used by a macOS guest, it passes three integers: two for the display dimensions, and its pixel density in pixels/inch. This addresses problems with virtual display resolution and quality, and I’m particularly grateful to Greg for the testing he has done, and the invaluable pointers that he provided. I’m pleased to release a third beta of my macOS virtualising app for Apple silicon Macs, Viable.