Hi everyone,

I'm a Mac user who has been wanting to run ColourSpace natively on my MacBook Pro for a long time. Until recently that wasn't realistic through a VM, but now that VMware on Apple Silicon has matured I'm finally making it work — though not without some frustrating stumbles along the way.

Steve's support has been genuinely exceptional throughout this process. This post isn't a complaint — it's an honest attempt to understand how VMware and macOS can inadvertently break a ColourSpace activation, so I can get my setup right once and for all. I hope the answers also help other Mac users avoid the same pitfalls.

My setup:
- MacBook Pro M1 Max, 32GB unified memory, 1TB
- VMware Fusion, Windows 11 ARM VM
- Anker USB-C Gigabit adapter (primary), Baseus USB-C Gigabit adapter (backup)
- i1D3
- VM stored at /Users/[name]/Virtual Machines/ on internal NVMe, iCloud sync disabled
- Current VM: 4 CPU cores, 8192 MB RAM, 8192 MB shared graphics memory

1. NETWORK ADAPTER — BRIDGED NETWORKING AND USB DONGLE STABILITY
I now have VMware set to Bridged > USB 10/100/1000 LAN, pinned specifically to the Anker. I also now plug the Anker in before launching VMware to ensure the adapter is present and stable from the start.

I believe Bridged > Autodetect was the root cause of most of my lost activations — when I plugged in the Anker after VMware had already launched, Autodetect silently switched from Wi-Fi to the USB LAN adapter, which I believe triggered the "moved or copied" hardware fingerprint check.

- Is Bridged > pinned to a specific adapter the most stable configuration for keeping the ColourSpace activation intact, and is the approach of always connecting the dongle before launching VMware the right one?
- I own two USB-C ethernet dongles — an Anker as primary and a Baseus as backup. Best practice is obviously to always use the same one, but what happens if the Anker breaks and I'm forced to switch to the Baseus? Will VMware see it as a different host adapter and risk a fingerprint change, and is there a safe procedure for handling that situation?

2. THE "MOVED OR COPIED" PROMPT — WHAT TRIGGERS IT?
I now know that "I moved it" preserves the VM's hardware identity and "I copied it" destroys it. I've also learned not to click "Generate" next to the MAC address field. The hard way, unfortunately.

What I'd really love is a clearer picture of everything that can trigger this prompt, so I have a definitive list of things to simply never touch.

- Beyond network adapter changes and MAC regeneration, what other actions in VMware Fusion on Apple Silicon are known to trigger the "moved or copied" prompt?

3. SAFE VS. UNSAFE VM SETTING CHANGES AFTER ACTIVATION
While ColourSpace is my primary reason for this VM, I'd occasionally like to use Windows for other applications, which might mean adjusting resources from time to time.

- Which settings are safe to change after ColourSpace is activated — CPU cores, RAM, shared graphics memory, display settings, USB devices?
- Are there any settings beyond the network adapter that must never be changed once the activation is in place?

4. SHARED GRAPHICS MEMORY — IS 8192 MB TOO MUCH?
My VM is currently set to 8192 MB shared graphics memory, which I understand is drawn from host RAM rather than a dedicated GPU. Combined with the 8192 MB RAM allocation, that's potentially 16GB of my Mac's 32GB unified memory going to the VM alone, for an application that isn't GPU-intensive.

- Is this excessive for ColourSpace and potentially a source of instability? What would be a sensible value on a 32GB M1 Max?

5. TPG WORKFLOWS — PGenerator ON RASPBERRY Pi 4 AND DaVinci RESOLVE
I plan two workflows, with all devices on a dedicated ethernet network:

- Workflow A: PGenerator on a Raspberry Pi 4, controlled by ColourSpace in the VM over LAN
- Workflow B: DaVinci Resolve on a separate Windows PC with a DeckLink card as network TPG, controlled by ColourSpace over LAN
For my LG OLED: the TV will be connected via ethernet for ColourSpace to upload 3D LUTs and control the display. Patch generation will come from PGenerator or Resolve — not the TV's internal generator.

- Is Bridged > pinned Ethernet the correct VMware network mode for both workflows so that ColourSpace in the VM can reliably see and communicate with the Pi and the Windows PC?
- Without a DHCP router on the dedicated switch, should all devices (Windows VM, Pi, Windows PC, LG OLED) be assigned static IPs, and is there a recommended subnet configuration?
- Are there any firewall or port considerations for PGenerator on the Pi or Resolve as a network TPG that are commonly overlooked?

6. NETWORKING HARDWARE — UNMANAGED GIGABIT SWITCH VS. CONSUMER ROUTER
For my dedicated calibration network I'm deciding between a simple unmanaged gigabit switch or a consumer router with DHCP (e.g. Cudy AX3000).

- For a closed calibration LAN running ColourSpace with PGenerator and Resolve as TPG sources, is a simple unmanaged gigabit switch the most stable and direct approach, or does a router with DHCP offer any meaningful practical advantages for this kind of workflow?

7. UPDATE SAFETY
- Are Windows Updates, VMware Fusion updates (including the offer to upgrade the virtual hardware version), and macOS updates generally safe for ColourSpace activation, or are there specific update types that carry a real risk of breaking it?

Thank you to anyone who takes the time to respond. I hope this thread becomes a useful reference for other Mac users in the same situation.

I suspect you would need to ask most of those questions to VMware Fusion support, or on their user forums.
As far as I know the "Moved or Copied" issue is a recent VMware bug - I have read about that on their forums.
I have experienced it, and after saying 'i Moved' it, it didn't cause any ColourSpace licensing issues.

But as per the Licensing page of the website, the majority of the license fingerprints of the PC are hardware.
However, VM can do strange things, without warning!

I have an M1 Mac that I use for testing, and have never experienced any license issues.
I keep all Mac OS updated, as well as all Windows OS.
And changing resources, which are just software managed allocations.
No issues.

But, network adapters are one that can/will cause issues.

Beyond that, no idea...

Steve

Those are not issues that I had with VMware, but, as Steve knows, I did not find their graphics handling to be reliable enough to work every time!

With two ColourSpace licences, I have one on a Lenovo laptop and the other is on a MacBook Pro M1. Originally tried UTM, which worked but was not able to launch ColourSpace reliably every time. The issues would be random from not connecting to devices to parts of the UI vanishing.

Moved on to VMware, unfortunately, while VMWare had fewer issues than UTM, it was still troublesome, the occasional USB disconnect. The real killer though was with vanishing graphs, it is hard to adjust RGB balance when the graph has vanished, gave up on VMware!

Those issues are now history, thanks to Steve's advice, I gave Parallels a try. This was not my first encounter with their technology having used it for other applications in the past, it was my first use with ColourSpace. The setup has been working for over two years now with no serious issues. Perhaps the only place that needs to be different from a Windows machine is connecting to the BoxIO TPG, found it best to use a travel router as the direct network connection through the macOS was just not consistent.

This has proved to be very reliable, there is also plenty of resource left on the MacBook with Windows running ColourSpace PRO that I can continue working on the mac at the same time, even running Resolve.

It is actually interesting, as for some years I ran both Parallels and VMware on my M1 Mac, testing both with every new ColourSpace release.
Due to storage issues running both (the Mac just ran out of disc memory) I had to remove one VM.
Basically as both were working perfectly I removed Parallels, on the basic that as VMware was free more ColourSpace users we likely to opt for that.

I've never seen any issues with either Parallels or VMware, after OpenGL support was updated to VMware some years back.
And every ColourSpace release is still tested on VMware.

The configuration of USB passthrough, as well as networking, wifi, etc., can be a pain.
But once configured correctly I've not seen any further issues, especially with licensing.

However, as I say network adapters can cause issues.
Usually, installing/running ColourSpace as Admin will sort such issues.
(That's a Windows thing, not ColourSpace.)

Steve

Thank you Steve and Victor — both replies have been really helpful.

Victor, good to know Parallels has been solid for you for two years, and the travel router tip for the BoxIO connection is exactly the kind of practical detail that's hard to find anywhere. Steve, the reminder to run ColourSpace as Administrator is something I'll make sure is in place on my Windows ARM install — easy thing to miss.

Since network adapters were flagged as the main variable to watch, I did some testing to understand exactly how VMware handles physical dongle changes on a Mac with no built-in ethernet. I wanted to share the results here for anyone in the same situation.

The short version is that VMware's virtual network layer is much more resilient than I expected. With the adapter pinned to a specific USB ethernet interface (rather than Autodetect), I tested the following scenarios:

- Swapping the primary Anker dongle for a different brand (Baseus)
- Removing the ethernet cable while the dongle remained plugged into the Mac
- Booting the VM with no dongle connected at all

In every case, Windows simply reported the network as disconnected — but the virtual adapter itself remained present and unchanged in Device Manager. The VM has no awareness of which physical dongle is on the Mac side, or whether any cable is plugged in. It only sees its own stable virtual network card.

I also ran these tests across a major macOS update (around 9GB) and confirmed the VM identity remained completely stable before and after.

The key takeaway for other Mac users seems to be: pin the VMware network adapter to a specific named interface rather than using Autodetect, and always connect the dongle to the Mac before launching VMware so it's present when VMware initialises. Beyond that, the virtual hardware appears to be well insulated from what's happening on the physical Mac side.

With this locked-down network configuration, I am very optimistic that the activation will easily survive future macOS updates, VMware version bumps, ColourSpace releases, and any physical USB-C dongle swaps. Most importantly, I'm hoping this means I will never have to bother Steve for an activation reset again!

Just for full transparency, I ran these tests before activating my ColourSpace license. I wanted to make sure my VMware network configuration was set up correctly and completely stable. My main goal was simply to ensure that an honest mistake—like forgetting to pack my USB dongle in my bag—wouldn't accidentally register as a new machine. Now that I see VMware keeps the virtual adapter consistent, I feel more confident my setup is finally ready for activation!

Hopefully this is useful to someone else working through the same setup.

I have now done the Broadcom suggested edit to the .vmx file.

• Locate the .vmx file: Right-click your VM in the Finder and select Show Package Contents.
• Edit the configuration: Open the .vmx file with a text editor (like TextEdit).
• Add the fix: Add the following line to the file, preferably at the beginning:
• uuid.action = "keep"
• Save and close: Save the file and start your virtual machine.

Seems it may have stopped the VM moved/copied issue on startup...

Steve