Launchern för vmware kanske måste vara på C: men diskimagen som den sedan kör på för din diskavbild behöver troligen inte vara på just C: - själv kör jag KVM/QME under Virtual Machine Manager i Linux som är en level 1 hypervisor och Virtualbox under windows (och är en level 2 hypervisor) när jag måste och i KVM-fallet ligger imagen på externa eSSD med komprimerande filsystem (BTRFS) med TRIM fungerande och att TRIM från klienten som körs slår igenom hela vägen till externa lagringens eSSD och dessutom på en krypterande partition, som förvisso kommer få nollställda 'hål' för alla sektorer som det har gjorts Trim/unmap/discard på - gjorde det mest för att prova detta.
VM-filen för KVM är av sparse-typ och med TRIM fungerande så behöver diskimagefilerna med windows i inte vara så stora och också krymper i storlek i upptagen diskyta när filer raderas inne i klientmaskinen om denna sänder TRIM/Unmap när filer raderas som i windowsklient eller man kör fstrim om det är en linuxklient.
De flesta andra VM-miljöer så har diskimage en tendens att bara växa och växa med tiden men inte krymper igen även när filer tas bort i klientmaskinen - och för att 'pressa luften' ur denna så får man först stänga ned maskinen och sedan köra manuellt kommando ofta under powershell för att gör VM-filen mindre igen och sedan startar VM-maskinen igen - det är rätt irriterande när klientimagen med tiden brer ut sig av olika skrivande fast det är långt ifrån fullskriven filsystem och käkar upp diskutrymme för värdmaskinen för saker som är igång 24/7. När man har en VM-miljö som stöder 'sparse' och kan skapa 'holes' på filerna och VM-diskimage krymper när filer raderas så vågar man formatera lite större partitioner än annars och har utrymme för framtida tillväxt utan att pilla med att förstora både VM-imagen och i denna partitionen och filsystemet - vilket ofta görs med CLI-commandon för VM-miljön i fråga.
Det är lite pill med de olika VM-miljöerna och en stående problem är windows och att få den att hantera skärmar större än 1024x768 som största skärmstorlek om man inte kör server-version och högre då att få större så vill den se en fysisk skärm inkopplad och för att lösa det så måste man installera 'drivrutiner' från en CD som emulerar en fysisk skärm med de högre storlekarna och det fungerar olika bra i olika VM-miljöer.
Jag tycker mig nog märka att en virtualbox-installation där man också fått in drivrutinerna för skärmupplösningarna korrekt och man sedan konverterar den till qcow2 för att köra i KVM fungerar bättre än att använda KVM/QME egna drivrutiner på 'CD' för windowsupplösningarna.
Idag finns det konverteringsverktyg av VM-images för i stort sett alla VM-maskin miljöer, så det går att prova runt med samma diskimage på en rad olika VM-miljöer och se hur man trivs med dem.
---
Slutligen - du vill inte ha en VM-diskimage på en långsam USB-sticka - du vill ha det på en snabbare eSSD av någon slag - men även eSSD är inte alls lika snabb som en inbyggd SSD eller NVMe-disk och flaskhalsen är inte om disken klara 250, 500 eller 1000 MB/s utan flaskhalsen ligger i USB3-protokollet och USB-stackens transaktionsmaskin där det är väldigt svårt att komma under 1 ms per påbörjad transaktion mot lagringen medans direktaccess via SATA och NVMe är på 10 och 100-delar av en sekund och ännu lägre, så är det mycket randomize 4K-sektorläsning och skrivning så kommer det att märkas mycket när man pratar över USB3 mot en eSSD gentemot en intern SSD/NVMe-lagring för sin diskimage, lite mindre om värd-OS har stora RAM-ytor som kan cacha mycket av den heta data mot lagringen.
