VMware-Forum

Hallo,

unsere IBM Flex System Teststellung ist angekommen. Die einzelnen Compute Nodes (früher Blades) kommen mit 2 internen USB Sticks, die im Auslieferungszustand mit dem angepassten IBM ESXi 5.0 Image ausgeliefert werden.

Im UEFI sieht das dann so aus:

http://s1.directupload.net/file/d/3141/6cdwqsah_png.htm

Unser Lieferant meinte, er hatte am Anfange Probleme mit einem PSOD (wahrscheinlich das Problem mit mehreren parallelen ESXi Installation: http://kb.vmware.com/kb/1035107), nach dem Update auf 5.1 trat es aber nicht mehr auf.

In dem KB Artikel werden nur die Versionen bis 5.0 erwähnt, bedeutet dies, dass es mit 5.1 kein Problem mehr ist? Aktuell mit 5.1 bootet der Server jedenfalls ohne PSOD.

Ich installiere die ESXi Server über ein Kickstart Skript. Mit den bisher verwendeten HP Rackservern habe ich im Skript immer folgendes verwendet um sicherzustellen das ESXi auf dem lokalen RAID installiert wird.

clearpart --firstdisk=hpsa --overwritevmfs
install --firstdisk=hpsa --overwritevmfs

Wie kann ich nun bei der Installation sicherstellen, dass die Installation immer auf dem ersten Stick erfolgt?

Ich habe versucht das device direkt mit z.B. drives=mpx.vmhba32:C0:T0:L0 anzugeben, das hat aber nicht geklappt. Wobei vmhba auch nicht immer die gleiche Nummer zu haben scheint.

Mit...

clearpart --firstdisk=usb-storage --overwritevmfs
install --firstdisk=usb-storage --overwritevmfs

..habe ich die Installation nun durchführen können, nur wurde dabei der ESXi auf dem 2. Stick installiert.

Wenn ich mir die devices anschaue, sehe ich nur einen USB Stick mit 2 GB. Sollten dort nicht auch 2 angezeigt werden?

~ # esxcli storage core adapter list
HBA Name Driver Link State UID Description
-------- ----------- ---------- ------------------------------------ -------------------------------------------------------------------------
vmhba0 mpt2sas link-n/a sas.5005076056409dd4 (0:6:0.0) LSI Logic / Symbios Logic LSI2004
vmhba1 qla2xxx link-up fc.20000024ff418186:21000024ff418186 (0:27:0.0) QLogic Corp ISP2532-based 8Gb Fibre Channel to PCI Express HBA
vmhba2 qla2xxx link-up fc.20000024ff418187:21000024ff418187 (0:27:0.1) QLogic Corp ISP2532-based 8Gb Fibre Channel to PCI Express HBA
vmhba32 usb-storage link-n/a usb.vmhba32 () USB
vmhba34 usb-storage link-n/a usb.vmhba34 () USB


~ # esxcli storage core device list
mpx.vmhba32:C0:T0:L0
Display Name: Local USB Direct-Access (mpx.vmhba32:C0:T0:L0)
Has Settable Display Name: false
Size: 1911
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/mpx.vmhba32:C0:T0:L0
Vendor: SMART
Model: USB-IBM
Revision: 0000
SCSI Level: 2
Is Pseudo: false
Status: on
Is RDM Capable: false
Is Local: true
Is Removable: true
Is SSD: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: unknown
Attached Filters:
VAAI Status: unsupported
Other UIDs: vml.0000000000766d68626133323a303a30
Is Local SAS Device: false
Is Boot USB Device: true

mpx.vmhba34:C0:T0:L0
Display Name: Local USB CD-ROM (mpx.vmhba34:C0:T0:L0)
Has Settable Display Name: false
Size: 0
Device Type: CD-ROM
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/cdrom/mpx.vmhba34:C0:T0:L0
Vendor: IMM
Model: Virtual CD
Revision: 0325
SCSI Level: 2
Is Pseudo: false
Status: on
Is RDM Capable: false
Is Local: true
Is Removable: true
Is SSD: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: unknown
Attached Filters:
VAAI Status: unsupported
Other UIDs: vml.0005000000766d68626133343a303a30
Is Local SAS Device: false
Is Boot USB Device: false


~ # esxcli storage core path list
usb.vmhba32-usb.0:0-mpx.vmhba32:C0:T0:L0
UID: usb.vmhba32-usb.0:0-mpx.vmhba32:C0:T0:L0
Runtime Name: vmhba32:C0:T0:L0
Device: mpx.vmhba32:C0:T0:L0
Device Display Name: Local USB Direct-Access (mpx.vmhba32:C0:T0:L0)
Adapter: vmhba32
Channel: 0
Target: 0
LUN: 0
Plugin: NMP
State: active
Transport: usb
Adapter Identifier: usb.vmhba32
Target Identifier: usb.0:0
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 122880

usb.vmhba34-usb.0:0-mpx.vmhba34:C0:T0:L0
UID: usb.vmhba34-usb.0:0-mpx.vmhba34:C0:T0:L0
Runtime Name: vmhba34:C0:T0:L0
Device: mpx.vmhba34:C0:T0:L0
Device Display Name: Local USB CD-ROM (mpx.vmhba34:C0:T0:L0)
Adapter: vmhba34
Channel: 0
Target: 0
LUN: 0
Plugin: NMP
State: active
Transport: usb
Adapter Identifier: usb.vmhba34
Target Identifier: usb.0:0
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 122880

Hm, ich bin jetzt etwas verwundert von der Ausssage "The kit offers two USB ports however only one VMware ESXi memory key can be installed" im IBM Redbook. IBM und der Lieferant haben uns das so verkauft, dass man beide Sticks gleichzeitig verwenden kann. Z.B. um nach einem Upgrade noch die alte Version booten zu können.

http://www.redbooks.ibm.com/abstracts/tips0860.html

Vielleicht hilft dir die Tabelle darunter ja weiter:
Ausgehend davon, wurde der Stick bereits mit einer an die IBM-HW angepaßten ESXi-Version bespielt und der zweite Stick dient allein für "IBM Blank USB Memory Key for VMware ESXi Downloads". Der Stick an Port 0 wird dir wahrscheinlich deshalb immer als normaler USB-Stick und der an Port 1 als lokales USB CD-ROM mit dem ESXi angezeigt. Der Beitext sagt ja auch aus, daß du ohne weitere lokal angeschlossene Laufwerke auskommst. Keine Ahnung wie groß beide Sticks sind, aber zum Upgraden des ESXi wirst du ja auch noch etwas Platz auf einem oder beiden Sticks brauchen. Wenn du den Stick also per Kickstart-Script überschreibst, verlierst du sicherlich auch einige bereits vorgenommene Anpassungen.

Dayworker hat geschrieben:Vielleicht hilft dir die Tabelle darunter ja weiter:

Code: Alles auswählen

Table 18. Virtualization options
Part number   Feature code   Description                                          Maximum supported
49Y8119         A3A3         x240 USB Enablement Kit                              1
41Y8298         A2G0         IBM Blank USB Memory Key for VMware ESXi Downloads   1
41Y8300         A2VC         IBM USB Memory Key for VMware ESXi 5.0               1
41Y8307         A383         IBM USB Memory Key for VMware ESXi 5.0 Update1       1

Ausgehend davon, wurde der Stick bereits mit einer an die IBM-HW angepaßten ESXi-Version bespielt und der zweite Stick dient allein für "IBM Blank USB Memory Key for VMware ESXi Downloads". Der Stick an Port 0 wird dir wahrscheinlich deshalb immer als normaler USB-Stick und der an Port 1 als lokales USB CD-ROM mit dem ESXi angezeigt. Der Beitext sagt ja auch aus, daß du ohne weitere lokal angeschlossene Laufwerke auskommst. Keine Ahnung wie groß beide Sticks sind, aber zum Upgraden des ESXi wirst du ja auch noch etwas Platz auf einem oder beiden Sticks brauchen. Wenn du den Stick also per Kickstart-Script überschreibst, verlierst du sicherlich auch einige bereits vorgenommene Anpassungen.

So ganz klar ist mir noch nicht für was ich dann einen zweiten Stick benötige. Die Sticks kommen mit dem angepassten IBM Image. Das kann man aber auch direkt bei IBM herunterladen und für die Kickstart Installation verwenden. So habe ich das mit den HP Servern auch immer gemacht. Von daher solle es keinen Unterschied machen, ob ich die Konfiguration nachträglich an dem Stick im Auslieferungszustand vornehme, oder mit dem Image + Kickstart eine neue Installation auf den Stick schreibe.

Der Stick ist 2 GB groß wenn ich es richtig gesehen habe. Und mehr als den Platz auf einem Stick benötige ich ja bei einem Upgrade auch nicht. Ich denke die meisten Leute werden sowieso nur einen Stick/SD-Karte für sowas verwenden.

Selbt wenn er 2 ESXi Sticks akzeptieren wuerde kann ich mir nicht vorstellen was man Sinnvollerweise damit denn tun sollte. Auch wir haben damals, als es im Winter noch Schneite, immer ein Windows Hilfs mitinstalliert. Der Gedanke war das wenn mit dem FS oder der Windows Registry war ist man noch dran kommt an die Daten bzw. was Retten kann. Mal davon abgesehen das es nicht oft benoetigt wurde ganz klar das Problem das diese Installation nie mitgepflegt wurde, Passwoerter veralteten und mit der Verpflechtung von Windows AD, DNS usw. das Konzept unter Umstaenden mehr Schaden angerichtet hat als es nutzte.

Du haettest in kuerzester Zeit eine inkonsitenz was die Konfiguration angeht. Wenn es eh kein 1:1 Image vom ersten Stick ist dann waeren sogar die SSH Keys und Zerts ja unterschiedlich was bedeutet das ohne manuellen Zutun der 2. Stick niemals den Hosts automatisch wieder ins vCenter bringt. Diese wuerde auch evtl. VMs welche registriert sind nicht kennen.

Ich kann auch keinen Vorteil sehen 2 ESXi Installation auf dem Host zuhaben. Du willst
- Redundante SD Karte oder halt Single Stick/Karte
- Evtl. doch lieber gleich Boot from SAN
- Hostprofiles mal angucken und zusehen das diese immer aktuell sind. Weil dann ist ein Host flux wieder hergestellt
- In grossen Umgebungen dich mit AutoDeploy beschaeftigen. VMware hat hier nachgebessert so das man waehlen kann das auch eine lokale OS Installation mitgegaetigt wird welche man im Notfall nutzen kann falls das AutoDeploy versagt bzw. die ganze Umgebung nicht zur Verfuegung steht

Gruss
Joerg

Da sich an der Konfiguration bei uns nach der initialen Installation eigentlich nichts mehr ändert, wären beide Sticks erst mal mit der gleichen Version und identischer Konfig installiert worden. Im Falle eines Defekts eines Sticks, wäre dann der zweite gebootet worden, host profile check und gut ist.

Im Falle eines Version Upgrades wäre einer der Sticks als fall back mit der alten Version verblieben und hätte bei größeren Probleme gebootet werden können.

Das dies alles nicht unbedingt notwendig ist, sehe ich ähnlich. So wurde es uns aber "verkauft".

Die sinnigste Lösung ist nun wahrscheinlich nur einen Stick pro Server zu nutzen. Einen mit ESXi Installtion und einen "blanken" zu verwenden ist aus meiner Sicht auch nicht sinnvoll.

Jedes An und Ausschalten einer VM ist eine Konfigurationsaenderung. Der ESXi weis welche VMs er gerade ausfuehrt. Wenn du nun von einem 2 Stick bootest, der zwar von mir aus die gleiche Host Konfiguration hat weil er mal geklont wurde, dann sind die VM aber nicht mehr "da".

Gruss
Joerg

irix hat geschrieben:Jedes An und Ausschalten einer VM ist eine Konfigurationsaenderung. Der ESXi weis welche VMs er gerade ausfuehrt. Wenn du nun von einem 2 Stick bootest, der zwar von mir aus die gleiche Host Konfiguration hat weil er mal geklont wurde, dann sind die VM aber nicht mehr "da".

Fehlerfall Stick defekt:
In dem Fall muss ich wie immer schauen, dass die VMs vor einem Reboot und Umstieg auf den zweiten Srick auf einen anderen Host migriert werden. Wenn das Migrieren schon nicht mehr möglich sein sollte, ist es wie immer ein HA Fall und die VMs müssen hart auf einem anderen Host neu gestartet werden.

Upgrade:
Auch in dem Fall müssen die VMs vorher auf einen anderen Host migriert werden.

Ich sehe da kein großes Problem (ob's sinnvoll ist 2 Sticks zu verwenden sei immer noch dahingestellt).

Nachfragen bei IBM haben ergeben, dass eigentlich nur ein ESXi Stick gleichzeitig unterstützt wird. Und so wird das künftig auch betrieben werden. Auf einen blanken zweiten Stick verzichte ich, sehe da keinen großen Nutzen drin. I.d.R. werden die Hosts auch neu installiert und kein Upgrade durchgeführt.

Also bei den Minor Upgrades von X.y auf x.1 wuerde ich nicht immer neuinstallieren wollen und eigentlich klappt das mit dem Inplace Upgrade ganz gut. Der "grosse" Unterschied zum normalen Patching ist da ja auch nicht.

Wenn jemand von 4.x auf 5.x geht da kann eine neuinstallation durchaus Sinnvoll erscheinen. Da VMware ja auch die AutoDeplay/Kickstart Geschichten immer aendert faengt man da ja gefuehlt auch immer bei Null an.

Gruss
Joerg

Dafür sollte aber auch der verwendetet 2 GB Stick ausreichen.