Editing Host:Helios

{{Host
|name=helios.chaosdorf.space
|description=almighty server
|image=helios.jpg
|os=Debian 12
|location=Lounge
|purpose=virtualization host
|disk=38TB
|ram=32GiB
|admin_toolkit=Yes
|ssh_pam=Yes
|ssh_userlogin=No
|ownership=club
|use=ask
|admins=derf, byte, nomaster, uen, feuerrot, ytvwld, nik
|netbox_id=12
}}
Großer mächtiger VM-Host für Clubrauminfrastruktur und Projekte. Ein Teil der Dienste befindet sich auch auf dem [[Kubernetes Cluster]].

== Hardware ==

* Mainboard: [http://www.asrockrack.com/general/productdetail.asp?Model=C2750D4I ASRock Mini-ITX mit 12x SATA]
* CPU: [http://ark.intel.com/products/77987 Intel Avoton C2750 8-Core]
* Storage: [http://www.wdc.com/global/products/specs/?driveID=1311&language=1 2x 1TB WD10JFCX Red]
* RAM: 1x 32GB DDR3 1600MHz ECC
* Gehäuse: 19" [http://www.chenbro.com/en-global/products/RackmountChassis/2U_Chassis/RM23608 RM-236-8 2HE mit 8 Festplatteneinschüben]
* Netzteil: 400W EPS Green

== Storage ==

Das Gehäuse bietet Platz für 10 SATA-Platten, davon 2 intern (2.5") und 8 in Festplattenschächten (3.5").

Layout bei Aufsicht aufs Gehäuse:
{| class="wikitable"
|-
| System
| System
|
|
|-
| VMs (alt)
| Storage
| VMs (neu)
| VMs (neu)
|-
| VMs (alt)
| Storage
| leer
| leer
|}

=== Systemplatten ===

Sind die beiden internen 2.5"-Platten. Jeweils 1TB Western Digital Red (WDC WD10JFCX-68N6GN0). Auf beiden Platten befinden sich aus historischen Gründen™ vier Partitionen á 250GB, die wie folgt genutzt werden.

* 1. Partition: RAID 1 für /
* 2. Partition: RAID 1 für <tt>backup</tt>-VG
* 3. Partition: RAID 1 für <tt>backup</tt>-VG
* 4. Partition: RAID 1 für <tt>backup</tt>-VG

=== VM-Platten ===

* VMs1: Hitachi Deskstar 7K2000 HDS722020ALA330 (wwn-0x5000cca222c96707)
* VMs2: Hitachi Deskstar 7K2000 HDS722020ALA330 (wwn-0x5000cca221c5cc76)

Jeweils 2TB Hitachi Deskstar 7K2000 (HDS722020ALA330). Darauf liegt ein RAID1 für die VG <tt>vmstorage</tt>, welche wiederum LVs für die einzelnen VMS enthält.

=== Storage ===

Zwei 16TB-Platten, auf denen sich jeweils ein LUKS-Container (<tt>/dev/mapper/storage?</tt>) befindet, die an die VM {{H|fileserver}} durchgereicht werden.

== Netzwerk ==

Von hinten betrachtet hat das Mainboard drei Netzwerkinterfaces.

* Oben links: IPMI
* Oben rechts: eth0
* Unten rechts: eth1

Das IPMI-Interface ist vom Betriebssystem aus nicht sichtbar. Die anderen beiden sind als bond0 per LACP / 802.3ad zusammengefasst. IP/IPv6 ist darauf nicht konfiguriert.

Aus bond0 fällt VLAN 1 (Management) untagged raus, die VLANs 3-5 tagged. VLAN 2 (WAN) ist nicht erreichbar.
Alle weiteren Interfaces sind Bridges auf Basis von bond0.

{| class="wikitable sortable"
|-
! Interface !! IP !! libvirt-Name !! Beschreibung
|-
| br0 || 192.168.0.9 (statisch) || management || Direkte Verbindung zu bond0, d.h. VLAN 1
|-
| br1 || — || — || VLAN 1 auf bond0
|-
| br3 || 172.22.26.11 (DHCP) || default || VLAN 3 auf bond0
|-
| br4 || — || freifunk-mesh || VLAN 4 auf bond0
|-
| br5 || — || freifunk-client || VLAN 5 auf bond0
|-
| br21 || — || — || VLAN 21 auf bond0
|}

Die Bridges br1, br4 und br5 werden ausschließlich für VMs verwendet. IPv6 ist dort per <tt>/etc/sysctl.d/ipv6.conf</tt> aus, IPv4 per <tt>/etc/network/interfaces</tt>. Auf br3 und br21 läuft zwar IPv6, es werden aber keine Router Advertisements akzeptiert (damit alles per br3 über das normale Access-Netz rausgeht und public IPv6 überhaupt funktioniert).

== Virtuelle Maschinen ==
{{#ask: [[Has location::Host:Helios]] [[Host:+]]
 | ?Hostname
 | ?Operating System
 | ?Disk size
 | ?RAM size
 | ?Has admins = Admins
}}

=== VM anlegen ===

Zum Beispiel ein Debian Stretch im Access VLAN mit 1GiB RAM und 20GB Festplatte:

    <nowiki>virt-install --connect qemu+ssh://helios.chaosdorf.space/system -n testvm --memory 1024 --network network=default --cpu host --boot uefi --os-variant debian12 -l http://ftp.de.debian.org/debian/dists/stable/main/installer-amd64/ --disk pool=vmstorage,size=20</nowiki>

Falls vorhanden, kann eine preseed-Konfiguration mit <tt>--initrd-inject</tt> berücksichtigt werden.

=== Snapshots ===

Am Beispiel des Dockerserver

* VM herunterfahren (→ Konsistenter Dateisystemzustand)
* <tt>sudo lvcreate --snapshot --size 250g --name dockerserver-backup vmstorage/dockerserver</tt> (Größe anhand des erwarteten Schreibumfangs auf dem per Snapshot gesicherten Volume anpassen)
* VM starten, Dinge tun (z.B. komplexeres Dist-Upgrade)
* Wenn erfolgreich: <tt>sudo lvremove vmstorage/dockerserver-backup</tt>
* Andernfalls Rollback: VM herunterfahren, <tt>sudo lvconvert --merge vmstorage/dockerserver-backup</tt>, VM wieder starten

== IPMI ==

Ist das Interface links und sehr seriös. Als grundlegender Alias empfiehlt sich
    helios-ipmi='ipmitool -I lanplus -H helios-ipmi.chaosdorf.dn42 -U meinnick -f datei/mit/passwort'

ipmitool benutzt wenn möglich IPv6. Nach Änderungen an der VLAN-Config ist das IPMI-Interface teils nur noch per IPv4 erreichbar, dann muss helios-ipmi.chaosdorf.dn42 durch die entsprechende IPv4-Adresse ersetzt werden. Eigentlich sollte das nicht passieren, da das IPMI-Interface an einem eigenen Switchport hängt, der von den sonstigen Änderungen unabhängig ist — Irgendwas ist da aber komisch™.

Nützliche Befehle sind unter anderem:

* Watchdogstatus auslesen: <tt>helios-ipmi bmc watchdog get</tt>
* Watchdog ausschalten (falls z.B. ein neues System installiert wird): <tt>helios-ipmi bmc watchdog off</tt>
* Serielle Konsole: <tt>helios-ipmi sol activate</tt>
* System an-/ausschalten/neustarten: <tt>helios-ipmi power on/off/cycle</tt>

=== Serial over LAN ===

ttyS1 ist per IPMI nutzbar. BIOS geht darüber auch. Grub und Kernel sind vermutlich so konfiguriert, dass sie ausschließlich mit der seriellen IPMI-Konsole (und nicht mit einem angeschlossenen Monitor) reden.

=== Watchdog ===

Das Mainboard hat einen IPMI (SMS/OS) Watchdog. Der Daemon '''bmc-watchdog''' setzt diesen alle 60 Sekunden zurück. Falls er nicht läuft, wird automatisch nach 15 Minuten ein hard reset ausgelöst.