Beiträge von The-real-BOFH

    Hi!


    Gleiches Thema hier. Hab den Server jetzt längere Zeit nicht genutzt, jetzt mal Patches eingespielt und *patsch*: Reparaturmodus...


    Alles sehr wenig zufriedenstellend. Ich könnte mir vorstellen, dass ich nicht der einzige bin, der eine Testumgebung brauchen kann und nicht der Linux-Experte ist. NetCup hat mir gerade geschrieben, dass sie "Nested Virtualization" nur auf KVM supporten, aber weder auf Hyper-V noch auf VMWare,

    Naja, wenn das nicht supported wird, ist das eine kaufmännisch/technische NetCup-Entscheidung, die will ich gar nicht in Frage stellen.


    Ich werde dann aber wohl zum nächsten Termin den Server kündigen. Schade.

    Hurra!!! Es hat funktioniert. Was habe ich dieses Mal anders gemacht?


    1) Ich vor der Installation die "virtio" - Karte auf auf DHCP belassen, also nicht die IP nicht vorab fest konfiguriert. Ggf. hat das neu erstellte virtuelle Interface, dass Hyper-V installiert dann die IP-Adresse dann zugewiesen bekommen, die ich vorab der Karte immer fest zugewiesen hatte. Das eigentliche Interface wird ja vom Hyper-V "totgelegt".


    2) NACHDEM der Server nach der Installation der Hyper-V-Rolle erneut nicht ansprechbar war, habe ich einfach mal die Netzwerkkarte von "virtio" auf "rtl8139" geändert und neu gestartet. Keine Ahnung, was bei dieser Karte nun anders ist. Nach der Installation habe ich Adresse auf dem neuen Interface nun fest zugewiesen und der Server läuft (noch). Mal sehen, ob es so bleibt...


    3) Nach den Installation habe ich im Hyper-V - Manager das neue virtuelle Interface (eigentlich ein virtual Switch) als "extern" (allow Management Operating System to share this adapter) geflaggt und einen neuen "internen Switch" konfiguriert, auf dem dann meine Gast-Systeme laufen.


    pasted-from-clipboard.png

    Hi!


    Nun, das "Hyper-V add-on" ist das Windows Gegenstück zum KVM auf Windows. Was meinst Du mit "2013" - Server?

    Meinst Du Windows Server 2012, 2012 R2, 2016 oder 2019? Wenn Ihr das nicht nutzt, womit virtualisiert Ihr denn "nested"? KVM? ESXi? XEN?


    Ich habe das Problem bei nur einem Host (ich hab nur einen), allerdings ein RS4000.


    Für mich stellt sich das Bild wie unten stehend dar - mit ein paar Änderungen (von unten nach oben):

    - Der "Azure Hardware - Layer" ist das Blech bei Netcup.

    - Die dunkelblaue Schicht ist der KVM, das OS des Linux - Wirts wird bei KVM nicht virtualisiert, also gibt es den Block "Azure Root OS Server 2016" nicht.

    - Das Mittelblaue ist dann mein geplanter Hyper-V Host und

    - das hellblaue sind dann die Maschinen meiner geplanten Testumgebung (Windows, Linux, whatever).


    pasted-from-clipboard.png

    Mhhhhh, natürlich war ich auf eine - wenn auch vorsichtig formulierte, aber dennoch leicht abschätzige Äußerung gefasst.


    Nein, ich bin nicht "nur" theoretisch unterwegs und praktisch auch nicht erst seit "gestern". Zugegeben, ich habe mehr Erfahrung mit Microsoft-Produkten, als mit Linux-basierenden, wie scheinbar die meisten hier im Forum, aber das ist für diesen Fall ja (hoffentlich) nicht ganz so relevant. ;)


    Ich bin allerdings auch Lösungsorientiert. Siehst Du denn eine andere Möglichkeit, als das Netcup zumindest grundlegende Dinge prüft, bevor sie Mailserver dulden? Damit wären zumindest die ganz groben Schnitzer zu vermeiden. Zu Anfang täte es ja schon ein "How-to" mit den oben erwähnten Einstellungen (SPF & Co.), damit wäre zumindest die grundsätzliche "Reputation" des MTA sichergestellt.


    Was die Nutzer betrifft, gebe ich Dir recht, da ist kein Kraut gegen gewachsen und ja, dann wird ein einzelnes Postfach auch gerne mal als "Relay" missbraucht. Dagegen hilft wiederum nur, eine entsprechende Passwort-Richtlinie und selbst dann werden weiterhin Postfächer gehackt, weil User mit ihren Passworten und auch mit Ihren PCs nicht "vernünftig" umgehen, ist mir auch klar.


    Klar ist aber auch, dass "die Großen" auch weiterhin ganze Blöcke von Adressen statt einzelner sperren werden, weil es ihnen die Arbeit erleichtert.


    Und jetzt?


    Was wäre denn eine bessere Lösung? Ich lerne immer gerne dazu...

    Ganz genau! Das wiederum kann man schon ich in der Verantwortung von Netcup verorten. Es muss aus meiner Sicht eine Qualitätssicherung durch Netcup stattfinden, bevor eine Mailserver eines Kunden in Betrieb gehen darf - allein schon deshalb, weil es am Ende alle Kunden im gleich Netzsegment betrifft, wenn "ein schwarzes Schaf" seinen Server nicht ordentlich konfiguriert hat.

    Hallo zusammen!


    Aus meiner Sicht ist Netcup nur für die von denen selbst gemanagten Email-Domains selbst verantwortlich.


    Wenn jemand einen Mailserver selbst betreibt, sollte er/sie das inhaltlich / handwerklich auch selbst nach aktuellem Stand der Technik können und nicht nur Amateurhaft / Laienhaft - ohne das ich damit jemand speziell meine (bevor gleich ein Sturm der Entrüstung über mich hineinbricht). ;)

    Netcup ist nicht dafür verantwortlich, wenn jemand seinen Mailserver technisch nicht im Griff hat, ebenso wenig wie Microsoft. Microsoft ist dafür verantwortlich, dass seine Kunden aufgrund fehlerhafter / unvollständiger Konfiguration nicht Massen von Spam zugeschickt bekommen - das ist deren Verantwortung.


    Die Spamfilter bei allen bekannten Blocklist-Providern funktionieren alle ähnlich und inzwischen meistens auf Basis einer gesamthaften Reputation eines Mailversenders. Um diese herzustellen sollten man zum einen darauf achten, dass der eigene Server nicht als "open relay" Server missbraucht werden kann, weil z.B. SMTP ohne Authentifizierung und von jeder IP annimmt und "blind" versendet. Darüber hinaus kann man durch entsprechende Einträge im DNS dafür sorgen, dass die eigenen Mailserver eine entsprechende Reputation erhalten bzw. behalten, Stichwort SPF, DKIM, DMARC: https://www.sc-networks.de/blo…egen-spammer-tun-koennen/

    Das alles ist kein "Hexenwerk" und es hilft, zum einen von Blocklists wieder herunterzukommen und auch gar nicht erst wieder drauf zu landen, ebenso macht es ggf. Sinn, DNSSec auf seinem Mailserver zum implementieren, auch kein neues Feature - macht aber eben etwas mehr Arbeit.


    Aus Sicht von Netcup würde es helfen, wenn die ihren Kunden ein "how-to" bereitstellen und auch vor der Freischaltung eines neuen Mailservers prüfen, ob dessen Konfiguration sicher ist. Anderenfalls trifft es eben nicht nur den "Bösewicht", sondern auch die im selben Netz, die ihre Mailserver gut im Griff haben, weil die "Großen" wie Microsoft sich das Leben eben leicht machen und gleich das ganze IP-Segment sperren. Letzteres kann ich bis zu einem gewissen Grad auch nachvollziehen, weil es aus Sicht von Microsoft ein sehr dynamisches und umfangreiches "Massengeschäft" ist.


    Just my two cents…


    The-real-BOFH

    Ok, das klingt schonmal, als wäre es ein guter "Plan B". Bis dato bin ich aber (noch) nicht bereit, mich geschlagen zu geben. Wenn also jemand Erfahrungen mit einem "Nested Hyper-V" hat, der auf KVM läuft, wäre ich sehr dankbar, wenn er/sie diese teilen könnte.

    Hi!


    Danke für die Antwort. Die Info mit dem Rettungssystem hatte ich noch nicht, "Coreinfo" kenne ich natürlich. Coreinfo und auch der Output aus dem Rettungssystem zeigt mir natürlich nur die Parameter aus dem Gastsystem an, dass dann mal der L1-Hypervisor werden soll, nicht die des Hosts, der von Netcup auf "Blech" als "L0" Hypervisor aufgesetzt wurde.

    Hat denn jemand mal einen "ESXi" oder "einen "Qemu/KVM" als Gastsystem zum laufen bekommen - und kann mir auch nicht sagen, wie?

    Hallo zusammen!


    Bevor ich meinen RS 4000 gebucht habe, habe ich mich umfangreich darüber informiert, ob dass, was ich vorhabe funktionieren könnte: Einen Hyper-V Server auf Basis von Windows Server 2019 zu installieren. In den Dokumentationen, die ich gefunden habe, hatten das zwar alle nur mit Windows Server 2016 Hyper-V zum laufen bekommen, aber ich dachte mir: Ok, es wird wohl nicht "schlechter" geworden sein. Allen, die das gemacht haben, war jedoch gemeinsam, dass sie selbst auch Zugriff auf den L0-Hypervisor - also den Bare-Metal Host hatten und somit direkt auf den KVM Zugriff hatten.

    Eins noch vorab: Ich habe wenig bis keine Erfahrung mit Linux, bin aber schon sehr viele Jahre auf der "dunklen Seite der Macht". also im Windows - Umfeld unterwegs in der IT.


    Aaaalso: Was habe ich gemacht?


    Ich habe mir für die sechs Kerne meines RS 4000 VMX freischalten lassen. Danach habe ich einen Windows 2019 Server aufgesetzt. (Alles zwei Mal inzwischen). Bis dahin war alles gut. Ich habe mir auch vorher angeschaut, mit welchen virtuellen Netzwerkkarten (virtio, e1000) und Platten (IDE, SCSI. virtio) die besten Erfahrungen gemacht wurden. Der Server lief bis dahin sauber, das Event-Log war blütenrein, alle Updates eingespielt, RDP-Zugriff freigeschaltet, alles prima bis dahin. Dann habe die Hyper-V-Rolle installiert (mit Nutzung der virtuellen Netzwerkkarte (virtio) und neu gestartet. Von da an ging nichts mehr.

    Beim ersten Mal antwortete der Server auf PING nach dem Neustart, danach habe ich versucht, per RDP zuzugreifen, danach kam kein Echo mehr. Auch in der VNC-Konsole reagierte der Server nicht mehr. Ok, dachte ich, dann war das wohl keine gute Idee, die virtuelle Netzwerkkarte für den RDP-Zugriff und Hyper-V zu nutzen...

    Gesagt, getan, Server neu aufgesetzt, dieses Mal mit der "e1000" virtuellen Netzwerkkarte. Dieses Mal habe ich auch beim Installieren des Hyper-V-Servers die Karte nicht ausgewählt und hatte vor, nach der Installation erst einmal mit einem "rein internen" virtuellen Netzwerk-Switch anzufangen. Leider kam es nicht dazu. Nach dem Neustart lief der Server zwar und ich konnte mich auch sowohl mittels VNC-Konsole als auch RDP verbinden, jedoch nur sehr kurz, nach dem Start des Server-Managers nach der Anmeldung reagierte der Server nicht mehr, auch PING bekam kein Echo. Ich hab dann verschiedenes versucht über das SCP: Virtuelle Platte von "virtio" auf SCSI umgestellt, virtuelle Netzwerkkarte auf "virtio" umgestellt - immer das gleich Bild: Kurz nach der Anmeldung (ich vermute, wenn der Hyper-V-Service startet) reagiert das System plötzlich nicht mehr....alle Kerne laufen auf 100% CPU-Last.


    Leider habe ich keinen Zugriff auf den darunter liegenden KVM (von dem ich ohnehin nicht viel verstehe) und daher kann ich auch nicht sehen, was konfiguriert wurde, also "VMX freigeschaltet" wurde. Ich vermute jedoch, dass zum einen der Windows Server 2019 Hyper-V sich eben doch anders verhält als der vom Windows Server 2016 (s.o.), zum anderen habe ich das ein oder andere darüber gelesen, was andere dort konfiguriert haben, die das auch versucht haben (z.B. "Host-pass-through" setzen).


    Hat irgendjemand hier das schon einmal erfolgreich umsetzen können? Hat jemand vom Support evtl. eine Idee, was man beim KVM noch ändern könnte, um das zum laufen zu bekommen? Ich kann mir vorstellen, dass der/die ein oder andere diese Möglichkeit auch nutzen würde - und sei es mit Windows 10 -, um wie ich seine Testumgebung zu virtualisieren.


    Vielen Dank im Voraus für Eure Antworten und Unterstützung. :thumbup:


    Schönes Wochenende und bleibt gesund...! :)