[Fmx,VmWare,XCode] VmWare Image Grösse 30GB ?

[Rollo62]

Hallo zusammen,

bin gerade dabei etwas auf- und umzuräumen, und lege mir neue VmWare Images an.
Das sind jetzt meine ersten OSX Images, mit denen ich gerade herumexperimentiere und
hoffentlich genauso schön einfach arbeiten kann wie mit Windows Images.

Ein cleanes VmWare Image MacOs 10.13.2 HighSierra, mit VmWare erzeugt
(allerdinge hat es sich zwischendrin schon von 10.12 auf 10.13 upgedatet),
belegt ca. 20 GB
nach ein paar Updates und XCode 9.2 + PAServer
belegt es ca. 30 GB

Windows Images bieten fast regelmäßig in VmWare das Defragmentieren an, um die Disks wieder zu säubern.
Das MacOs Image hat dies bisher noch nicht getan.
Die OSX-Festplatte ist weder vorab belegt, noch in mehrere Dateien unterteilt.

Ist diese Dateigröße normal, oder kann man das noch optimieren ?

Rollo

[LTE5]

Ich kann deine Frage nicht beantworten, aber dein folgender Satz irritiert mich doch ein bisschen

Zitat:

Windows Images bieten fast regelmäßig in VmWare das Defragmentieren an, um die Disks wieder zu säubern.

[mensch72]

"im Prinzip" reichen zur Installation 30-40GB für OSX,ITunes,Xcode,PA-Server... aber leider nur zum ERSTEN !Clean-Install!

Wenn bei neuen Releases OSX(~4GB) + XCode(+6GB) + IphoneDebugfiles(je 1..2GB) alles auf einmal zum Download kommt braucht es über +10GB Downloadplatz und nochmal +15GB zum entpacken&installieren(zwar nur temporär, nützt aber nix wenn einmal von VM belegt dann ist es belegt)

=> meine aktuellen OSX-VMs sind jetzt auf 55..63GB konfiguriert und machen so alle AutoUpdates auch wenn gewollt auf einen Schlag
-> OSX und XCode installiere ich aber stets manuell getrennt, wenn die mal zusammen in der Updateliste stehen

=> VMwareDisk vergrößern ist im Prinzip per Expand unter VMware einfach, nur leider installiert OSX hinten immer noch eine RecoveryPartition... die muss man mit einem PartitionsTool wie "GParted(z.B. per BootISO)" zuerst weider ganz nach hinten schieben, bevor dort oder dann auch per "OSX Festplattendienstprogramm" die eigentliche OSX Partition vergrößern kann
-> Unter OSX habe ich das einmal mit dem ParagonOSX-Diskmanager gemacht, ging aber ist im letztem Sierra zu einem Rechte gefrickel geworden... ein fertiges "grafisches" GParted per LinuxBootISO läuft problemlos als temporäre BootQuelle einer OSX-VM.

[Rollo62]

@LTE5
Ich meine das unter WindowsImages quasi sofort via VmWare nach kurzer Benutzung Speicher freigegeben werden kann.
Das entspricht in etwa dem was temporär gelöscht oder im Paierkorb geleert wurde.

Ich hatte eigentlich unter OSX ein ähnliches Verhalten erwartet, das gelöschte Files auf dem OsxImage einfach wieder freigegeben werden können.

@mensch72
Ja so ähnlich kommen die Filegrößen bei mir auch hin, dann werd ich wohl damit leben müsse
Hatte gehofft das MacOS schlanker wäre.
Ich hätte aber gedacht das man wie unter Windows temporäre Dateien freimachen kann.

Ich habe jetzt noch keinen "Cleaner" unter OSX ausprobiert,
es gäbe da z.B. den CleanMyMac3 oder auch CCleaner for Mac.
Hast du Erfahrung damit, können die etwas freischaufeln auf einem nahezu leeren Mac ?

Eine Idee wäre noch einige unnütze Programme rauszuschmeissen, aber das wäre in der cleanen Version eigentlich nur Kleinkram, und lohnt wohl den Aufwand nicht.

Edit:
Hab gerade mal CCleaner gecheckt, der hat nur 13MB gelöscht.
Die tauchten beim VmWare Bereinigen wie erwartet auch nicht auf.
Also es scheint bei MacOs wohl so das man zusehen muss wie die Platte wächst.
Naja, ich will ha nur XCode und PAserver draufhalten, da hoffe ich es bleibt im Rahmen.

Rollo

[LTE5]

Zitat:

Ich meine das unter WindowsImages quasi sofort via VmWare nach kurzer Benutzung Speicher freigegeben werden kann.
Das entspricht in etwa dem was temporär gelöscht oder im Paierkorb geleert wurde.

Defragmentieren ist es dann aber nicht

[Rollo62]

Ich stecke da jetzt nicht im Detail drin,
deshalb hier mein Wunschdenken:
Bei VmWare ist das HD-Drive wohl ein Sparse-File (zuindest wenn man keine feste Größe vorbelegt hat), welches durch das Bereinigen von solchen gelöschten Clustern verkleinert wird.

Ob das jetzt Defrag heisst oder anders, mir egal, Hauptsache es hat den gleichen Effekt wie unter dem WindowsImage

Rollo

[mensch72]

Der Sinn des "defrag" kommt aus Zeiten der mechanischen Festplatten, denn da machte es Sinn, wenn alle Daten schön hintereinander auf den Scheiben lagen, damit alles in einer Drehung ohne sehr langsames bewegen&positionieren der Lese-Köpfe gelesen werden konnte.

Bei SSDs ist es völlig wurscht, denn da verteilt der interne Controler sowie so alles wie er will und was man als Partition oder als Filesystem sieht ist stets nur eine virtuelle Ansicht.

Weil in einer Standard-OSX Installation die RecoveryPartition hinter der SystemPartition liegt, belegten die 2 Partitionen zusammen virtuell per Default immer die volle Platte... VMware ist bei dynamischem SingleFile intelligent und erkennt wieviel OSX-Systemspeicher benötigt wird, und kann so automatisch vergrößern, aber leider nicht verkleinern, weil sowas wie "sdelete -z(ero)" unter für OSX da fehlt.

Sinnvolles Verfahren:
- man vergrößere per VMware das VMDK um etwas mehr als die Größe der RecoveryPartition
- man verschiebe mit "gparted" die RecoveryPartition ans Ende
- man verschiebe mit "gparted" die SystemPartition nach hinten wieder direkt vor die RecoveryPartition
- man verschiebe mit "gparted" die RecoveryPartition nach vorne an den Anfang des nun dort ja freien Platzes
- man verschiebe mit "gparted" die SystemPartition wieder etwas nach vorn, also nun direkt hinter die RecoveryPartition
- man vergrößere mit "gparted" die SystemPartition nach hinten bis ans Ende zur sinnvollen Nutzung des ganz am Anfang zugefügten Speichers
- man kontrolliere im OSX "Festplattendienstprogramm" ob alles passt

=> ab nun kann man unter OSX je nach Füllstand der SystemPartition diese auch direkt unter OSX verkleinern und dann wird unter VMware bei "VMDK-Compact" das VMDK auch wirklich kleiner
-> man sollte sowas nur mit 100% Vollbackup der VMs bzw. eines RealMAC machen, denn Stromausfall bei einem der Punkte wäre keine gute Idee

[Rollo62]

Dankesehr für die Tipps, ich Teste gerade noch OSX-VM mit Rx1022 weiter aus.

Wie sich das OSX-VM verhält schaue ich mir erstmal eine Weile an, die 30GB sind ja offensichtlich ganz normal und OK.
Ich hoffe mal es bleibt so ungefähr dabei.

Im Moment bin ich froh das OSX-VM überhaupt so gut läuft, und tatsächlich auch ein iPhone debuggen kann
Sogar der Simulator zuckt schon wieder (stürzt aber noch ab, liegt womöglich an der App).

Wenn es denn mit der Filegrösse ausufern sollte dann schaue ich mir gerne dein Verfahren nochmal an.
Aber vielleicht wäre es auch weniger aufwändig einfach ein neues, cleanes OSX-VM zu Erzeugen.

Wie gesagt, wenn nur XCode und PAServer drin sind ist das ja wenig Aufwand.
Das größere Problem sind da schon eher das Anlegen der Zertifikate die man auch womöglich immer neu anlegen und draufspielen muss.

Rollo

[mensch72]

..."Aber vielleicht wäre es auch weniger aufwändig einfach ein neues, cleanes OSX-VM zu Erzeugen"...

Tip:
- wenn du jetzt ein "CleanOSX mit XCode und funktionierenden DeveloperAccount hast, dann kopiere diese VM komplett (also kein SnapShot oder so)
- jetzt lösche XCode indem du unter Programme den Ordner in den Papierkorb ziehst und anschließend den Papierkorb löschst
- jetzt noch den PA ServerServerManager in gleicher Methode löschen, den aktuellen(zukünftig alten) "PA Server" selbst also drin behalten!
- das dauert jetzt noch etwas bis das Filesystem auch wirklich den Platz frei gibt... also mach 10min Kaffeepause und dann 1x OSX Restart
- nun den freien Platz kurz checken und VM herunter fahren
- VM logs&caches löschen
- OSX VM per Winrar oder 7Zip "maximal" packen... und das ist nun fürs Archiv die "CleanVM incl aller Zertifikate", denn sofort nach Redownload XCode klappt damit sofort wieder alles
- die VM selbst kannste jetzt so löschen, dafür lieber 2x oder Rar/7zip aufbewahren


Nachtrag:
- ich gehe selbstverständlich davon aus, du verwendest VMwareFusion für deine OSX-VMs... da kann man theoretisch immer die neueste VM-HW-Variante beim neuanlegen von VMs nutzen
- solltest du aber VMs WorstCase mal auf älteren MACs als Host oder gar ganz böse auf "angepasster" VMwareWorkStation/ESXi nutzen wollen/müssen... dann empfehle ich lieber eine 2 Versionen alte HW-Basis für die VMs. Speziell unter Windows klappt das durchgereichte IOS-USB-Debug am sichersten wenn man real das IOS Gerät an einem USB3 Anschluss dran hat, die VM aber nur USB2 "virtualisiert"
- OSX-VMs mögen keine "frei" übertrakteten Intel-K-Typen... also I5 & I7 immer mit Standardmultiplikator laufen lassen, sonst verschlucken sich manche HW-Treiber unter OSX (wer hat und kann nehme XEONs und spiele dort mit dem Bustakt und der einen zusätzlichen TurboStufe... das beherrscht OSx wegen der MacPro schon seit Jahren)
- OSX-VMs mögen keine variabel "heruntergetakteten" Intel-U-Typen... also solche I5 & I7 NotebookCPUs unter Windows immer mindestens auf ausgewogen, wenn nicht gar auf Höchstleistung schalten(wenn man ganz böse OSX VMs mit WindowsNotebook nutzt)
- daher: man nutze OSx VMs nur mit VMwareFusion auf org. MAC Hardware

[MEissing]

innerhalb der macOS VM bei installierten VMWare Tools
sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrinkonly