För stor fil för att exportera till extern H-disk

Metod 1: Det är lite krångligt det där med diskstorlek i en VM. Du kan inte ändra medans VM rullar storleken på den disk som den körs på. Men du lägga upp en ny Linux VM, kalla den VMx med bara minimalt med diskutrymme.
Den uppdaterar du som vanligt och gör erforderligt inställningsjobb mm. Därpå stänger du ner den.
I menyn på VirtualBox så markerar du din nya VMx,och letar upp Properties/Storage, där lägger du till de andra VMs diskfiler (attach storage device), heter det i de äldre VirtualBox.

När du sedan startar din lilla VMx så kan du då med alla verktygen inne i Linux, kunna omarbeta dessa diskavbildningsfiler mm. Defragga och krympa ihop dem.
Tex med GParted.
Kan bli krångligt om diskfilen är krypterad så man bör undvika kryptering för att lära sig hur man gör.

Men, men det är lätt att förvilla bort sig i detta. Så bästa rådet brukar vara att inte kludda med något som redan fungerar. Risken blir att man spiller bort en massa timmars arbetstid i onödan.
Kan inte beskriva detta exakt eftersom jag inte har Win 10/VirtualBox på just denna lilla pluttdator jag skriver detta på.

Metod 2: OBS läser också det som att compact kommandot verkar ha syntaxen
VBoxManage.exe modifymedium disk "C:\path\to\disk.vdi" --compact
Istället för vdi så får man alltså prova med vmdk.

Reddit har ett eget forum för VirtualBox, här:
https://www.reddit.com/r/virtualbox/
https://www.reddit.com/r/virtualbox/...sure_of_which/

Här finns arbetsgången för att komprimera en VM diskfil:
https://www.howtogeek.com/312883/how...up-disk-space/
Lite krångligt och mycket att lära sig. Programmet zerofree behövs köras i Linux i recoverymode och skriver alla lediga sektorer med nollor.
Det här kommandot är det som slutligen komprimerar diskfilen:
VBoxManage.exe modifymedium disk "C:\path\to\disk.vdi" --compact

Det är dock en del problem sedan när du ska starta den, därför att efter komprimering så har ju VM inget ledigt diskutrymme kvar. Så den går ju att starta, men är inte särskilt användbar då förstås. Därför brukar man efter komprimeringen lägga till typ minst 2-4 GB ledigt utrymme.
Här finns exempel på hur man gör i GUIn i VBox:
https://www.howtogeek.com/124622/how...box-or-vmware/
Nu har din VM en del ledigt utrymme, och blir därmed körbar, tills utrymmet är slut.
Tar diskutrymmet slut i Linux så kan vad fan som helst hända, i synnerhet om du kör
sudo apt-get update.
Att Linux sedan failar starten och man har en inkonsistent maskin.
Det är bland annat därför jag aldrig bryr mig om att behålla någon VM genom ett stort antal uppdateringscykler.
Utan jag bara skapar en ny.

Du bör inte avbryta ett pågående VBoxManage kommando därför att diskfilen kan då bli korrupt.
Man tar alltid backup på viktiga VMs, för säkerhets skull.
Det är lite svårt att beskriva ett så intressant och värdefullt program som VBox är.
VMWare är också mycket kraftfullt , men har de flesta inställningar i fönsterformatet.
Och har tillhörande hjälpfiler förstås.

Har inte provkört senaste VBox men det finns buggar i de tidiga versionerna, bla vid sleep/hibernate, och då tex att den inte refreshar nätverksanslutningen. När den ska väckas upp. Den noteras ibland som disconnected, och man måste ibland manuellt disconnecta det trådlösa eller trådbundna nätverket. För att få en automatisk refresh.

Kryperat är de . Slutsatsen får bli att man ska göra rätt med en gång! Funderar på att fixa en H-disk med 2 terabyte.

Bra info I alla fall! Lärde mej mycket.

Skumt ändå att ska va svårt att justera utrymmet i efterhand. Men de har väll med filsystemet eller nått att göra.

De ligger faktiskt en blå fi i H-disken för ens VM. Den verkar motsvara de verkliga storlek på ens VM (den ser ut ikonen för den andra VM:en som är 100 gigabyte). Skulle den kunna fungera självständigt om man exporterade bara den?

Det är riktigt att krympa och expandera hårddiskfilerna är lite knepigt att göra.
De som håller på med detta ständigt och jämnt kör ju bara kommandona som skript
och har färdiga batchfiler för att sätta upp dem okej.
Det räcker egentlgen om du exporterar hårddiskfilen. VDI eller VHD (*), du behöver när du sen ska använda den i VirtualBox välja new virtual machine, och använda samma inställningar som du hade förut.
Du behöver bara använda default inställningarna för en ny VM, och när du kommer till storage sektionen, så väljer du bara din kopia av hårddiskfilen.
Hårddiskfilen kan kopieras som en vanlig fil i Windows filhanterare.
Virtual Box försöker hålla reda på vilka registrerade hårddiskfiler (image filer) som finns i din Windows maskin.
Men du kan lägga till en kopia om du vill.
Du kan behöva reboota din VM ett par gånger, innan den fungerar som tänkt.

Men om du behöver spara maskintillståndet så hänger det ihop med den aktuella hårddiskfilen.
Sparar man maskintillståndet så kopieras den virtuella maskinens minnesinnehåll inkl den virtuella CPUns tillstånd i en fil, och därpå kan man starta den precis där den befann sig.
Eftersom även det virtuella nätverkskortets tillstånd sparas, så när man aktiverar maskinen igen så kan den notera nätverket som disconnected fastän den inte är det.
Vet ej om den buggen är helt rättad nu. Nätverkskortet får ingen refresh-signal alltså.
Trots att man valt NAT som alternativ.
Oftast kommer nätverket igång ändå.

Fast om den virtuella maskinen håller på med en pågående filoperation och den avslutas precis när den virtuella maskinen startas så kan det hända att tidsstämpeln då blir felaktigt satt. Dvs filen blir bakåtdaterad i tiden.

Man kan även råka ut för en del låsningar av webbläsarfönstren när man startar en VM från ett sparat maskintillstånd. Detta beror ju på att webbläsaren förlorat kontakten med HTTP servern - men det räcker ju oftast att trycka på refresh att ladda sidan på nytt.

Måste man hålla igång flera VMs som kräver mycket diskprestanda i synnerhet om de ska driva flera strömmar, streams, då går det inte så värst bra med mekaniska diskar, utan det behövs SSDs rentav i RAIDs. Har man för långsam diskprestanda så hackar de både i ljud och bild. Även om man räknat på att diskprestandan ska räcka så gör den inte det i alla fall. Att hitta var flaskhalsen sitter blir inte så lätt. Så det skiter man i och sätter in snabbare diskar och en CPU med fler kärnor och mera RAM.

De sk shared folders, delade mappar, är ett slags hybrid mellan Windows och Linux. Och i Windows ser filerna ut att vara i NTFS format, men inifrån Linux så går de i regel att öppna ändå, även om man inte aktiverat NTFS stödet i Linux.
Om du nu har en 100 GB hårddiskfil, så starta den Linuxen och kopiera de filer du villl ha till något externt utrymme. Och sedan bildar en ny VM med lagom utrymme, därpå kan man bara trasha den gamla. Det är vanligen enklare än att dekryptera den, krympa och sedan expandera den.

(*) Det finns fler virtuella diskformat, i regel tar de inte hänsyn till om de är krypterade eller inte.
Är de krypterade "inifrån" VM självt så går det ofta inte att krympa/expandera dem hur som helst.
Är de krypterade virtuella diskar så är också FATs filallokeringstabellerna också krypterade, och då kan inte expanderings/krympningsprogrammet "se in" utifrån hur de ska ändra om dem heller.

Det är som sagt var viktigt att komma ihåg att har man krympt en VM så mycket det går, så är den knappt körbar i det läget. Eftersom när man startar den så finns det noll bytes kvar i diskutrymme. Man brukar få utöka disken med 2-4 GB för att den ska ha lite "slack". Tänk på att tex Google Chrome och Mozilla Firefox äter rätt mycket i diskutrymme i cachen.

Det finns färdiga virtuella maskiner, diskavbildningsfiler att ladda hem. Så då får man en VM som redan är förkonfigurerad för en viss host-miljö, testad, uppdaterad och uppvärmd.

Dessa kan användas som testmaskiner för ny programvara, hastighetstest mm.
Allt man kan tänka sig.
Särskilt för att tex testköra drivrutiner, eller programvara som körs direkt i kernelnivån, daemons, etc.

Sådant som man absolut inte vill köra på sin ordinarie work-horse.

Dessa VMs har använts rätt mycket som tex honeypots och liknande för att logga hackerattacker mm.
Man kan nämligen lägga in att spara hela hackerförsöket
i form av inkommande nätverkspaket mm.

Krypterade system som inte bara är krypterade på filnivå utan även på partitionsnivån är inte möjligt att krympa/expandera med mindre än att du antingen gör det inifrån VM eller vet hur man dekrypterar den.

Detta på grund av att innehållet ser bara ut som random ettor och nollor och ett krymp/expander-program inte vet var filerna börjar och slutar. Och inte heller vet vilket utrymme som är markerat som "ledigt", och kan tas bort vid krympning.

Dessa nedladdningsbara VMs i form av diskavbildningar påminner alltså starkt om Windows Recovery-partition som nästan alla fabriksinstallerade märkesdatorer har på sin hårddisk.

De som är riktigt kryptiska kan ju köra engångs-VM, dvs man har en nyinstallerad VM och använder den bara under en session, varpå man skriver över den med en ny kopia. På det viset kan man byta datornamn, random användarnamn, MAC-adress mm. Dessa VMs är värdefulla tex i Onions som tex noder, och man trashar dem efter ett tag, och lägger upp nya. På så vis hittar man ingen info om vad som har hänt inuti dem heller.