ESX / ESXi - Hilfethread

Hi

Ich habe in meinen ESXi eine neue 500GB SSD eingebaut und an napp-it gehängt. Napp-it gibt davon 450GB als NFS an vSphere zurück, 50GB hatte ich als Überlaufschutz, welchen ich nun auf 10GB runter genommen habe.

Auf dem Share habe ich zwei vmdk angelegt. 50 GB für ein Debian mit Nextcloud, 350GB für die Daten von Nextcloud. Ich hatte zwei Snapshots gemacht, einmal nach der Grundinstallation und einmal nach dem anhängen der Datenplatte und einrichten der Nextcloud. Dummerweise hatte ich vergessen, die Datenplatte als unabhängig zu markieren. Die Datenplatte habe ich bereits mit ~200GB gefüllt.

Nun wollte ich die beiden Snapshots löschen. Den zweiten konnte ich löschen, allerdings nicht mehr konsolidieren da zuwenig Platz auf dem Datenträger vorhanden war. Dann wollte ich den ersten Snap löschen, da hat er stundenlang bei 75-80% rum gerödelt. In dem Zuge habe ich noch den Überlaufschutz auf 10GB runter genommen. Als dann bei 80% wieder nichts mehr ging, habe ich im Host Client bei den aktuellen Tasks unten auf Konsolidieren abbrechen geklickt. Nun geht gar nichts mehr, d.h., ich kann mich nicht einmal mehr beim host Client anmelden. Der lädt jetzt ewig die Anmeldeseite. Die Gäste laufen aber noch.

Wie gehe ich jetzt am besten vor?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
hmm, nach längerer Gedenkpause konnte ich mich wieder einloggen und die Datenpartition löschen. Ich glaube, ich kriege es selbst hin jetzt, nur muss ich die ganzen Daten halt nochmals rein kopieren.
 
Das würde mich jetzt wirklich interessieren, welche Tricks du nutzt. Läßt sich das soweit verallgemeinern, daß das nachher auch unabhängig von der Host-CPU einfach läuft?

Nea du musst vier sachen machen. In der .vmx von deiner Windows VM folgende Parameter hinzufügen.
Erstens: hypervisor.cpuid.v0 = FALSE
Zweites: pciPassthru0.msiEnabled = FALSE
Drittes: pciPassthru.use64bitMMIO = TRUE

Dann musst du noch in der passthru.map

# NVIDIA
10de ffff bridge false

von bridge auf link stellen, ich konnte diesen schritt überspringen, ging bei mir auch ohne und hat auch keine änderung gebracht.

Funktioniert mit eigentlich jeder Nvidia Consumer Karte und egal bei welcher ESXI Version ab 6.5. :-)

Also ich habe es ja wie geschrieben momentan in UnRaid laufen und läuft auch top, jetzt stehe ich eher vor dem Problem das der 3900X scheinbar zu schwach ist.
Bin die ganze Zeit im CPU Limit. Beispielweise bei Watch Dogs Legion 1080p alles auf Max + Raytracing gerade mal 60 bis 70% GPU Auslastung bei 50 bis 90 FPS.
 
Zuletzt bearbeitet:
Hallo zusammen, ich bekomme unter ESXi 7.0 und fertig eingerichtetem virtuellem TrueNAS mit durchgereichtem HBA-Controller die Platten nicht per iSCSI als Datastorage an den Host geroutet.
vSwitch und Portgruppe sind entsprechend eingerichtet. Wenn ich den iSCSI-Share an eine Windows-VM auf demselben Host mounte, klappt es direkt. Ich vermute hier eine Fehlkonfiguration im virtuellen iSCSI-Netzwerk meinerseits.
Externen TrueNAS-Server habe ich am laufen und der tut es per iSCSI auch. Nur mit dem AiO komme ich nicht mehr weiter. Hat jemand eine Idee oder Anleitung für mich? Danke!

Grüße maxblank
 
Hallo,

hat jemand von euch ein shutdown Skript für ESXI in Verbindung mit Truenas/Freenas? Ich will meinen Server nicht 24/7 laufen lassen. Das Skript sollte prüfen ob auf dem Freenas ab einer bestimmte Uhrzeit X irgendwelche Aktivitäten sind (Festplatte, Netzwerk) und prüfen ob bestimmte Clients noch online sind. Wenn das alles nicht der Fall ist, an ESXI den Befehl senden, dass VMs in bestimmter Reihenfolge herunterfahren sollen (kann man ja im ESXI einstellen).
 
Ich muss jetzt nochmal das Thema ESXI Backup aufgreifen.

Auch ich nutze, wie viele andere hier wohl auch, VEEAM Backup and Replication.

Funktioniert derzeit wie folgt:
- Windows 10VM läuft auf meinem zu backuppenden Host mit VEEAM
- TrueNAS VM läuft auf meinem Host, worauf das Backup geschoben wird
- 1x pro Woche geht von diesem TrueNAS Host das Backup der ESXI VM's auf einen separaten Server im Keller

Klingt ja alles erstmal schön für einen Baby-Gau: Windows 10VM mit VEEAM starten -> Backup auswählen -> Einspielen -> Fertig ist die Laube

Aber im Super-Gau (SSD, wo ESXI und die VM's drauf laufen verabschiedet sich vollends): TrueNAS VM erstmal nicht erreichbar, Windows10 VM nicht erreichbar

Sprich: Neue SSD einbauen, ESXI installieren, TrueNAS mit einem Konfig-Backup wiederherstellen -> Windows 10 VM vom externen BackupServer erstmal wieder irgendwie zum laufen bekommen -> Nach und nach die Backups zurückspielen...Geht auch theoretisch, aber das kann schon sehr zäh werden und lief beim letzten Trockenlauf auch nicht reibungslos ab.

Überlegung war nun:
- Billigste Synology / QNAP kaufen und dort die Backups mit Veeam draufschieben lassen. Problem bleiben nur bestehen: Brauchst ja trotzdem nach einem richtigen Crash erstmal wieder die Windows 10 VM mit VEEAM. Und die integrierte Software von Synology zum Backup soll ja auch nicht der Knaller sein.

Wie habt ihr das als gesamtes Konzept gelöst?
Für mich wäre am schönsten:
- Backup auf externes NAS (Synology / Qnap / Welcher Anbieter auch immer)
- SSD ersetzen und ESXI neu installieren
- NAS per NFS mounten -> alle VMDK Files etc. in den neuen VMFS Speicher von ESXI kopieren -> Backup von ESXI einspielen -> Reboot -> Fertig. Das wären gefühlt zehn Klicks und zwei Stunden einfach warten und Kaffee trinken.

Aber noch nix in der Richtung gefunden.
Ne schöne Option wäre natürlich noch mein aktueller Backupserver, von dort aus die Backups erledigen zu lassen, bloß frisst die Kiste 100W an Strom und ist daher im Dauerbetrieb keine Option nur für diesen Komfort. Auto-Shutdown und Wake-Up für die Backup-Jobs ist mit der ESXI Basis vom BackupServer auch keine Option.
 
Synology hat ein passabes Backup Modul welches auch mit der freien ESXi Version zusammenspielt. Für den Restore musst du nur den ESXi wiederherstellen. Sofern du ein x86 NAS kaufst, kannst du deine Win10 VM sogar auf der Synology starten.
 
Synology hat ein passabes Backup Modul welches auch mit der freien ESXi Version zusammenspielt. Für den Restore musst du nur den ESXi wiederherstellen. Sofern du ein x86 NAS kaufst, kannst du deine Win10 VM sogar auf der Synology starten.
Active Backup Suite?

Müsste nur mal schauen, ob es das auch für die günstigste 1-Bay Serie gibt, soll nur für den Desaster Fall sein... Und wäre doof, wenn nur für diesen Komfort die teureren 350€ Geräte her müssten.
 
In dem Fall wäre ggf noch Xpenology eine Option => die günstigen Syonlogy´s haben keinen Support für die Backup Suite.
 
In dem Fall wäre ggf noch Xpenology eine Option => die günstigen Syonlogy´s haben keinen Support für die Backup Suite.
Mhh, das ist schon wieder doof. Dafür müsste auch wieder ein extra Server laufen, 100W Dauerlauf sind keine Option dafür, müsste dann schauen, wie zuverlässig Auto-Boot und Auto-Shutdown funktioniert.
 
Kannst Du nicht einfach eine veeam rescue/recovery ISO erstellen, von der booten (in einer neuen VM) und dann die VMs zurück spielen?

Ich nutze bisher nur Veeam agents mit direktem Backup auf SMB Laufwerk, da funktioniert das reibungslos.

Was ist der Vorteil des zwischengeschalteten Veeam Backup & Recovery Servers? (Ernsthaft, überlege das auch umzustellen, verstehe aber noch nicht Recht denn Mehrwert dahinter)
 
Kannst Du nicht einfach eine veeam rescue/recovery ISO erstellen, von der booten (in einer neuen VM) und dann die VMs zurück spielen?

Ich nutze bisher nur Veeam agents mit direktem Backup auf SMB Laufwerk, da funktioniert das reibungslos.

Was ist der Vorteil des zwischengeschalteten Veeam Backup & Recovery Servers? (Ernsthaft, überlege das auch umzustellen, verstehe aber noch nicht Recht denn Mehrwert dahinter)
Theoretisch wäre das eine Option (wusste noch gar nicht, dass die ne recovery-ISO haben). Praktisch müsste ich zumindest erstmal TrueNAS wiederherstellen, da auf diesem die ganzen Backups lagern.

Veeam Agents habe ich bis jetzt auch noch nicht genutzt, nur die Backup and Replication, da ich das als einzig kostenloses Tool von VEEAM gefunden hatte. Da sowieso eine Windows 10 VM für Remote-Wartung in Betrieb ist, habe ich auf dieser auch Backup and Replication in Betrieb genommen. Funktioniert auch top, aber im Falle eines Totalausfalls, echt kompliziert. Weitere Vorteile dürfte es soweit nicht geben (wobei mir eben auch der Vergleich zu Veeam Agents fehlt).
 
Moin zusammen,

seit dem ESXi-Upgrade zeigen meine VMs im WebUI und in der Konsole nur noch einen schwarzen Bildschirm, weiß jemand warum?
Habe die VMs von einem ESXi zum anderen und wieder auf den neuen zurück geschoben mit der SCP-Methode.
Funktionieren tut alles darin, Webmin geht und die Services laufen auch einwandfrei.

Eine testweise neu angelegte VM zeigt das Verhalten nicht -> hier sehe ich die Bildschirmausgabe.

ESXi ist 7.0U1d (von U1c-ISO installiert und geupdatet).

//edith:
Hilfe zur Selbsthilfe:
Das Entfernen der drei Optionen:
vpmc.enable = "TRUE"
vhv.enable = "TRUE"
vvtd.enable = "TRUE"
hat geholfen.
//edith2:
Reicht wohl, die IOMMU beim EPYC nicht an die VMs durchzureichen.
Wieso?
 
Zuletzt bearbeitet:

Mit link auf VMware advisory:

Korrigierte versionen scheinen aber bereits in den letzten ESXi Updates/Patches enthalten zu sein.
 
Wie habt ihr das als gesamtes Konzept gelöst?
- QNAP startet Nachts
- VM mit Veeam macht Backups aufs QNAP
- QNAP sichert Daten der Nextcloud
- QNAP sichert Backups zusätzlich in Cloud und/oder auf ext. HDD
- QNAP fährt sich herunter

Zum Zurückspielen deiner Backups brauchst du deine Veeam-VM nicht zwingend, du kannst Veeam auch auf deinem normalen Rechner installieren und darüber auf die Backups vom NAS zugreifen.

P.S.: Schau dir mal Nakivo als Alternative für die Active Backup Suite an.
 
- QNAP startet Nachts
- VM mit Veeam macht Backups aufs QNAP
- QNAP sichert Daten der Nextcloud
- QNAP sichert Backups zusätzlich in Cloud und/oder auf ext. HDD
- QNAP fährt sich herunter

Zum Zurückspielen deiner Backups brauchst du deine Veeam-VM nicht zwingend, du kannst Veeam auch auf deinem normalen Rechner installieren und darüber auf die Backups vom NAS zugreifen.

P.S.: Schau dir mal Nakivo als Alternative für die Active Backup Suite an.
Habe das nun so gelöst, musst bloß QNAP durch FUJITSU ersetzen (meinem Backupserver, wo ich noch ein extra Dataset angelegt habe).

Nun sichert mein Hauptserver 1x wöchentlich die notwendigen VM's zum Restore, sprich:
- PFSense
- Windows 10 Backup-VM
- TrueNAS

Auf dem Fujitsu wurde VEEAM so konfiguriert, dass er von Fujitsu die oben, drei genannten VM's zurückspielt und dann der Hauptserver wieder voll startfähig ist und von dort der Restore normal vonstatten gehen kann. So bringe ich Stromverbrauch und schnellen Restore in Einklang miteinander.

Mein normaler Rechner (nur Laptop) ist dafür leider nicht geeignet, da sich dieser die Hälfte des Jahres hunderte Kilometer vom Serverstandort ;) entfernt befindet.
 
Moin zusammen, wie handhabt ihr es, so dass man mit dem VCenter Server auch alle ESXI updaten kann?
Ich habe bei der Testinstallation immer das Problem, dass der Host, auf dem der VCenter läuft nicht selbst updaten mag, was ich unpraktisch finde. Klar, mit der Hand und ssh geht es, aber das ist ja nicht so komfortabel :-) Würde mich über Eure Erfahrung und Ratschläge freuen.
 
Daheim gibts bei mir kein VCenter, kann man ja nicht sinnvoll mit privaten Mitteln lizenzieren ^^
 
Moin zusammen, wie handhabt ihr es, so dass man mit dem VCenter Server auch alle ESXI updaten kann?
Das hört sich danach an als dass es mehrere Hosts gibt, richtig? Wenn das mehrere Hosts mit zentraler Storage sind und vMotion eingerichtet ist, ist es einfach:
  1. (vCenter Server und abhängige Software wie z.B. Veeam Backup&Replication aktualisieren, damit der Host weiterhin vom vCenter Server verwaltet werden kann)
  2. Einen der Hosts aktualisieren
  3. vCenter per vMotion auf diesen schon aktualisierten Host verschieben
  4. Alle anderen Hosts aktualisieren
Wenn das mehrere Hosts mit zentraler Storage sind, vMotion aber nicht eingerichtet ist, ist es etwas komplizierter:
  1. (vCenter Server und abhängige Software wie z.B. Veeam Backup&Replication aktualisieren, damit der Host weiterhin vom vCenter Server verwaltet werden kann)
  2. Einen der Hosts aktualisieren
  3. Auf diesen Host und den Host, auf dem der vCenter Server bisher läuft, per Host Client verbinden
  4. vCenter Server herunterfahren, vom noch nicht aktualisierten Host deregistrieren, auf dem schon aktualisierten Host registrieren und hochfahren
  5. Alle anderen Hosts aktualisieren
Ohne zentrale Storage wird's natürlich schwierig, da muss eben der Host wirklich manuell aktualisiert werden. Das geht ja aber normalerweise relativ einfach, indem das aktuellste ESXi-Installationsmedium heruntergeladen und davon gebootet wird, dann sollte die Installationsroutine den installierten ESXi erkennen und ein Update anbieten.
 
Moin zusammen, wie handhabt ihr es, so dass man mit dem VCenter Server auch alle ESXI updaten kann?
Ich habe bei der Testinstallation immer das Problem, dass der Host, auf dem der VCenter läuft nicht selbst updaten mag, was ich unpraktisch finde. Klar, mit der Hand und ssh geht es, aber das ist ja nicht so komfortabel :-) Würde mich über Eure Erfahrung und Ratschläge freuen.
Ich habe den vCenter Server auf dem Laptop mit VMware Workstation Pro aufgesetzt.
 
Moin zusammen, wie handhabt ihr es, so dass man mit dem VCenter Server auch alle ESXI updaten kann?
Ich habe bei der Testinstallation immer das Problem, dass der Host, auf dem der VCenter läuft nicht selbst updaten mag, was ich unpraktisch finde. Klar, mit der Hand und ssh geht es, aber das ist ja nicht so komfortabel :-) Würde mich über Eure Erfahrung und Ratschläge freuen.
Früher im Büro habe ich das über den Update Manager gemacht. Das ganze lief über den vCenter. Habe darüber alles zentral gesteuert und nur abschließend die ESXier bei Bedarf manuell neugestartet. Da lief der vCenter als VCSA auf einem der ESXer. Ob das immer noch so klappt weiß ich aber nicht.

Edit sagt: Wie Eye-Q geschrieben hat, bei mir war natürlich dediziertes Storage (SAN) und vMotion vorhanden... Der vCenter lief dann natürlich immer auf dem Host der nicht neugestartet wurde.
 
Das geht ja aber normalerweise relativ einfach, indem das aktuellste ESXi-Installationsmedium heruntergeladen und davon gebootet wird, dann sollte die Installationsroutine den installierten ESXi erkennen und ein Update anbieten.
Warum so kompliziert?
1. Update-Zip auf den ESXi hochschieben
2. SSH aktivieren
3. esxcli und Feuer frei.
Update ging bisher immer ohne Wartungsmodus oder VMs runter fahren.
Aber ok, neustarten muss man sowieso.
Allerdings sind die ISOs für den Otto-Normal-Verbraucher nicht immer gleichzeitig mit dem Update verfügbar (oder ich bin zu doof, die VMWare-Webseite zu bedienen). =)
 
Hallo zusammen,

kennt jemand diese Fehlermeldung beim Patchen von ESXi 7.0 (Update 1c Build 17325551) und hat ggf. einen Tipp für mich?
EDIT: Bzw. einen Workaround?

Code:
[root@localhost:~] esxcli network firewall ruleset set -e true -r httpClient
[root@localhost:~] esxcli software profile update -p ESXi-7.0U1d-17551050-standard \
-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
[MetadataDownloadError]
Could not download from depot at https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml, skipping (('https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml', '', '<urlopen error [SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:728)>'))
        url = https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
Please refer to the log file for more details.

Im LOG (/var/log/esxcli.log) steht leider nur dieselbe Meldung, keine weiteren Infos.

Google hat auch nichts brauchbares ausgespuckt (auch nix bei vmware selbst, zumindest nichts Richtung "ssl.c:728") und hier im Forum habe ich ebenfalls nichts gefunden...
 
Hallo zusammen,

kennt jemand diese Fehlermeldung beim Patchen von ESXi 7.0 (Update 1c Build 17325551) und hat ggf. einen Tipp für mich?
EDIT: Bzw. einen Workaround?

Code:
[root@localhost:~] esxcli network firewall ruleset set -e true -r httpClient
[root@localhost:~] esxcli software profile update -p ESXi-7.0U1d-17551050-standard \
-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
[MetadataDownloadError]
Could not download from depot at https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml, skipping (('https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml', '', '<urlopen error [SSL: UNKNOWN_PROTOCOL] unknown protocol (_ssl.c:728)>'))
        url = https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
Please refer to the log file for more details.

Im LOG (/var/log/esxcli.log) steht leider nur dieselbe Meldung, keine weiteren Infos.

Google hat auch nichts brauchbares ausgespuckt (auch nix bei vmware selbst, zumindest nichts Richtung "ssl.c:728") und hier im Forum habe ich ebenfalls nichts gefunden...
Versuchst du hinter einem VPN upzudaten? Das funktioniert bei mir auch öfters nicht, scheint als würde VMWare die IPs zahlreicher VPN Provider zu blocken.
Falls dem so ist, für's Update ohne VPN durchziehen (bzw. bei deinen Netzwerk-Interfaces in ESXI anpassen).

Wenn es immer noch nicht klappt, einmal ohne https versuchen, sondern nur mit http.

Wenn alle Stricke reißen:

Musst dir aber die Links zusammenbasteln...Hierbei auch drauf achten, dass die Adresse nur mit http angegeben wird und nicht mit https.
 
Versuchst du hinter einem VPN upzudaten? Das funktioniert bei mir auch öfters nicht, scheint als würde VMWare die IPs zahlreicher VPN Provider zu blocken.
Falls dem so ist, für's Update ohne VPN durchziehen (bzw. bei deinen Netzwerk-Interfaces in ESXI anpassen).

Wenn es immer noch nicht klappt, einmal ohne https versuchen, sondern nur mit http.

Wenn alle Stricke reißen:

Musst dir aber die Links zusammenbasteln...Hierbei auch drauf achten, dass die Adresse nur mit http angegeben wird und nicht mit https.

Danke für den Hinweis, soeben erneut probiert und heute kommt der o. a. Fehler nicht mehr (?!!? neue public IPv4? ist ein DSL-Home Anschluss, bin jetzt etwas verwirrt...).

Dafür ein neuer Fehler:

Code:
[2021-03-07 13:00:35,425 root ERROR] update failed:  [HardwareError]
 Hardware precheck of profile ESXi-7.0U1d-17551050-standard failed with warnings: <UNSUPPORTED_DEVICES WARNING: This host has unsupported devices [<PciInfo ' [1000:0087 1590:0041]'>]>

Damit dürfte mein HBA gemeint sein:

HBA.JPG


Der funktionierte aber bisher unter 7.0U1c, den habe ich aktuell per passthrough an die StorageVM durchgereicht:

passthru.JPG


Im Compatibility Guide scheint die Unterstützung für ESXi 7 nicht (mehr?) gegeben. Ist wohl besser, ich bleibe mal da wo ich bin, never touch a running system...
 
@zos
Genau oder VMWare hatte zu dem Zeitpunkt Wartungsarbeiten durchgeführt und Downloads waren nicht möglich. Aber lag bei mir eben meist auch an der IP Adresse (VPN bei mir).

Ja, das könnte gut sein. Viele hier nutzen den LSI 2008 Controller für ihre Storage VM's und reichen diesen auch durch.
Durchreichen funktioniert problemlos, aber direkte Nutzung von ESXI funktioniert eben nicht (bspw. ist der RAID-Controller auch als RAID für das ESXI Betriebssystem konfiguriert).

Aus genau diesem Grund hatte ich aber auch von einer Nutzung von ESXI 7 abgesehen. Hatte auch noch keine Vorteile für mich gesehen im Vergleich zu 6.7, das Rad wurde dazwischen sicherlich nicht neu erfunden.
Falls du es also wirklich wagen möchtest, kannst du es tun oder eben auf das altbewährte zurückgreifen. Ich hatte dort erstmal keine Nerven mehr zu, zumal ESXI 6.7 noch Jahrelang Updates bekommen wird.
 
  • Danke
Reaktionen: zos
Ja, das könnte gut sein. Viele hier nutzen den LSI 2008 Controller für ihre Storage VM's und reichen diesen auch durch.
Durchreichen funktioniert problemlos, aber direkte Nutzung von ESXI funktioniert eben nicht (bspw. ist der RAID-Controller auch als RAID für das ESXI Betriebssystem konfiguriert).

Aus genau diesem Grund hatte ich aber auch von einer Nutzung von ESXI 7 abgesehen. Hatte auch noch keine Vorteile für mich gesehen im Vergleich zu 6.7, das Rad wurde dazwischen sicherlich nicht neu erfunden.
Falls du es also wirklich wagen möchtest, kannst du es tun oder eben auf das altbewährte zurückgreifen. Ich hatte dort erstmal keine Nerven mehr zu, zumal ESXI 6.7 noch Jahrelang Updates bekommen wird.
Da Du schreibst "Durchreichen funktioniert problemlos" und wegen diesem Post habe ich es jetzt doch probiert und es hat funktioniert, die StorageVM mit durchgereichtem HBA läuft wie frisch geölt :-)

Nein, nicht Jahrelang Updates...
Dann kann ich mich ja jetzt zurück lehnen 8-)

EDIT: Danke nochmal für Euren Input!
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh