- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Watching Michael Roy on VMware podcast #588 (I think it was), how he was running 100 VM's, 8 Gig Ram (probbaly an over-simplification), but i added all that up and it came to 80Gig
No way you would be able to do this in 8Gig, even if say you had a 16GIg M1 like me i still doubt that, be possible.,. Now, Apple talks about the memory pressure being lower on the M1, which probably is the reason you can do more than on Intel under the same "conditions"... As i understand it, once a pile of memory is allocated to a VM, that's all it can play with right ? Any "memory pressure" footprint would have to be reversed for the host.... for 'other stuff', excluding the VM's. You may be able to run more of them, due to the memory fetching is part of the chip now, so everything "appears" more speedy, (doesn't have to go out externally to other chips anymore), but still the physical memory is 8 or 16GIG, that's still gonna limit VM's because regardless of footprint may be lower it would still be Physical memory limit of the Mac..
It this some sort of illusion here that Apple has made? The only way i know is to either increase the memory of the Mac, or reduce the memory in the VM's, as its still shared, M1 or not..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've run VM's with 2x the CPU's and RAM in my host without really skipping a beat (Linux, not Windows). It's pretty amazing - the unified memory makes a huge difference.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's not an illusion but virtual memory management working as intended - with a little help from Apple's unified memory and their fast SSD implementation.
Virtual memory systems do allow you to over-subscribe memory. They deal with that by keeping a working set pages for active applications in memory. To make room for those pages, macOS resorts to removing unused pages, removing file system cache pages, paging applications and swapping applications (traditional OS methods) as well as compressing unused memory.
To macOS, a virtual machine's memory is somewhat opaque. It knows it's being referenced, but it doesn't know or care what's in it. An 8GB VM will be allocated as 8GB virtual address space. That doesn't mean it will take up 8GB of memory. Last I checked, Fusion does not wire a VM's memory footprint, so it's eligible to be paged in and out by macOS as it deems fit. It'll try to keep however much of the VM's memory footprint resident depending on how the VM is using it. macOS doesn't have to move the entire VM's memory footprint to the swap/page file, just the least recently used portions - unless over subscription gets *really* bad.
Where things get interesting is when you have over-subscribed memory too much and the actively running processes (including VMs) causes repeated page/swap in-out whenever a process/thread is scheduled to run. That is reported as high memory pressure and a drop off of performance in the VM.
As a side note, you sort of have dueling virtual memory management here. The VM thinks it has memory equivalent to what you set it for. It will manage virtual memory for the applications that it has running. macOS will manage the memory of the VM application at the system level. That gets interesting when you've oversubscribed the virtual machine's memory where the VM's OS is paging in and out, and you've oversubscribe the host OS memory so it has to page things in and out. Both operations are independent of each other.
This is where unified memory and the SSD on Apple silicon come into play. Those are much faster than in earlier Macs. The user sees less performance degradation because of the speed of the page in/out operations.
However, as in life, there is too much of a good thing. You can still over-subscribe VM memory to the point where the VMs performance is impacted. I remember this being referred to in the classic CS texts as "thrashing", where the system is spending more time managing memory in and out than actually doing work. And consider that constant paging out is writes to the SSD - which over time may impact the lifespan of the the SSD.
Editor of the Unofficial Fusion Companion Guides
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't think this is doable with 8GB based on the many posts on various sites (reddit, macrumors) where people have been describing their experience with Macs with 8GB of memory. It seems that most of them are using about 2 or 3 vm's. Others with those kind of systems that are using it for development (where you'd use containers; they use less system resources than a full blown vm does) and are running into out of memory messages. From what I have read on the VMware Fusion blog it concerned a machine with more memory, 16GB, and I also recall there being a MacBook Pro with M1 Max and 64GB of memory.
Virtual memory management is at play but it is not the only thing. There is a lot more going on and it happens at 3 different levels:
- host OS
- guest OS
- the virtualisation layer (aka the in-built hypervisor from macOS and VMware Fusion that lays on top of it)
All three do their own memory management and use things like swapping, compression, deduplication and so on to use as little RAM as possible. That, however, does have its limits. There also is memory overcommitting (you assign more memory to the vm(s) than there is actually available) which works fine as long as memory doesn't get fully utalised. Even the faster SSDs on these Apple Silicon Macs will not help you there.
The settings of the vm's also play a huge role. Running 100 vm's that have been set to use no more than 512MB of memory (very doable with operating systems such as Alpine Linux, they can go even lower) is a lot easier to do when you have 16GB of memory (to name something) then it is when they use 2GB of memory.
What is definitely not at play here is Apple's unified memory. They only have that because of how they designed their Apple Silicon. The unified memory allows for having 1 single pool of RAM for all the different types of processing units in the Apple Silicon. If all these processing units were separate (like in the Intel era) they all would have had their own memory pool. As a result when a 4GB chunk of data in the memory needs to be worked on by different processing units that chunk of memory has to be copied over to the respective memory pool. Unified memory negates that because all processing units are using the exact same memory pool and so there is no need for copying things back and forth. That's a gain in time and thus speed but not size. Unified memory has no impact on the size of the objects in memory at all. The processing units may because they do the processing on it but not the unified memory itself.
That said, when you use virtualisation on an Apple Silicon machine and compare it to an Intel Mac you'll very quickly find that memory management is indeed a whole lot better as well as the overall performance. It's like as if Apple Silicon was made with virtualisation in mind. Which is why it is so sad that we don't (yet?) have nested virtualisation support. It would be awesome if we could try out the ESXi for ARM fling inside a VMware Fusion vm. Would make a Mac Studio with the Ultra a very nice homelab solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@treee agreed with everything you said, and a great post.
bottom line: how many VMs you can run simultaneously and with acceptable performance for the desired workload is dependent on your hardware config. Apple Silicon may run oversubscribed systems faster, but this still applies: nothing helps virtual like real.
Editor of the Unofficial Fusion Companion Guides
