XEN Update - Versionsgeschichte

Neobiker: /* Driver Domain: XEN-Utils Installation */

2021-03-13T16:11:32Z

Driver Domain: XEN-Utils Installation

← Nächstältere Version		Version vom 13. März 2021, 18:11 Uhr
Zeile 218:		Zeile 218:
	</pre>		</pre>

	Jede virtuelle Maschine die unsere Domain-N als Network-Backend benutzt, erzeugt hier dynamisch ein neues virtuelles Netzwerkinterface ''~~vifx~~.y'', wobei x die ID der XEN-VM entspricht, und y der Interface-ID. Den Namen kann man aber in der XEN Konfiguration der VM mit dem Parameter ''vifname'' frei definieren (das funktioniert meiner Erfahrung nach nicht mit HVM DomUs).		Jede virtuelle Maschine die unsere Domain-N als Network-Backend benutzt, erzeugt hier dynamisch ein neues virtuelles Netzwerkinterface ''vifX.Y'', wobei X die ID der XEN-VM entspricht, und Y der Interface-ID. Den Namen kann man aber in der XEN Konfiguration der VM mit dem Parameter ''vifname'' frei definieren (das funktioniert meiner Erfahrung nach nicht mit HVM DomUs).
	Diese dynamisch erzeugten Interfaces müssen automatisch der Bridge br_lan hinzugefügt werden. Das kann auf zwei Arten erfolgen:		Diese dynamisch erzeugten Interfaces müssen automatisch der Bridge br_lan hinzugefügt werden. Das kann auf zwei Arten erfolgen:
	# man definiert die entsprechenden statischen Einträge in /etc/network/interfaces		# man definiert die entsprechenden statischen Einträge in /etc/network/interfaces
Zeile 237:		Zeile 237:

	Lösung zu 2) dynamische Konfiguration mittels '''xl devd'''		Lösung zu 2) dynamische Konfiguration mittels '''xl devd'''
	Der Daemon der diese Aufgabe erledigt wird mittels ''xl devd'' gestartet. Daher müssen die XEN-Utils installiert sein, was wir schon vorhin erledigt haben.		Der Daemon der diese Aufgabe erledigt wird mittels ''xl devd'' gestartet. Daher müssen die XEN-Utils installiert sein, was wir schon vorhin erledigt haben. Hierbei ist zu beachten, dass die Version von xen-utils identisch zur Version der Dom0 ist, da ja der xenstore der Dom0 gelesen wird.
	<pre>		<pre>
	xl devd		xl devd

Neobiker: /* Dom0: Driver Domain Konfiguration */

2021-03-13T15:54:41Z

Dom0: Driver Domain Konfiguration

← Nächstältere Version		Version vom 13. März 2021, 17:54 Uhr
Zeile 137:		Zeile 137:
	net.ipv4.ip_forward=1		net.ipv4.ip_forward=1
	</pre>		</pre>
	'''Alternativ''' kann man die Dom0 auch über eine ''Network-Proxy'' Konfiguration an das LAN anbinden. Das habe ich auf meinem Notebook als Testsystem gemacht, da sich das Wireless Device nicht zu einer Bridge hinzufügen lässt, wie ich es mit dem Ethernet Device üblicherweise mache. Diese Konfiguration werde ich hier demnächst noch ergänzen. Dabei ist aufgfallen, dass die kaum verwendeten XEN-Scripten vif-route und vif-nat Fehler enthalten, da sie vereinzelt den Befehl ''ifconfig'' noch nicht durch dessen Nachfolger ''ip'' ersetzt haben.		'''Alternativ''' kann man die Dom0 auch über eine ''Network-Proxy'' Konfiguration an das LAN anbinden. Das habe ich auf meinem Notebook als Testsystem gemacht, da sich das Wireless Device nicht zu einer Bridge hinzufügen lässt, wie ich es mit dem Ethernet Device üblicherweise mache. Diese Konfiguration werde ich hier demnächst noch ergänzen. Dabei ist aufgfallen, dass die kaum verwendeten XEN-Scripten ''vif-route'' und ''vif-nat'' Fehler enthalten, da sie vereinzelt den Befehl ''ifconfig'' noch nicht durch dessen Nachfolger ''ip'' ersetzt haben.

	'''Andernfalls''' kann man die Dom0 natürlich auch von einem '''internem Update-Mirror''' mit Updates versorgen. Dann braucht die Dom0 keine Verbindung mehr zum Internet. Sofern Domain-N selbst als Mirror dient, braucht man auch kein IP-Forwarding, und die Dom0 ist NUR von der Domain-N aus erreichbar.		'''Andernfalls''' kann man die Dom0 natürlich auch von einem '''internem Update-Mirror''' mit Updates versorgen. Dann braucht die Dom0 keine Verbindung mehr zum Internet. Sofern Domain-N selbst als Mirror dient, braucht man auch kein IP-Forwarding, und die Dom0 ist NUR von der Domain-N aus erreichbar.

Neobiker: /* Dom0: Driver Domain Konfiguration */

2021-03-13T15:53:42Z

Dom0: Driver Domain Konfiguration

← Nächstältere Version		Version vom 13. März 2021, 17:53 Uhr
Zeile 129:		Zeile 129:
	</pre>		</pre>

	Die '''Network Driver Domain''' ist jetzt die einzige Verbindung der Dom0 zur Aussenwelt. In den meisten Fällen muss daher in der DriverDomain '''IP-Forwarding''' aktiviert werden, damit die Dom0 sich mit dem Netzwerk verbinden kann. Je nach Netzwerk-Design muss auf dem Internet-Router eine Route zur Dom0 mit Domain-N als Gateway eingerichtet werden. Eine 'Outgoing NAT' Regel für die Dom0 in Richtung Internet muss natürlich ebenfalls aktiv sein.		Die '''Network Driver Domain''' ist jetzt die einzige Verbindung der Dom0 zur Aussenwelt. In den meisten Fällen muss daher in der DriverDomain '''IP-Forwarding''' aktiviert werden, damit die Dom0 sich mit dem Netzwerk verbinden kann. Je nach Netzwerk-Design muss auf dem Internet-Router eine zusätzliche '''Route''' zur Dom0 mit Domain-N als Gateway eingerichtet werden. Eine ''Outgoing NAT'' Regel für die Dom0 in Richtung Internet muss natürlich ebenfalls aktiv sein.
	<pre>		<pre>
	sysctl -w net.ipv4.ip_forward=1		sysctl -w net.ipv4.ip_forward=1
Zeile 137:		Zeile 137:
	net.ipv4.ip_forward=1		net.ipv4.ip_forward=1
	</pre>		</pre>
	'''Alternativ''' kann man die Dom0 auch über eine Network-Proxy Konfiguration an das LAN anbinden. Das habe ich auf meinem Notebook als Testsystem gemacht, da sich das Wireless Device nicht zu einer Bridge hinzufügen lässt, wie ich es mit dem Ethernet Device üblicherweise mache. Diese Konfiguration werde ich hier demnächst noch ergänzen.		'''Alternativ''' kann man die Dom0 auch über eine ''Network-Proxy'' Konfiguration an das LAN anbinden. Das habe ich auf meinem Notebook als Testsystem gemacht, da sich das Wireless Device nicht zu einer Bridge hinzufügen lässt, wie ich es mit dem Ethernet Device üblicherweise mache. Diese Konfiguration werde ich hier demnächst noch ergänzen. Dabei ist aufgfallen, dass die kaum verwendeten XEN-Scripten vif-route und vif-nat Fehler enthalten, da sie vereinzelt den Befehl ''ifconfig'' noch nicht durch dessen Nachfolger ''ip'' ersetzt haben.

	'''Andernfalls''' kann man die Dom0 natürlich auch von einem '''internem Update-Mirror''' mit Updates versorgen. Dann braucht die Dom0 keine Verbindung mehr zum Internet. Sofern Domain-N selbst als Mirror dient, braucht man auch kein IP-Forwarding, und die Dom0 ist NUR von der Domain-N aus erreichbar.		'''Andernfalls''' kann man die Dom0 natürlich auch von einem '''internem Update-Mirror''' mit Updates versorgen. Dann braucht die Dom0 keine Verbindung mehr zum Internet. Sofern Domain-N selbst als Mirror dient, braucht man auch kein IP-Forwarding, und die Dom0 ist NUR von der Domain-N aus erreichbar.

Neobiker: /* Dom0: Driver Domain Konfiguration */

2021-03-13T15:49:37Z

Dom0: Driver Domain Konfiguration

← Nächstältere Version		Version vom 13. März 2021, 17:49 Uhr
Zeile 137:		Zeile 137:
	net.ipv4.ip_forward=1		net.ipv4.ip_forward=1
	</pre>		</pre>
			'''Alternativ''' kann man die Dom0 auch über eine Network-Proxy Konfiguration an das LAN anbinden. Das habe ich auf meinem Notebook als Testsystem gemacht, da sich das Wireless Device nicht zu einer Bridge hinzufügen lässt, wie ich es mit dem Ethernet Device üblicherweise mache. Diese Konfiguration werde ich hier demnächst noch ergänzen.

	'''~~Alternativ~~''' kann man die Dom0 natürlich von einem '''internem Update-Mirror''' mit Updates versorgen. Dann braucht die Dom0 keine Verbindung mehr zum Internet. Sofern Domain-N selbst als Mirror dient, braucht man auch kein IP-Forwarding, und die Dom0 ist NUR von der Domain-N aus erreichbar.		'''Andernfalls''' kann man die Dom0 natürlich auch von einem '''internem Update-Mirror''' mit Updates versorgen. Dann braucht die Dom0 keine Verbindung mehr zum Internet. Sofern Domain-N selbst als Mirror dient, braucht man auch kein IP-Forwarding, und die Dom0 ist NUR von der Domain-N aus erreichbar.

	==== Driver Domain: Konfiguration ====		==== Driver Domain: Konfiguration ====

Neobiker: /* PVHVM / HVM */

2021-03-13T15:35:39Z

PVHVM / HVM

← Nächstältere Version		Version vom 13. März 2021, 17:35 Uhr
Zeile 403:		Zeile 403:
	on_crash = 'destroy'		on_crash = 'destroy'
	</pre>		</pre>
	Das ist also theoretisch der zweit beste XEN Modus um OPNSense in einer VM zu betreiben. Noch performanter ist der PVH Modus, der als nächstes betrachtet wird. In der Realität ist derzeit noch ~~dieser~~ Modus zu bevorzugen.		Das ist also theoretisch der zweit beste XEN Modus um OPNSense in einer VM zu betreiben. Noch performanter ist der PVH Modus, der als nächstes betrachtet wird. In der Realität ist derzeit meist noch der HVM Modus zu bevorzugen, da PVH noch nicht einzelne offene Punkte auf der ToDo Liste stehen hat, bevor alle Szenarien damit funktionieren.

	XenProject.org<ref>https://wiki.xenproject.org/wiki/PV_on_HVM</ref>: ''"PV on HVM is a mixture of paravirtualization and full hardware virtualization. The primary goal of PV on HVM is to boost performance of fully virtualized HVM guests through use of specially optimized paravirtual device drivers (also called PVHVM or PV-on-HVM drivers).''		XenProject.org<ref>https://wiki.xenproject.org/wiki/PV_on_HVM</ref>: ''"PV on HVM is a mixture of paravirtualization and full hardware virtualization. The primary goal of PV on HVM is to boost performance of fully virtualized HVM guests through use of specially optimized paravirtual device drivers (also called PVHVM or PV-on-HVM drivers).''

Neobiker: /* PVHVM / HVM */

2021-03-13T15:33:20Z

PVHVM / HVM

← Nächstältere Version		Version vom 13. März 2021, 17:33 Uhr
Zeile 378:		Zeile 378:
	PVHVM ist die klassische Standard HVM Variante die bis Dato für Windows-VMs verwendet werden: In das OS der VM werden optimierte XEN-Treiber installiert, die eine Paravirtualisierte Schnittstelle zum XEN-Backend zur Verfügung stellen um eine bessere Performance zu erzielen.		PVHVM ist die klassische Standard HVM Variante die bis Dato für Windows-VMs verwendet werden: In das OS der VM werden optimierte XEN-Treiber installiert, die eine Paravirtualisierte Schnittstelle zum XEN-Backend zur Verfügung stellen um eine bessere Performance zu erzielen.

	OPNSense verfügt mit FreeBSD als zugrunde liegendem Betriebssystem bereits über die notwendigen XEN PV-Treiber, daher muss keine Emulation für Disk- und Netzwerkressourcen verwendet werden~~. Disk und Netzwerk Einträge starten nicht QEMU zur Emulation, sondern es werden die nativen XEN PV-Treiber verwendet~~.		OPNSense verfügt mit FreeBSD als zugrunde liegendem Betriebssystem bereits über die notwendigen XEN PV-Treiber, daher muss keine Emulation für Disk- und Netzwerkressourcen verwendet werden.

	<pre>		<pre>

Neobiker: /* Dom0: XEN VM Start-/Stop- Reihenfolge */

2021-03-13T15:31:28Z

Dom0: XEN VM Start-/Stop- Reihenfolge

← Nächstältere Version		Version vom 13. März 2021, 17:31 Uhr
Zeile 292:		Zeile 292:
	Nachdem zukünftig alle VMs von der Driver Domain abhängig sind, um Netzwerkverbindung zu erhalten, müssen wir uns noch um die Startreihenfolge kümmern. Beim Runterfahren des gesamten Systems sollte die Driver Domain auch erst nach allen anderen VMs runterfahren. Hierzu passen wir innerhalb der Dom0 das File '''xendomains''' an, welches alle VMs automatisch startet und auch stoppt.		Nachdem zukünftig alle VMs von der Driver Domain abhängig sind, um Netzwerkverbindung zu erhalten, müssen wir uns noch um die Startreihenfolge kümmern. Beim Runterfahren des gesamten Systems sollte die Driver Domain auch erst nach allen anderen VMs runterfahren. Hierzu passen wir innerhalb der Dom0 das File '''xendomains''' an, welches alle VMs automatisch startet und auch stoppt.

	Die Idee ist, dass wir ein 2.tes Start-/Stop- File '''xendomains.local''' anlegen, welches alle VMs die nicht die Driver Domain Domain-N, eine Firewall (opnsense) oder ein File-Server sind zuerst stoppen, dann den File-Server und anschliessend die Firewall stoppen, bevor das normale ''xendomains'' Skript alle restlichen virtuellen Maschinen runterfährt, welches jetzt nur noch die Driver Domain Domain-N sein sollte.		Die Idee ist, dass wir ein 2.tes Start-/Stop- File '''xendomains.local''' anlegen, welches alle VMs die nicht die Driver Domain Domain-N, eine Firewall (opnsense) oder ein Domain/File-Server sind zuerst stoppen, dann den Domain/File-Server und anschliessend die Firewall stoppen, bevor das normale ''xendomains'' Skript alle restlichen virtuellen Maschinen runterfährt, welches jetzt nur noch die Driver Domain Domain-N sein sollte.

	Hier ist das zusätzliche Dom0 [[ Init-Skript xendomains.local \| Init-Skript '''/etc/init.d/xendomains.local''' ]] zum stoppen der VMs in vorgegebener Reihenfolge.		Hier ist das zusätzliche Dom0 [[ Init-Skript xendomains.local \| Init-Skript '''/etc/init.d/xendomains.local''' ]] zum stoppen der VMs in vorgegebener Reihenfolge.

Neobiker: /* Dom0: XEN VM Start-/Stop- Reihenfolge */

2021-03-13T15:30:10Z

Dom0: XEN VM Start-/Stop- Reihenfolge

← Nächstältere Version		Version vom 13. März 2021, 17:30 Uhr
Zeile 290:		Zeile 290:

	==== Dom0: XEN VM Start-/Stop- Reihenfolge ====		==== Dom0: XEN VM Start-/Stop- Reihenfolge ====
	Nachdem zukünftig alle VMs von der Driver Domain abhängig sind, um Netzwerkverbindung zu erhalten, müssen wir uns noch um die Startreihenfolge kümmern. Beim Runterfahren des gesamten Systems sollte die Driver Domain auch erst nach allen anderen VMs runterfahren. Hierzu passen wir innerhalb der Dom0 das File '''xendomains''' an, welches alle VMs automatisch startet und auch ~~stopped~~.		Nachdem zukünftig alle VMs von der Driver Domain abhängig sind, um Netzwerkverbindung zu erhalten, müssen wir uns noch um die Startreihenfolge kümmern. Beim Runterfahren des gesamten Systems sollte die Driver Domain auch erst nach allen anderen VMs runterfahren. Hierzu passen wir innerhalb der Dom0 das File '''xendomains''' an, welches alle VMs automatisch startet und auch stoppt.

	Die Idee ist, dass wir ein 2.tes Start-/Stop- File '''xendomains.local''' anlegen, welches alle VMs die nicht die Driver Domain Domain-N, eine Firewall (opnsense) oder ein File-Server sind zuerst stoppen, dann den File-Server und anschliessend die Firewall stoppen, bevor das normale ''xendomains'' Skript alle restlichen virtuellen Maschinen runterfährt, welches jetzt nur noch die Driver Domain Domain-N sein sollte.		Die Idee ist, dass wir ein 2.tes Start-/Stop- File '''xendomains.local''' anlegen, welches alle VMs die nicht die Driver Domain Domain-N, eine Firewall (opnsense) oder ein File-Server sind zuerst stoppen, dann den File-Server und anschliessend die Firewall stoppen, bevor das normale ''xendomains'' Skript alle restlichen virtuellen Maschinen runterfährt, welches jetzt nur noch die Driver Domain Domain-N sein sollte.

Neobiker: /* Driver Domain: XEN-Utils Installation */

2021-03-13T15:28:02Z

Driver Domain: XEN-Utils Installation

← Nächstältere Version		Version vom 13. März 2021, 17:28 Uhr
Zeile 217:		Zeile 217:
	</pre>		</pre>

	Jede virtuelle Maschine die unsere Domain-N als Network-Backend benutzt, erzeugt hier dynamisch ein neues virtuelles Netzwerkinterface ''vifx.y'', wobei x die ID der XEN-VM entspricht, und y der Interface-ID. Den Namen kann man aber in der XEN Konfiguration der VM mit dem Parameter ''vifname'' frei definieren.		Jede virtuelle Maschine die unsere Domain-N als Network-Backend benutzt, erzeugt hier dynamisch ein neues virtuelles Netzwerkinterface ''vifx.y'', wobei x die ID der XEN-VM entspricht, und y der Interface-ID. Den Namen kann man aber in der XEN Konfiguration der VM mit dem Parameter ''vifname'' frei definieren (das funktioniert meiner Erfahrung nach nicht mit HVM DomUs).
	Diese dynamisch erzeugten Interfaces müssen automatisch der Bridge br_lan hinzugefügt werden. Das kann auf zwei Arten erfolgen:		Diese dynamisch erzeugten Interfaces müssen automatisch der Bridge br_lan hinzugefügt werden. Das kann auf zwei Arten erfolgen:
	# man definiert die entsprechenden statischen Einträge in /etc/network/interfaces		# man definiert die entsprechenden statischen Einträge in /etc/network/interfaces

Neobiker: /* PVH FreeBSD Konfiguration */

2021-03-13T15:17:43Z

PVH FreeBSD Konfiguration

← Nächstältere Version		Version vom 13. März 2021, 17:17 Uhr
Zeile 505:		Zeile 505:
	</pre>		</pre>

	OPNSense (FreeBSD Firewall Implementierung PF) benötigt folgende Anpassung der Netzwerkschnittstellen: '''Tx off'''.		OPNSense bzw. die FreeBSD Firewall Implementierung ''PF'' (Paket Filter) benötigt folgende Anpassung der Netzwerkschnittstellen: '''Tx off'''.

	Dafür verwende ich folgendes angepasstes '''vif-bridge_TxOff''' Skript (''ethtool'' vorher installieren nicht vergessen):		Dafür verwende ich folgendes angepasstes '''vif-bridge_TxOff''' Skript (''ethtool'' vorher installieren nicht vergessen):