hoakley August 1, 2022 Macs, Technology, Updates

Virtualisation on Apple silicon Macs: 7 Improving the virtual display

I’m pleased to release a third beta of my macOS virtualising app for Apple silicon Macs, Viable. 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.

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. 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 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. 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. 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.

viable1b3

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).

I prefer running my VMs at a resolution of 1600 x 1000, so this is what I set Viable to:

for the first run after installing macOS in a new VM, 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 Recovery Mode, 1600 x 1000 at 80 ppi and no HiDPI.

Viable beta 3 now gives you complete control to experiment as you wish. It’s available from here: viable1b3

I have other writing commitments over the coming week, and will then be returning to virtualising Linux. 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.

13Comments

Add yours

1

Rumorconsumer on August 1, 2022 at 6:17 pm

Howard- thank you for making this app. I haven’t downloaded it yet but I am wondering if you could tell me the answer to this question: Right now I run a video viewing lab with 5 Macs in it. I have off-site users who use Jump Desktop to remote desktop into these Macs. Jump provides an audio output device extension (I think thats right) which you select in sound prefs on the host machine and viola, you can watch video over the net AND get the audio from the host machine. Its great. If I could, Id replace those 5 Macs with 1 Mac with many cores and run 5 VMs that each could be running the Jump connect software. I tried this with Parallels and the video worked ok (no HW acceleration) but the jump audio extension thing wouldn’t output the audio properly to the remote client.

Does your solution allow for HW accelerated video watching and sound output such that this setup could work?

LikeLiked by 2 people
- 2
  
  hoakley on August 1, 2022 at 6:48 pm
  
  Thank you. That’s an unusual and interesting question.
  I think it boils down to counting cores and GPUs. If you were to have 5 M1 (or, soon, I hope) M2 Mac minis you’d have 5 GPUs and 20 P cores. If you were to have 1 Studio M1 Ultra, then you’d have something around 3-4 GPU equivalents and only 16 P cores.
  For that sort of task, I think you’d need 4 vCPUs per VM, which would limit your Ultra to less than the 5 minis.
  I suspect that the VMs would have problems with the Jump connect audio, but that’s something you’d need to try out.
  You also have the problem of bandwidth on output, I suspect, where 5 minis are likely to beat a Studio Ultra hands down.
  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.
  I also tried running more than two VMs simultaneously on an M1 Max, and it refused on the grounds of some resource limit. Although I haven’t investigated further yet, I’m not sure whether you could run 5 VMs simultaneously at present.
  Howard.
  
  LikeLiked by 1 person
  - 3
    
    Rumorconsumer on August 1, 2022 at 7:33 pm
    
    Yeah most of these are viewing relatively low res video thats just located on a local NAS that we dont want to expose outside the LAN. Not all 5 users are logged in at once. Rarely are 2 even logged in at once, but it has to be available for them to do so if they want to. So resources wise I think Im fine with one M1 Max or even a single m1 potentially. The crux of the issue is definitely much more about the audio connectivity than the CPU time.
    
    LikeLiked by 1 person
    - 4
      
      hoakley on August 1, 2022 at 9:54 pm
      
      I checked again this evening for you: the maximum number of macOS VMs allowed to run simultaneously on an M1 Mac is two. Whether that will change in the future, I don’t know, but that’s what it is at present.
      Howard.
      
      LikeLike
5

Eric on August 1, 2022 at 10:06 pm

The number of macOS VMs in the Virtualization framework is gated by Apple – since running more than two additional copies of macOS on the same piece of hardware is forbidden per EULA.

LikeLiked by 1 person
- 6
  
  hoakley on August 2, 2022 at 9:57 am
  
  Thank you. Yes, it is, of course, although the EULA is actually rather more complex than that. It’s also interesting that, despite introducing lightweight virtualization, Apple shows no sign of changing that.
  Howard.
  
  LikeLike
7

Tony Williams on August 5, 2022 at 2:14 am

Howard,

That is looking good. The one extra it would be nice to have is the ability to set the serial number of the VM before it starts so we can test deployment (my most common use of a VM).

LikeLiked by 1 person
- 8
  
  hoakley on August 5, 2022 at 6:11 am
  
  Thank you.
  I’ll look at that this weekend.
  Howard.
  
  LikeLike
- 9
  
  hoakley on August 8, 2022 at 9:52 pm
  
  Tony,
  I’ve taken a close look at this, and it’s not simple, as the serial number is an opaque blob of data, and not intended to be human-readable.
  I’m not sure why it would be any benefit to be able to set a serial number. The primary purpose seems to be to make each running VM uniquely identifiable, and it doesn’t correlate with anything in the host macOS or Mac. It’s effectively a (very large) random number as far as I can see.
  You can copy this between VMs, but it isn’t something that’s amenable to setting by the user.
  Howard.
  
  LikeLike
10

Greg on August 10, 2022 at 3:36 pm

Howard,
Many thanks for the hat tip in the article.

Nice work on this new beta — it is working perfectly in terms of display resolution. When I tick the ‘HiDPI’ setting, the guest’s total display size is double the stated dimensions and HiDPI mode is available. The ‘Snap’ command now correctly sets the size of the VM’s window. The appearance of the guest is then optimal. I also haven’t had any more crashes when creating VMs.

The ‘ppi’ setting does not make any difference to what’s shown in the guest, with one exception. The physical display size in inches reported inside the guest is calculated based on the ppi (larger when the ppi is lower), but that’s irrelevant to us.

At a lower ppi than the host’s display (I tried 80, and 109 which is half of my host’s ppi):
1) The guest display settings under ‘Scaled’ show two resolutions, eg. ‘1600×1000 (HiDPI)’ and ‘3200×2000’ without needing to toggle ‘Show all resolutions’ on.
2) On ‘first run’ setup after the VM is created, the display is not in HiDPI mode, as you stated.

However, when I select the same ppi as on my host (218):
1) The ‘Scaled’ list only contains the ‘1600×1000’ resolution, but without the ‘(HiDPI)’ label. The ‘3200×2000’ resolution is shown only when ‘Show all resolutions’ is enabled.
2) on ‘first run’, HiDPI mode is automatically selected, which makes it much easier to go through all the setup screens! You also never need to go into display settings to switch to HiDPI. macOS just does the right thing.

Therefore, for the same experience as on a physical Mac, it may be best to select the ppi which matches your host’s display.

LikeLiked by 1 person
- 11
  
  hoakley on August 10, 2022 at 4:01 pm
  
  Thank you.
  Yes, those are identical findings to mine. However, I’m mindful that much of this is still in beta, and I want to retain the flexibility to cope with future changes, should they occur. So for the moment these controls remain manual. Perhaps by the release of Ventura they’ll be stable enough to fix in code.
  I’m also wary of the fact that we’re referring to Retina displays. I have no idea what happens on non-Apple displays yet.
  At least the GUI Linux virtualisation has no such options – that’s coming here in the morning, for Ventura beta-testers only, though.
  Howard.
  
  LikeLike
  - 12
    
    Greg on August 10, 2022 at 5:19 pm
    
    I meant to say that the user should select the matching ppi, if for use on the host display; I wasn’t suggesting automatically.
    
    LikeLiked by 1 person
    - 13
      
      hoakley on August 10, 2022 at 7:29 pm
      
      Thank you. Yes, but it’s all rather fiddly at present. As things settle I think I can do better to help the user get the right combination.
      Howard.
      
      LikeLike

·Comments are closed.

Share this:

Related