Jump to content
XPEnology Community

Installaton von DSM 6.2.1 auf HP MicroServer Gen8 mit ESXi 6.x


haydibe

Recommended Posts

In diesem Post wird Zusatzinformation zu Folgendem englischsparachigen Post gegeben:

 

luchuma created a topic in Tutorials and Guides

Die CPU vom HP MicroServer Gen8 is so so alt, dass damit eine DS 918+ nicht betrieben werden kann.

 

Von den angegeben Downloads sind 1) und 2) umbedingt notwendig. Je nachdem, ob ihr die Pat-Datei erst herunterladen und dann installieren wollte oder der Installer das selber machen soll, könnt Ihr Download 3) durchführen oder überspringen. 4) ist erst Relevant wenn die DS fertig installiert ist. 5) Ist das Schweizer-Taschenmesser der Tools die für XPE verwendet werden (können).

 

Ich habe bei der Installation nur zwei Werkzeuge verwendet um erfolgreich DS3615sx 6.1.7 auf DS3615sx 6.2.1 zu aktuallieren:

 - OSFMount: zum Anpassen der grub.cfg  in der .img-Datei

 - WinSCP: zum hochladen der vmdk und .img-Datei auf den ESXi Datastore.

 

Im Abschnitt "Preparation" habe ich folgendes gemacht:

- entpacken von 1) ;  in dem Zip sind wir nur an der vmdk-Datei interessiert. Sie hilft uns die modifizierte 1.03b synoboot.img-Datei in ESXi direkt einzubinden.

- entpacken von 2)

- Starten von OSFMount und mounten der Datei synoboot.img aus 2), dort wie angezeigt Partition 0 mounten und die grub.cfg anpassen. Anders als es auf den Screenshots zu sehen ist, habe ich NUR die Seriennummer und die MAC1 angepasst (dieses sollte zur MAC der späteren Netzwerkkarte passen), da alles andere bei mir zu Probleme geführt hat. Danach in OSFMount den Mount wieder unmounten - wenn hier ein Popup kommt, dann verhindert irgendetwas das unmounten... wenn man "forced" unmountet kann es sein, dass die Änderungen an der grub.cfg weg sind.

 

Nicht abgebildete Aktionen:

- kopieren der bearbeiteten synoboot-img-Datei in das Verzeichnis 1).

- Hochladen der img- und vmdk-Datei in den Datastore mit WinSCP.

 

Der ESXi Part its als Schablone für die VM-Einstellungen zu verstehen.

Dabei ist folgendes zu beachten:

- das neue Synoboot-Laufwerk muss als SATA 0:0 gemoutet werden - wenn die grub.cfg nicht beschädigt wird, dann ist dieses Laufwerk unsichtbar für DSM.

- Um Datendisks zu verwenden, muss ein neuer virtueller SATA-Controller angelegt werden, alle Datenfestplatten MÜSSEN dann SATA 1:x verwenden um im DSM sichtbar zu sein.

- Alternativ kann ein supporteter Hardware-Controller mittels Passthrough in die VM gehangen werden.

- Die Netzwerkkarte muss auf Intel 1000e gestellt sein, ihre MAC-Adresse sollte identisch sein, mit der in der grub.cfg.

 

Darüber hinaus habe ich folgende Erfahrung gemacht:

- Eine NeuInstallation ist unproblematischer als eine Migration, da Fehler in der grub.cfg sich hier leichter identifzieren lassen.

- Vor einer Migration lohnt es sich die Konfiguration aus DSM zu exportieren.

- Fehler in der grub.cfg sorgen dafür das SATA0:0 nicht unsichtbar ist für DSM und verhindern die Installation (Es wird gefragt ob n +1 Festplatten formatiert werden soll) .

- Es kann sein, dass die Systempartition auf bestehenden Systemen zu Problemen führt, die eine Migration verhindern!

 

Letzteres war bei meiner ersten Migration mit meinem "nur Docker System" der Fall. Ich musste die VM ausschalten, die Platte mit Altdaten von SATA1:0 wieder entfernen, eine frische vmdk an SATA1:0 erzeugen und dann DMS normal installieren. Nach der Installation habe ich das System dann heruntergefahren und dann die Platte mit den Altdaten als SATA1:1 eingehangen und die VM wieder gestartet. Nach dem Einloggen in die DSM-UI wurde angzeigt das eine defekte Systempartition vorliegen würde - diese habe ich reparieren lassen... Die Shares und Daten waren alle wieder da. Nun habe ich die VM wieder heruntergefahren. um die temporäre SATA1:0 zu löschen und die Platte mit den Altdaten auf SATA1:0 zu ändern. Nach einem weiteren Neustart habe ich dann das Docker-Paket installiert, wobei die Container SOFORT wieder in Betrieb genommen wurden, ohne das ich irgendetas tun musste (standen alle auf Autostart). Zusätzlich habe ich noch Webstation und die VMWare Tools  installiert, Letsencrypt und meine Aufgaben wieder angelegt und die Migration war abgeschlossen. Lession learned: hätte ich die Einstellungen mal vorher exportiert (cry).

 

Ich hoffe das hilft auch anderen das Update durchzuführen.

 

Ich habe keine Ahnung bei XPE mit VMWare mit nicht Xeon-Systemen, daher werde ich keine Fragen beantworten können zu Themen wie "funktioniert das auch mit Mainboard x oder CPU z"?

 

Edited by haydibe
Link to comment
Share on other sites

  • 2 weeks later...

Ich habe gerade erfolgreich auf meinen beiden HP MS Gen8 Kisten meine Haupt-VM's von 6.1.7 auf 6.2.1 migriert.

In beiden VM's ist jeweils ein LSI9211-Controller mit LSI2008-Chip per Passthrough in die VM reingereicht, sowie eine extra 100GB vmdk als Datendisk.

 

Der Ablauf war sogar unprobematischer, als bei meinem "nur Docker System".

Hier musste ich eigentlich nur das oben beschreibene anwenden:

- Synoboot anpassen mit Serial und MAC, hochladen in den Datastore

- VM-Bearbeiten:

-- Extra SATA Controller hinzufügen

-- bestehende 100GB Datenplatte von SCSI0:0 auf SATA1:0 ändern

--  bestehende Boot-Platte (vorher SATA0:0) rausschmeissen

-- hochgeladene synoboot-Datei ein SATA0:0 einbinden

-- Altlasten bereinigen:

--- SCSI-Adapter rausschmeissen

---  Seriellen Port aus DSM6-Zeiten auch rausschmeissen

 

Dann in den "VM-Optionen" unter Startoptionen die Firmware auf BIOS stellen und beim nächsten Start die Bios-Anzeige erzwingen.

Im Bios dann die Bootreihenfolge so anpassen, dass das synoboot geladen wird (bei mir jeweils die Angabe, die nicht 2:0:0:0 war)

 

Im Synology-Assistent war der DSM-Intaller dann direkt zu finden. Dort konnte die Migration ausgewählt werden und war ohne probleme abgeschlossen.

Nach dem nächsten Neustart war DSM wieder mit den richtigne Einstellungen wieder erreichbar. Top!

 

Lediglich einige Docker-Container konnte nicht gestartet werden. Hier ist irgendetwas mit dem "Image zu Container"-binding im Eimer gewesen.

In der Docker UI kann man das aber Problemlos wieder reparieren, in dem man das Kotextmenü bei dem "Schalter" öffnet und dort "Aktion"->"Inhalt löschen".

Damit wird ein neuer Container mit exakt den vorherigen Einstellungen verwendet.

 

 

 

 

 

Edited by haydibe
Link to comment
Share on other sites

... wenn ich dann am Ende nicht festgestellt hätte, dass die Platten am LSI-Controller in beiden VMS nicht erkannt werden! Arghhh.

 

Ein Neustart mit dem dritten Menüpunkt (ESXi) hat zum Erfolg geführt. Die Platten werden nun angezeigt. Yay :)

 

Synoboot wird nun als nicht initalisiertes Laufwerk gezeigt. Das war wohl bei dem ersten Installationversuch der Grund, warum die Installation nicht geklappt hat.

Meine 100GB vmdk wird als eSATA erkannt?! Das Volume ist nicht zu sehen.

 

Je nachdem welchen Booteintrag ich wähle bekomme ich entweder den Controller mit seinen 4 Platten nicht angezeigt oder die 100GB vmdk wird als eSATA erkannt.

Weiß hier jmd was hier zu tun ist?!

 

Ich verstehe das es ein Problem mit den Ports gibt. Soweit ist es klar. Nur wie es genau konfiguriert werden muss verstehe ich ehrlich gesagt nicht.

Ich habe einfach das gemacht was in folgendem Post steht und es funktioniert wieder alles:

 

 

Kann jmd erklären WAS genau konfiguriert werden muss?

Ich habe SATA0 und SATA1 als Vmware SATA Controller mit jeweils eine vmdk, sowie den LSI-Controller mit 8 Anschlüssen.

 

Edited by haydibe
Link to comment
Share on other sites

2 hours ago, haydibe said:

Lediglich einige Docker-Container konnte nicht gestartet werden. Hier ist irgendetwas mit dem "Image zu Container"-binding im Eimer gewesen.

In der Docker UI kann man das aber Problemlos wieder reparieren, in dem man das Kotextmenü bei dem "Schalter" öffnet und dort "Aktion"->"Inhalt löschen".

Damit wird ein neuer Container mit exakt den vorherigen Einstellungen verwendet.

 

So einfach war es dann doch nicht. Die gemappten Volumes waren bei den Containern die repariert werden mussten weg. Da hat nur löschen und vorher gespeicherte Konfiguration wieder re-imporen geholfen.

Link to comment
Share on other sites

Wie muss Der Wert für SataPortMap bei dem System aussehen?

root@dsm:~# lspci -Q | grep -E '(AHCI|LSI)'
0000:02:00.0 SATA controller: VMware SATA AHCI controller
0000:02:03.0 SATA controller: VMware SATA AHCI controller
0000:03:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 02)

Die Controller sind folgend belegt:

0000:02:00.0 -> 1x vmdk

0000:02:03.0 -> 1x synoboot.img

0000:03:00.0 -> 4x SATA Platten

 

In der zweiten VM sieht es ganz genau so aus, nur dass dort statt 0000:02:03.0 der Controller unter 0000:02:05.0 läuft.

 

Damit müsste der Wert doch mindestens "SataPortMap=114" sein, da die beiden VMware SATA AHCI Controller zuerst kommen und so jeweils eine Platte ausreichend wäre. Der LSI-Controller wiederum könnte zwar 8 Platten anbinden, davon kann ich aber nur 4 belegen.

 

Verstehe ich es richtig, dass der dort gesetzte Wert NUR bei der ersten Migration greift und nicht mehr, wenn man das synoboot.img im Nachgang ändert, so dass dann die Werte manuell in /etc/synoinfo.cfg bzw. /etc.defaults/synoinfo.cfg gesetzt werden müssen? SataPortMap kann jeder Zeit geändert werden und greift nach dem Neustart sofort; wobei je nach Änderung ggf. eine "kurze" Migration gemacht werden muss. Allerdings sorgt die Einstellung 114 nicht dafür, dass meine 100gb vmdk nicht trotzdem als 13tes Laufwerk erkannt wird. Interessanterweise entspricht das dem Laufwerk, dass eingetlich die synoboot durch DiskIdxMap=0C erhalten sollte. Ich habe jetzt die Standardwerte in synoinfo.cfg gelassen und einfach DiskIdxMap von 0C auf 09 geändert - unschön, aber funktioniert.

 

Wer trotzdem an der Synoinfo.cfg rumbasteln will findet hier eine recht gute Beschreibung WIE die Werte entstehen:

 

 

Edited by haydibe
Link to comment
Share on other sites

Die SataPortMap habe ich auf 444 geändert, weil das Bootdevice sonst an zweite Stelle ist. Scheinbar ist die Angabe der Controller von hinten nach vorne, so dass 411 wohl eher richtig gewesen wäre... aber ich lebe lieber mit Lücken in den Laufwerken als noch ewig rumzuprobieren.

 

set sata_args='sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=09 SataPortMap=444 SasIdxMap=0

 

Jetzt ist nur noch die Frage, welche Werte bei sata_uid, sata_pcislot und synoboot_satadom angegeben werden müssen, damit mittels DiskIdxMap das synoboot Laufwerk angesprochen wird.

 

Link to comment
Share on other sites

If it helps at least a single person, it is wort sharing it :)

 

Jetzt habe ich auch mal die Übertragungsraten gemessen:

mit einem  Cat6-Kabel bekomme ich zwischen meinen Win10 Notebook und jeder der beiden haupt VMs lesen und schreiben so um die 115mb/s.

Wenn last auf dem Disk-Array ist, bricht es schon gerne bis auf 80mb/s ein.

 

Edited by haydibe
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...