Mislykket USB passthrough til Home Assistant via ESXi og XPEnology

ADVARSEL: Denne guiden endte med at hele systemet gikk ned. Ikke følg den. Den står igjen som dokumentasjon på hvordan én endring i ESXi tok ned alt.

Bakgrunn

Jeg har en ConBee II ZigBee-antenne som har ligget i ukesvis i en boks merket «SMARTHUS». Planen er å flytte Home Assistant fra en Raspberry Pi til Docker. Da må USB-enheten sendes gjennom hele stacken: fra den fysiske maskinen, gjennom ESXi, gjennom XPEnology og inn i Docker-containeren.

ConBee II ZigBee-antenne
ConBee II i sitt naturlige habitat

Den lokale elektronikkbutikken tok aldri inn antennen, så jeg kjøpte den på nett. Da den kom, gikk den rett i boksen, og der lå den til i dag.

ConBee II tilkobling
USB-forlenger
Midlertidig oppheng i taket
Tilkobling og midlertidig oppheng i taket med en fem meter USB-forlenger

Antennen må gjennom tre lag

Home Assistant kjører i Docker, som kjører på XPEnology, som kjører på ESXi på serveren. Antennen må sendes videre gjennom alle tre lagene. Plansjen viser rekkefølgen:

Diagram over lag-arkitekturen: server, ESXi, XPEnology, Docker, Home Assistant
Antennen må gjennom RØDT (ESXi), så BLÅTT (XPEnology), så GRØNT (Docker)

Steg 1: USB passthrough i ESXi (rødt lag)

ESXi innlogging
Logg inn på ESXi

Planen:

  • Gå til Manage → Hardware → PCI Devices
  • Velg USB-kontrolleren for passthrough
  • Restart

Hos meg var alle valgene her grået ut, så ingenting kunne sendes videre.

ESXi PCI passthrough grået ut
Lite passthrough-vennlig, dette her

PCI-ID-ene legges inn manuelt via SSH

Omveien er å logge inn med SSH, finne PCI-ID-ene til USB-kontrolleren og legge dem inn i passthru.map for hånd.

Slå på SSH i ESXi
Slå på SSH i ESXi
SSH-tilkobling via Putty
Inne via SSH

lspci viser alle PCI-enheter, og lspci -n gir de numeriske ID-ene:

lspci output
lspci avslører at USB-kontrolleren ligger på 0000:00:14.0
lspci -n output
lspci -n avslører Device ID 0xa36d og Vendor ID 0x8086

Vendor- og Device-ID er altså 8086:a36d. Den legges inn i passthrough-konfigurasjonen:

vi /etc/vmware/passthru.map
# Legg til nederst:
8086 a36d d3d0 false
d3d0
er reset-metoden for PCI-kontrolleren, og false slår av «Full Passthrough Shareable».

ESXi mistet tilgangen til sin egen USB-disk

Etter restart ble USB-kontrolleren sendt videre. Dermed kunne ESXi ikke lenger nå sin egen datastore på USB, og heller ikke oppdatere konfigurasjonen sin, som også lå på USB.

Jeg prøvde å rette det omtrent 20 ganger før jeg forsto hva som hadde skjedd. Deretter monterte jeg USB-pennen på en Raspberry Pi for å rette innstillingene manuelt. Det virket ikke, fordi jeg endret feil partisjon.

På riktig partisjon fikk jeg denne feilen:

ESXi feilmelding etter mislykket passthrough

Jeg ga opp og skulle gjenopprette fra backup. Backupen lå på XPEnology, som nå var utilgjengelig.

En eldre backup på en ekstern disk virket godt nok. XPEnology kom opp igjen, men Docker ville ikke starte.

Gjenopprettingsprosessen steg 1
Gjenopprettingsprosessen
Gjenopprettingsprosessen

Lærdom

USB passthrough er satt på vent. Systemet kom så vidt tilbake, og alle Docker-containere unntatt SABnzbd og Ghost må settes opp på nytt. Ingen filer gikk tapt, men det var flaks.

Den viktigste lærdommen er å ha skikkelig backup av Docker-konfigurasjonen. Den jobben er prioritert nå.