ESX / ESXi - Hilfethread

Erst mal hätte ich eine Frage zu einer Konfiguration. Auf jedem der installierten hosts ist jeweils der Speicherpfad 2x erreichbar.
1x über direkt 10 GBit - und einmal über Backup 2 GBbit.

Wie erreichst du 2GBit?
Ein paar mehr Infos zum Aufbau wären hilfreich... ;)

Im Grunde sollte normal für beide iSCSI Pfade je ein KernelPort existieren, diesem ist je ein phyischer Adapter zugewiesen. Diese beiden KernelPorts weist man dann dem iSCSI Initiator zu und bindet die Ziel-Storage IPs auf diesen.
Die Verwaltung der Pfade läuft dann direkt in den Settings der jeweiligen Volumes... Optimalerweise sollte hier dann der 10GBit Pfad Verwendung finden.

Sonst habe ich nämlich seit kurzem auch am Storage etwas Performance Probleme, die
sich so z.b. in zwei esxi hosts zeigen:

Anhang anzeigen 241330

Anhang anzeigen 241331

Jeder der beiden esxi hosts verfügt über 2x 10 gbit nic, welche mit 2 Storages verbunden ist. Die Storages syncen selbstständig die LUN/das Volume.

Hat jemand vergleichswerte? Mir kommen die Werte aber mal richtig schlecht vor :(

Ich sehe da grundsätzlich erstmal keine Probleme...
Falls du aber die Latenzunterschiede meinst, dann musst du definitiv mehr Infos geben. Die Latenz steigt bei Zugriffen logischerweise an.
Für mich sieht das im Moment nach den beiden Bildern so aus, als ob der eine ESXi einfach (deutlich) mehr Storagelast erzeugt als der andere... Somit ist die Latenz zum Storage auch schlechter.
Was aber grundsätzlich nicht unbedingt ein Problem ist, weil vollkommen logisches Verhalten.

Auch wären ein paar Bildchen der Performancegraphen in der erweiterten Ansicht vorteilhaft, denn dort sieht man entgegen deiner Bilder auch, welches LUN bzw. welches Ziel gerade betroffen ist. Das ganze kann/muss man dann gegen die Belastung der VMs halten um zu sehen, was da los ist.

Fakt ist, VMs erzeugen vermehrt massiven Random Access auf das Storage. Was unter Umständen massive Probleme hervorrufen kann. Nur aktuell lässt sich da pauschal nix empfehlen, weil nicht klar ist, was das Problem sein könnte. Von simpler Überlast über Netzwerkperformanceprobleme bis hin zu Geschichten wie schnell bereitgestellten VMDK Files für die VMs -> und daraus erzeuge mehr Last.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Gibt es eigentlich tatsächlich keinen nativen vSphere Client für Linux oder ist der nur so schwer zu finden?
 
Gibt es nicht, wird es auch sehr wahrscheinlich (=100% sicher) nie geben.
 
Was spricht dagegen?

Das die Konsole angeblich in der V6 ganz eingestampft werden soll und man sich nur noch über die Weboberfläche bewegen soll/kann...
Wie das dann mit Single ESXi Hosts von statten geht, ist aber aktuell noch ungeklärt.
Zumindest hab ich das mal irgendwo aufgeschnappt.
 
Ok, gegen eine "ordentliche" Weboberfläche kann man ja auch erstmal nichts einwenden. Zumal es ja auch noch die Konsole gibt. Es darf halt nur keine Funktion verloren gehen :)
 
Mir wär ne anständige Weboberfläche in mancherlei Hinsicht sogar lieber als der vSphere Client von dem man dann für jede Version von ESXi / VCenter die man managen will wieder genau die passende Version installiert sein muss. Als besonders schnell empfinde ich ihn außerdem auch nicht.
Leider ist der vSphere Web Client von einer anständigen Weboberfläche nach dem wenigen was ich bisher drüber sagen kann auch noch weit entfernt...
 
Das Problem beim Webclient ist die Geschwindigkeit und dass er komplett anders aufgebaut ist wie der native Client. Darum werden wohl die alteingesessen Admins wohl erst wechseln wenn sie wechseln müssen ;)
 
So schauts aus...
Der Webclient funktioniert zwar, aber der Speed ist alles andere als rosig... Und der Ressourcenverbrauch auf dem VCenter ist exorbitant, das geht über keine Kuhhaut.
Und das bezieht sich alles auf mal hier und dort ne aktive Session. Wie sich das Dingens verhält wenn man da mit 10+ aktiven Sessions gleichzeitig aktiv ist, weis ich nicht, ich glaube aber, dann muss man wohl fest mit minimum 16GB RAM am VCenter Server kalkulieren.

Vorteil ist aber in jedemfall, man kann den Spaß schön von public nutzen ohne VPN und Co. Und für public access geht es sogar vergleichsweise fluffig. Aber das liegt wohl eher daran, das der Speed im allgemeinen sehr mau ist.

Ich muss aber auch sagen, ich bin ziemlich erstaunt, wie "gut" der VCenter 5.1 mittlerweile rennt. Wir haben vor ner Weile den SQL Part auf ne seperate Kiste ausgelagert mit nem 2012er SQL (4 Cores, 8GB RAM, Raid 10 15k SAS Platten)
Seit dem kann man mit dem Ding sogar halbwegs gut arbeiten. Definitiv kein Vergleich zu vorher mit der 2008 R2 SQL Express Install in der VCenter Maschine...
 
Zuletzt bearbeitet:
Du würdest das vCenter WebGUI von aussen direkt ohne VPN erreichbar machen? o_O
Aber nicht in einer produktiven Umgebung, oder?
 
Was passiert eigentlich genau wenn ich eine VM im VSphere Client in den Wartungsmodus setze?
Und sollte ich eine VM in den Wartungsmodus setzen wenn ich sie auf einen anderen Server umziehen möchte?


VG

PS: Ich finde Weboberflächen zwar auch ziemlich smart, aber sie haben für die Usability den riesen Nachteil dass der Rechtsklick einfach wegfällt und damit die Übersicht deutlich leidet (ich erinnere mich noch an die ältere Weboberfläche von der kostenfreien VMware Server 2)
 
Zuletzt bearbeitet:
Das mit dem Rechtsklick -> Kontextmenü wär schon umsetzbar im Browser, jedenfalls schlußfolgere ich das daraus dass Dropbox das auch hinbekommt.
 
Klar geht das mit dem Kontextmenu, hab ich selbst schon bei einer eigenen Page verwendet. Man muss nur das Rechtsklick event abfangen und dann das Menu passend generieren / sichtbar machen.
Macht Google Maps ja auch so.
 
Du würdest das vCenter WebGUI von aussen direkt ohne VPN erreichbar machen? o_O
Aber nicht in einer produktiven Umgebung, oder?

Es ist HTTPS ;) -> spricht im Grunde nix gegen. Oder wo siehst du dort ein Problem?
Bei uns läuft zwar aktuell nicht die produktive Umgebung nach public, meine Testumgebung hatte ich aber von Zuhause aus erreichbar...
Aktuell habe ich aber nicht die Zeit, das ganze mal über unseren TMG zu schieben und zu testen, ob das überhaupt lüppt :fresse:

Was passiert eigentlich genau wenn ich eine VM im VSphere Client in den Wartungsmodus setze?
Und sollte ich eine VM in den Wartungsmodus setzen wenn ich sie auf einen anderen Server umziehen möchte?

Wie versetzt du eine VM in den Wartungsmodus?
Das geht soweit ich weis gar nicht... Du kannst den Host in den Wartungsmodus versetzen... Aber wenn du das machst, sagt er dir auch gleich, was das für Auswirkungen hat ;)

PS: Ich finde Weboberflächen zwar auch ziemlich smart, aber sie haben für die Usability den riesen Nachteil dass der Rechtsklick einfach wegfällt und damit die Übersicht deutlich leidet (ich erinnere mich noch an die ältere Weboberfläche von der kostenfreien VMware Server 2)

Zumindest der VMware WebClient agiert auch auf Rechtsklick... Alles eine Frage der Programmierung ;)
 
Zuletzt bearbeitet:
Es ist HTTPS ;) -> spricht im Grunde nix gegen. Oder wo siehst du dort ein Problem?
Bei uns läuft zwar aktuell nicht die produktive Umgebung nach public, meine Testumgebung hatte ich aber von Zuhause aus erreichbar...
Aktuell habe ich aber nicht die Zeit, das ganze mal über unseren TMG zu schieben und zu testen, ob das überhaupt lüppt :fresse:

Äh... dass man das jetzt wirklich erklären muss, macht mich echt betroffen.
 
Der Sinn von VPN ist in dem Fall nicht die Vertraulichkeit, die HTTPS auch hat, sondern die Zugriffskontrolle. Du weißt ja nicht, welche schönen Lücken die ganzen Dienste haben, die auf den zig Ports laufen. Du kannst zwar den ESXi-Paketfilter bemühen, um Zugriff auf bestimmte Adressen zu beschränken, aber IP-Adressen sind nie geeignet für Auth. Dass du ohne Passwort nicht in den Server kommst, heißt ja noch lange nicht, dass da nicht irgendwelche pre-auth Lücken existieren; davon geht man immer erstmal aus und dann ist die einzige Absicherung ein VPN.

Das ist Sicherheits-Einmaleins.
 
Nicht wirklich... Denn es gibt so oder so genügend Dienste die public verfügbar sind. Wenn es danach geht, kann/darf man gar nix im Netz verfügbar machen...

Und wenn, dann schleift man sowas über einen FrontEnd Server, der in ner DMZ steht und optimalerweise auch nix weiter macht, sondern nur den WebClient bereit stellt. ;)
Mal ganz davon von, das klingt alles so, als wären VPN Lösungen so extrem sicher... Solche potentiellen Schwachstellen wie du sie beschreibst, existieren nämlich immer, wenn du irgendwas public verfügbar machst. !uch bei diversen VPN Lösungen/Anbietern/Hardware! -> der Effekt ist absolut identisch. Zugriffskontrolle ist genau so wenig gegeben ;) Denn das ganze auf IPs/MACs oder worauf auch immer zu Restriktieren ist dann ebenso wenig zielführend.

Unterm Strich ist/bleibt es alles ein Kompromis aus möglicher Sicherheit und Nutzbarkeit. Zurammeln kann man immer irgendwie oder irgendwas, ob es dann noch nutzbar ist, steht auf nem anderen Blatt.
 
Zuletzt bearbeitet:
Nicht wirklich... Denn es gibt so oder so genügend Dienste die public verfügbar sind. Wenn es danach geht, kann/darf man gar nix im Netz verfügbar machen...
"Es gibt Dienste, die public sein müssen, weil das der Zweck des Servers ist, also kann alles public sein" Komisches Argument.

Mal ganz davon von, das klingt alles so, als wären VPN Lösungen so extrem sicher... Solche potentiellen Schwachstellen wie du sie beschreibst, existieren nämlich auch bei diversen VPN Lösungen/Anbietern/Hardware. -> der Effekt ist absolut identisch. Schlimmer noch, je nach Konfiguration bekommt der potentielle Angreifer bei Infiltrierung der VPN Lösung Zugriff auf nahezu alles anstatt sich nur auf dem FrontEnd Server für den WebClient auszulassen...

Unterm Strich ist/bleibt es alles ein Kompromis aus möglicher Sicherheit und Nutzbarkeit. Zurammeln kann man immer irgendwie oder irgendwas, ob es dann noch nutzbar ist, steht auf nem anderen Blatt.
Ein VPN hat ja wohl wesentlicher weniger Code und Angriffsfläche als dieses massive Konglomerat an Diensten, die ein ESXi so rumschleppt.

Dein Argument besteht also im Wesentlichen aus "Schultern zucken, bringt eh alles nix, lassen wirs gleich offen". Und dann wundert man sich über die andauernden Meldungen über Datenklau, die bösen Hacker sind schuld und die Strafen müssen erhöht werden, statt die Spaßadmins einfach mal ihren Job machen.
 
Wie versetzt du eine VM in den Wartungsmodus?
Das geht soweit ich weis gar nicht... Du kannst den Host in den Wartungsmodus versetzen... Aber wenn du das machst, sagt er dir auch gleich, was das für Auswirkungen hat ;)

Ich muss dir mal wieder Recht geben :hail:

Zitat: "Ein Host im Wartungsmodus führt keine Funktionen einer virtuellen Maschine aus, auch keine Bereitstellungsaktivitäten der virtuellen Maschine"

Aber was heißt das nun genau? Ist doch klar dass keine Funktionen einer virtuellen Maschine ausgeführt werden, wenn diese heruntergefahren ist.

Sollte man nun bevor man eine VM verschiebt den Host in den Wartungsmodus setzen? Oder dient der Wartungsmodus lediglich um ESXi zu aktualisieren?


Danke und Grüße!
 
Ganz ehrlich: Ich habe bisher alles ohne Wartungsmodus gemacht. Ob das falsch war weiss ich nicht, habe jedoch noch keine Probleme gehabt so.
 
Naja bei einem single ESXi ist das mit Sicherheit auch nicht die Welt, aber in einem (DRS)Cluster kann das unpraktisch sein wenn man gerade was daran machen möchte und dann Maschinen rübergeschoben werden automatisch...
 
Genau. So wie ich es verstehe, dient das einfach dazu, dass der Host kein Ziel mehr für irgendwelche automatischen Migrationen durch Lastverteilungen usw. ist.
 
"Es gibt Dienste, die public sein müssen, weil das der Zweck des Servers ist, also kann alles public sein" Komisches Argument.

Nein, ich denke, wir reden aneinander vorbei, denn du hast den Sinn meiner Aussage nicht verstanden...
Natürlich gibt es Dienste, die für public geschaffen sind, keine Frage... Nur wenn man mit der gleichen Argumentation rangeht, wie du sie getätigt hast, dann muss man folgerichtig auch bei allen anderen Diensten beim Thema Sicherheit so Argumentieren. Und da gehört eine VPN Lösung ebenso dazu. Denn diese macht nix anderes, als einen Dienst im INet bereit zu stellen. Und du als Betreiber musst dich zwingend darauf verlassen können, dass diese Lösung mehr oder weniger sicher ist.
Scheinbar bist du dir nach den Argumenten sicher, dass die VPN Lösung dies sein muss, beim VMware WebClient hingegen nicht. Und das ist Messen mit zweierlei Maß. Bei einer Lösung zweifelst du, bei der anderen bist du dir hingegen sicher. Dennoch kennst du in beiden Lösungen NULL! Codezeilen. Also reine Bauchgefühlargumentation ohne trivialen Hintergrund.

Ein VPN hat ja wohl wesentlicher weniger Code und Angriffsfläche als dieses massive Konglomerat an Diensten, die ein ESXi so rumschleppt.

Dein Argument besteht also im Wesentlichen aus "Schultern zucken, bringt eh alles nix, lassen wirs gleich offen". Und dann wundert man sich über die andauernden Meldungen über Datenklau, die bösen Hacker sind schuld und die Strafen müssen erhöht werden, statt die Spaßadmins einfach mal ihren Job machen.

Der erste Part ist quatsch... Es hat nix mit der Anzahl der Codezeilen zu tun. Ein hochkomplexes Programm kann weitaus sicherer sein, als ein nur wenige Codezeilen enthaltenes Anderes, wo aber ein fataler Bug/Sicherheitslücke reinprogrammiert wurde. Auch wenn natürlich mit steigender Anzahl an Codezeilen das Risiko potentiell höher wird, heist das aber lange nicht, das dies pauschal unsicherer ist. Im Gegenteil, es hängt massiv davon ab, wie sich der Programmierer darauf versteht. -> und wie die Software mit Sicherheitspatches bedient wird.


Zum anderen, woher interpretierst du das bitte?
Ich sagte: "Und wenn, dann schleift man sowas über einen FrontEnd Server, der in ner DMZ steht und optimalerweise auch nix weiter macht, sondern nur den WebClient bereit stellt."
Die Begriffe sollten dir denke ich geläufig sein, wenn du dich in der Lage siehst, dies und jenes als Sicher/Unsicher einzuschätzen :wink:
Von "lassen wirs gleich offen" kann also nicht die Rede sein...

In unserem Fall würde eine Webveröffentlichung wenn dann über ein TMG Server laufen. Gegen diesen muss man sich via Useraccount/PW authentifizieren. Das läuft über https und ist somit vollverschlüsselt -> erst dann bekommt man seine WebClient Session, diese läuft auf dem WebClient Serverdienst, der auf ner Kiste stehend in der DMZ tuckert und wo man sich erneut gegen den SSO Dienst vom VCenter authentifizieren muss (wobei noch nicht 100% klar ist, ob man das ggf. weiterreichen kann)
Das gleiche Verfahren nutzt man beispielsweise bei der Webveröffentlichung von Sharepoint, Exchange OWA oder weis der Teufel welchen anderen Sachen... Dort gibts den gleichen Aufbau von Access Gateway (TMG/UAG), FrontEnd Server (möglicherweise in der DMZ) und BackEnd Server intern im LAN.

Die einzige Angriffsfläche, die hier besteht, ist die Infiltrierung des TMG/UAG Servers bzw. anderen Lösungen, die als reverse Proxy bzw. SSL Gateway fungieren. Nur sind diese Server exakt für diesen Einsatz geschaffen... -> somit kannst du auch mit den selben Sicherheitsanforderungen an diese rantreten, wie sie deine VPN Lösung von dir bekommt.

So und jetzt nochmal die Frage, was für triviale Gründe kannst du aufzeigen, die den Einsatz des WebClients via public Access, https gesichert, gegen TMG Authentifiziert, als unsicher abtun würden!? :wink:

Aber was heißt das nun genau? Ist doch klar dass keine Funktionen einer virtuellen Maschine ausgeführt werden, wenn diese heruntergefahren ist.

Sollte man nun bevor man eine VM verschiebt den Host in den Wartungsmodus setzen? Oder dient der Wartungsmodus lediglich um ESXi zu aktualisieren?

Ne, anders... Die VM(s) laufen ja optimalerweise weiter. Denn man verwendet die ESXi Server ja idR in einem Clusterverbund. Somit werden die VMs schön von Host zu Host geschoben...
Musst du nun Wartungsarbeiten an einem Host durchführen (beispielsweise das Einspielen von Patches, Ändern von irgendwelchen Einstellungen oder auch beispielsweise das Erweitern des Hosts mit Hardware oder Software), versetzt du den Host in den Wartungsmodus.
Im Wartungsmodus werden die Clusterdienste beendet und vorher alle laufenden VMs auf andere Hosts im Cluster migriert. -> die VMs laufen somit alle samt weiter, wärend dieser eine Host eben nur noch die Basisfunktionalitäten ausführt. -> und man kann ihn danach so verändern, wie man es wünscht.

Zum anderen, nein... Wenn du eine VM verschiebst, muss der Host nicht in den Wartungsmodus. Was auch gar nicht gehen würde. Denn wenn du den Wartungsmodus in einem Clusterverbund aktivierst, werden automatisch alle VMs verschoben, die dieser Host bereit stellt.
 
Zuletzt bearbeitet:
So und jetzt nochmal die Frage, was für triviale Gründe kannst du aufzeigen, die den Einsatz des WebClients via public Access, https gesichert, gegen TMG Authentifiziert, als unsicher abtun würden!? :wink:

Wenn du dich mal entscheiden könntest, ob wir jetzt von Web-Client direkt am Netz oder irgendwelchen TMG-Geschichten reden (die ich im Übrigen auch für viel zu komplex halte um sicher zu sein), dann wäre es leichter. Ausgangspunkt der Diskussion war Web-Client direkt am Netz.

Ansonsten halte ich einen OpenSource-VPN-Server wie OpenVPN, der mit richtiger Kernel-/Userspace-Trennung arbeitet und auf einem gehärteten System läuft, oder auch eine jahrelang "auditete" IPsec-Implementierung, hinter denen dann eine Firewall den Traffic nochmals einschränkt, für die beste Lösung, anstatt einen obskuren ClosedSource-Codeball mit einem zweiten obskuren ClosedSource-Codeball aka TMG zu "sichern".

Bei einer Kompromittierung des VPN hat man außerdem keineswegs automatisch Zugriff auf alles. Man kann eine OpenVPN-Installation sehr wohl so einsperren, dass selbst wenn man den OpenVPN-daemon kompromittiert, man von dieser Kiste aus keinen Netzwerktraffic starten kann. In den Source kann man auch gucken und dann ist ja noch die Firewall zwischen dem VPN-Endpunkt und den Diensten.

Wir scheinen aus unterschiedlichen Zeiten zu stammen. Ich weiß lieber genau, was abläuft, anstatt in einer bunten Oberfläche mir was zurechtzuklicken und zu glauben, das wäre halbwegs sicher.
 
Zuletzt bearbeitet:
Ne, anders... Die VM(s) laufen ja optimalerweise weiter. Denn man verwendet die ESXi Server ja idR in einem Clusterverbund. Somit werden die VMs schön von Host zu Host geschoben...
Musst du nun Wartungsarbeiten an einem Host durchführen (beispielsweise das Einspielen von Patches, Ändern von irgendwelchen Einstellungen oder auch beispielsweise das Erweitern des Hosts mit Hardware oder Software), versetzt du den Host in den Wartungsmodus.
Im Wartungsmodus werden die Clusterdienste beendet und vorher alle laufenden VMs auf andere Hosts im Cluster migriert. -> die VMs laufen somit alle samt weiter, wärend dieser eine Host eben nur noch die Basisfunktionalitäten ausführt. -> und man kann ihn danach so verändern, wie man es wünscht.

Zum anderen, nein... Wenn du eine VM verschiebst, muss der Host nicht in den Wartungsmodus. Was auch gar nicht gehen würde. Denn wenn du den Wartungsmodus in einem Clusterverbund aktivierst, werden automatisch alle VMs verschoben, die dieser Host bereit stellt.

Vielen Dank für die ausführliche und sehr verständliche Antwort.

Ich bin echt begeistert wie gut der Thread (nicht zuletzt wegen fdsonne) hier ist!

VG
 
Kleiner Spaß am Rande:
Letzte Woche mit meinen ehemaligen Arbeitskollegen beim alten Arbeitgeber gequatscht. Denen hat vor 2-3 Wochen einer das HP iLO das an den Servern im Rechenzentrum hängt (öffentliche IP direkt im Netz da auf der Kiste die Firewall läuft) "geöffnet" und hat dann aber netterweise "nur" die Kiste mal übers iLO runtergefahren.
 
Kleiner Spaß am Rande:
Letzte Woche mit meinen ehemaligen Arbeitskollegen beim alten Arbeitgeber gequatscht. Denen hat vor 2-3 Wochen einer das HP iLO das an den Servern im Rechenzentrum hängt (öffentliche IP direkt im Netz da auf der Kiste die Firewall läuft) "geöffnet" und hat dann aber netterweise "nur" die Kiste mal übers iLO runtergefahren.

Das glaubt ihr :)
 
Ok, gegen eine "ordentliche" Weboberfläche kann man ja auch erstmal nichts einwenden. Zumal es ja auch noch die Konsole gibt. Es darf halt nur keine Funktion verloren gehen

Da stimm ich mal zu, allerdings muss da noch einiges dran gearbeitet werden, wenn ich mir da z.B. die Ausgabe von Fehlermeldungen anschaue, die sich teils deutlich von denen im Client unterscheiden und nicht unbedingt auf den eigentlichen Grund des Fehlers verweisen.

Btw: Hat noch jemand das Problem, dass der Webclient (im meinem Fall von vCenter 5.0) in Kombi mit Firefox 22 den Browser nach dem Durchlauf des Ladebalkens zum einfrieren bringt. Mit Firefox 21 liefs noch. Wobei ich allerdings nicht weiß, obs an VMware oder Firefox liegt...

Aber was heißt das nun genau? Ist doch klar dass keine Funktionen einer virtuellen Maschine ausgeführt werden, wenn diese heruntergefahren ist.

Sollte man nun bevor man eine VM verschiebt den Host in den Wartungsmodus setzen? Oder dient der Wartungsmodus lediglich um ESXi zu aktualisieren?

Naja, selbst wenn eine VM runtergefahren ist, kannst du die z.B immer noch via vMotion auf nen anderen Host schieben. Ist der Host aber im Wartungsmodus, kannst du da keine VM drauf schieben.
Der Wartungsmodus an sich wird zum Verschieben via vMotion nicht benötigt.
 
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