Det som kan påverka upplevensen av snabbhet och respons är tex. grafiken inte går direkt mot hårdvara utan är mer som en 'remote desktop' via en kommunikationslänk till en visningsfönster på samma sätt som MS remote desktop, även när det körs inom samma fysiska dator.
Skall man ha direkt HW-stöd till en GPU-grafikkort i klient-OS så är det genast mer meck och då helst ha två grafikkort den, ena för att sköta OS och VM etc. och den andre kopplade mot VM-maskinen att använda.
Sedan får man tänka på att virtualbox är en level-2 emulator där delar emuleras på mjukvara medans tex. KVM/QEMU som körs under linux är en level-1 emulator och i princip kör allt på kislet i processorn
Sedan är det som alltid - för lite RAM-minne påverkar prestanda och använda lagring och hur de emuleras kan också påverka.
De är oftast ingen större problem att konvertera en VM-image för en VM-miljö till en annan VM-miljö och dess format med respektive miljös import och export-verktyg om man vill prova runt mellan olika VM-miljöer. - jag har dragit av hela hårddiskar i RAW-form och gjort en QCOW2 VM-image direkt av den och sedan kört innehållet på samma sätt som den fysiska datorn - dock märker tex windows att den kör på en annan 'moderkort' (emulerad) och äldre licenser blir inte giltiga längre
Jag använder helst KVM i linux även om vi kört mycket virtualbox - och det är av en anledning - att när klientOS raderar filer inom sin VM-image och skickar TRIM på det som i windows - så slår det genom till VM-imagen och gör 'punch holes' i VM-imagen och tar upp mindre med diskyta i värddatorn i form av att det bildas sparse-block på den delen av VM-imagen som tidigare hade data på sig men inte längre används.
Och dessa 'punch-holes' kan gå hela vägen - genom krypteringslager till att det skickas discard/TRIM-kommdon till motsvarande position i lagringen på värd-datorns lagring. På det sättet kan man skapa VM-image som inte lider av ballooning över tiden och håller hälsan på den underliggande flashbaserade lagringen över mycket låga tider utan det måste tas ned.
Sparsefiler är något som hanteras skitdåligt om man kör VM-maskiner som virtual box på Windowsmiljö - så försök inte även om virtual box med lite hack också kan banta sin VM med sparse-block när klientOS raderar filer precis som med KVM i linux..
Jag gissar att det är NTFS fragmentationsbegränsning på VM-imagen-filen som sätter stopp då problemen och krascherna kommer först efter en tid och VM-filen blir trasig.
Annars är 'ballooning' av VM-image ett vanligt problem med VM-instanser och man får då och då stänga av dem och köra en 'inflate' på dem med VM-miljöns olika verktyg för att de inte med tiden kapar hela värddatorns diskutrymme. De flesta 'tools' är så pass smarta att man inte behöver extra diskutrymme för den nya kopian när man skall göra deflate på en förvuxen VM-image, men samtidigt om det skiter sig pga. av någon orsak under processen så är det stor sannolikhet att man förlorar diskimagen.
