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

[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

[Rollo62]

@mensch72
Super Tipp mit den Registrierungen.
Ich mache das eigentlich immer umgekehrt, Bottom-Up,
habe also erst ein clean Backup, dann eins mit XCode, Zertifikaten, etc.

Du hast Recht, jetzt wäre der richtige Zeitpunkt das XCode rauszulöchen und
ein Clean+Zertifikate zu halten.

Aber ist es nicht so das die Zertifikate sowieso dauernd verfallen ?
Deshalb wird ein solches Clean+Zertifikate leider auch nicht ewig halten.
Trotzdem, für die nächsten 2-3 Upates spart das gut Zeit.


@Matthias
Danke für den Tipp, das werde ich mal versuchen.
Es scheint wohl so das die VmWare Tools noch ein paar geheime Tricks draufhaben.


Früher hatte ich EIN Betriebssystem EINE IDE und Updates ca. jedes Jahr.
Den Rest der Zeit konnte ich in Aller Ruhe programmieren ...

Heute muss ich VmWare, drei+ Betriebssysteme, drei+ IDE's, zig Frameworks, etc. etc. warten, updaten und installieren.
Ich komme mir langsam vor wie ein Admin, und komme bestenfalls nur noch ein halbes Jahr zum programieren.

Emba versucht die ganze Sache schon gut abzufedern, aber es wäre nicht schlecht wenn man
für dieses Wartungs-Problem noch mehr clevere Lösungen finden könnte,
z.B. die optimale Verwaltung von VmWare, XCode, etc. durch kleine, abgestimmte Tools.
Könnte der PaServer, XCode, Zertifikatsverwaltung und AndroidStudio nicht noch besser integriert werden, damit auch die ganzen Einstellungen automatisiert und einfacher angepasst werden könnten ?
Damit die Entwickler endlich wieder zum Programmieren kommen

Rollo

[Rollo62]

@Matthias

hier das Ergebnis von dem shrinkonly:

Zitat:

sudo /Library/Application\ Support/VMware\ Tools/vmware-tools-cli disk shrinkonly
Shrink disk is disabled for this virtual machine.

Shrinking is disabled for linked clones, parents of linked clones,
pre-allocated disks, snapshots, or due to other factors.
See the User's manual for more information.

Ist kein Linked clone, parent, etc. muss ich weiter unter "other factors" suchen was das wohl wieder sein könnte.

Immerhin, da tut sich mal wieder ein neues, interessantes Feld auf

Edit:
Noch ein interessantes Feld (vm-run) ...
Ach wenn der Tag doch 25h hätte

Rollo