NilsK

Moin, ah, da hab ich neulich einen Trailer für gesehen, aber ohne Bing komm ich nicht auf den Titel, und das gildet ja nicht. Gruß, Nils

Moin, damit verlassen wir aber den sachlichen Bereich. Wir könnten hier jetzt auch Beispiele aufzählen, in denen VMwares Marketing sich unsympathisch aufgeführt hat. Zur Erkenntnis trägt das nichts bei. Gruß, Nils

Moin, na, jetzt suchst du aber verzweifelt nach Argumenten, oder? Wie oft kommt ein Release-Wechsel vor? Eben. Ja, von 2008 R2 auf 2012 kommt man nicht ohne Downtime, das muss man einplanen. In der Folgeversion wird das dank Shared-Nothing Live Migration wahrscheinlich nicht der Fall sein. (Übrigens gab es das Feature zuerst bei Hyper-V.) Und ja, bei vSphere geht das ohne Downtime. Ist damit ausgeschlossen, dass in Folgeversionen VMware Funktionen integrieren könnte, die dann eben doch eine Downtime bei der Migration erfordern? Also mal bitte auf dem Teppich bleiben. Wenn wir lang genug suchen, werden wir für jedes System Nachteile finden. Die Frage ist doch, was ich als Kunde in einer bestimmten Situation brauche, und da fallen viele prinzipiell vorhandene Nachteile (oder auch Vorteile) dann vielleicht gar nicht ins Gewicht. Hm, das klingt jetzt aber, als hättest du da was missverstanden. Live Migration ist kein Prozessorfeature. Hast du das jetzt mit AMD Pacifica verwechselt? Wobei gerade Linuxer traditionell eher auf Xen setzen. (Oder auf KVM und Konsorten.) Wenn wir mal eins der größten RZ weltweit außer Acht lassen. :D Sonst ist der Hinweis durchaus korrekt. Und es ist auch unbestritten: An vielen Stellen hat VMware immer noch technisch die Nase vorn, gerade an solchen Stellen, die man in richtig komplexen Umgebungen braucht. Ist ja auch richtig prima Software. Die Frage, die wir hier ja leider gebetsmühlenartig wiederholen müssen, ist aber immer die nach den konkreten Anforderungen. Und da stellt man eben durchaus häufig fest, dass der Kunde die Features der Enterprise-Plus-Fassung echt geil findet, aber schlicht nicht braucht - und dass das, was er braucht, problemlos mit den Bordmitteln von Hyper-V erreichbar ist. Wenn er trotzdem mehrere tausend Euro für vSphere ausgeben will, bin ich der Letzte, der ihn daran hindert. ;) Gruß, Nils

Moin, und immer noch vergleichst du Äpfel mit Birnen. Das ist aber auch ganz was anderes als die Ausgangsfrage. Also hier irrelevant. Naja, wie du selbst sagst, bin ich in den meisten Szenarien sogar dann noch günstiger, wenn ich den VMM nutze. Und in Mittelstandsszenarien bis fünf oder sechs Hosts geht es prima ohne, und da spare ich dann mal eben 40.000 Euro verglichen mit vSphere. Schauen sie zu Recht, weil die Aussage so ja nicht richtig ist. Dass Templates meistens sehr unsinnig eingesetzt werden und dann zu unguten Konfigurationen führen, steht jetzt mal auf einem anderen Blatt. "Die" Third-Party-Hersteller? Dann hast du dich auf dem Hyper-V-Markt aber noch nicht so gut umgesehen. Ich sehe da mittlerweile einige, die sehr interessante Zusatzprodukte bieten. Natürlich ist es vergleichbar. Es ist nicht dasselbe, aber es ist vergleichbar. Je nach Szenario kommt man, wie ja auch Daniel oben sagte, manchmal zu dem Schluss: Hier ist VMware besser geeignet. Dort ist Xen interessant. Und in anderen Situationen ist eben Hyper-V die bessere Wahl. Genau diese Differenzierung lässt du leider bislang vermissen. Das finde ich ein wenig schade. Nee, schon klar. Das Netzwerk, die Storage-Anbindung und das "bisschen Haushalt" macht sich bei VMware bekanntlich von selbst. <Zynismus>Glücklicherweise sehen das viele VMware-Verfechter so, daher haben wir eine Menge Aufträge, um sowas wieder geradezuziehen.</Zynismus> Kosten. Performance. Eignung. Je nach Situation. Wo es besser passt, empfehlen wir auch VMware. Und wo der Kunde eine Vorprägung hat, liefern wir ihm, was er gern möchte. Wir sind Dienstleister, keine Missionare. Gruß, Nils

Moin, vereinfacht gesagt: Ja. Gruß, Nils

Moin, wenn deine IP-Adressen 16-Bit-Subnetzmasken haben, befinden sie sich effektiv im selben Subnet. Entweder hast du das hier falsch wiedergegeben, oder es ist nicht günstig geplant. Oben hattest du noch "Cluster Network: Momentan je 1 Adapter pro Node" erwähnt - wo finde ich das in deiner Aufstellung wieder? Ansonsten würde ich vermuten, dass die Storage-Anbindung nicht korrekt ist. Darauf scheint mir auch die Fehlermeldung hinzudeuten, die du gepostet hast. Gruß, Nils

Moin, du bleibst auf dem Äpfel-und-Birnen-Niveau. Auch bei vSphere musst du selbstverständlich einen Cluster einrichten und konfigurieren, bevor HA funktioniert. Das ist, sobald man es einmal gemacht hat, auf beiden Seiten sehr beherrschbar. Und die Treiber-Installation - meine Güte ... entweder hast du von deinem Hardware-Hersteller ein Medium, das dir die Arbeit abnimmt. Oder du integrierst die Treiber in deine Installationswerkzeuge, wenn du wirklich viele Hosts installieren willst. Oder du hast eben 20 Minuten Aufwand. Dafür musst du bei neuer Hardware eben auch nicht warten, bis die vom Hersteller des Hypervisor durchzertifiziert ist und er die Treiber in seinen Kernel einkompiliert hat. Sorry, hier verlässt du mich. Seit wann ist XenDesktop zwingend erforderlich, um eine Hypervisor-Umgebung zu betreiben? Kommen jetzt auch noch mal Argumente? Gruß, Nils

Moin, ADFS ist zwar schon das richtige für das Szenario, aber dafür müsste natürlich auch die Web-Applikation angepasst werden. Für den Fall einer bestehenden Anwendung, die ihr nicht ändern könnt, wäre dann ein clientseitiges SSO-Tool geeignet. Gruß, Nils

Moin, sagen wir es so: Wenn es bei euch problemlos ist, den DC für ein paar Stunden länger außer Betrieb zu nehmen, dann ist evtl. das Herunter- und Heraufstufen in deinem Fall die einfachere Methode: DC herunterstufen Server umbenennen Server hochstufen und dabei gleich die richtigen Pfade wählen Gruß, Nils

Moin, weil es mir gerade auffällt, hier noch eine Korrektur für ein Missverständnis. Ein Switch hat keine IP-Adresse, weder in Hyper-V noch sonstwo. Es handelt sich bei physischen Switches um die IP-Adresse des jeweiligen Management-Moduls. Sowas gibt es bei virtuellen Switches nicht, weil dort eine andere Schnittstelle für das Management bereitsteht. Die Netzwerkkarte, die du "im Host" (richtiger: im Management OS) siehst, ist nicht "der Switch", sondern eine virtuelle Netzwerkkarte im Management OS, die an den jeweiligen Switch gebunden ist. Falls das Management OS nicht an den Switch gebunden sein soll, entfernt man das Häkchen "Gemeinsame Verwendung ... zulassen" in der Konfiguration des virtuellen Switches - dann verschwindet auch die virtuelle Netzwerkkarte, aber der Switch selbst bleibt natürlich erhalten. [Hyper-V und Netzwerke | faq-o-matic.net] http://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Gruß, Nils

Moin, wieso das denn? Allgemein rät man davon ab, weil es i.d.R. keine Vorteile bringt, aber sich vom Installationsstandard entfernt. Das verkompliziert manchmal Troubleshooting-Prozesse. Das Umbenennen eines DC ist kein Problem, das kann man genauso machen wie bei einem Client. Herunter- und wieder hochstufen ist nicht nötig. Das Verschieben der AD-Datenbank geht nur im Offline-Modus per NTDSUTIL. Ob es dazu reicht, die AD-Dienste zu beenden, weiß ich aus dem Kopf nicht (ich glaube schon); falls nicht, musst du den DC in den DS-Restore-Mode booten. Gruß, Nils

Moin, wie jetzt - meinst du? ... SCNR ... @Sunny: Meinst du nicht, dass eine Quellenangabe angebracht wäre? Gruß, Nils

Moin, ach so, um das noch eben anzuführen: Meine Einschätzung stützt sich auf eine höhere zweistellige Zahl von Hyper-V-Projekten zwischen zwei und 13 Hosts, beginnend mit Hyper-V in 2008 R2. Parallel gab es bei uns etwa dieselbe Zahl von vSphere-Projekten. Ich kann also beide Welten einschätzen. Abseits der Flamewar-Ebene stimme ich Daniels Zusammenfassung zu. Schöne Grüße, Nils

Moin, was du aufführst, lässt sich wohl am besten unter "Vorurteil" zusammenfassen. Der SCVMM bietet unbestritten Vorteile. Er ist aber auch nicht "nötig" in dem Sinne, dass ohne ihn "nichts" oder "recht wenig" ginge. Auch eine Umgebung mit, sagen wir, fünf oder sechs Hosts lässt sich problemlos ohne SCVMM betreiben. Alle Funktionen, die man von der Umgebung erwartet, stehen dann zur Verfügung: Failover, Live Migration, Replica, Cluster-Aware Updating, Client Monitoring, Metering ... Im Gegensatz zu vSphere, wo ich ohne vCenter kein HA und kein vMotion machen kann (und vieles andere auch nicht). Man ist hier also schnell dabei, Äpfel mit Birnen zu vergleichen. Klar, vCenter ist komfortabler als der mitgelieferte Hyper-V-Manager. Ich zahle allein dafür aber auch schon eine hohe vierstellige Summe, muss das also eher mit dem VMM vergleichen - und da hat dann eher der VMM die Nase vorn. "Installation dauert eine Stunde" - wenn du Patches und Konfiguration einrechnest, bist du bei vSphere auch nicht wesentlich schneller. Wir würden uns vielleicht über einen Unterschied von 20 Minuten unterhalten - für die Installation eines Hostservers, was ja nun eher eine einmalige Sache ist. So what? "Man muss den Cluster überwachen" - das muss man bei vSphere auch. Der Rest deiner Einwände bewegt sich meines Erachtens auf ähnlichem Niveau. Bleibt für mich irgendwie nur eine persönliche Abneigung übrig, die man nicht diskutieren kann. Und "Flamewars" brauchen wir hier im Board nicht. Gruß, Nils

Moin, einen RDP-Zugriff kannst du für VMs nur über das Netzwerk einrichten. Der Client, von dem aus du zugreifst, und die jeweilige VM müssen also miteinander per IP kommunizieren können. Als Alternative kannst du dir die Verwaltungstools auf dem Client installieren und dann per vmconnect.exe zugreifen, das ist das "Konsolenfenster", das du auch vom Host aus über den Hyper-V-Manager nutzt. In dem Fall muss der Client nur mit dem Host sprechen können, aber nicht direkt mit der VM. Du brauchst dann aber natürlich auch Zugriffsrechte für vmconnect.exe (entweder weil du Host-Admin bist oder weil dir die Rechte explizit eingeräumt wurden). Ein "interner" Switch ist ein Hyper-V-Switch "ohne Uplink", d.h. nur der Host und die VMs sind daran gebunden, aber nicht das externe LAN. Die jeweiligen virtuellen Netzwerkkarten müssen dann IP-Adressen aus demselben Segment bekommen, wenn sie miteinander kommunizieren sollen. Gruß, Nils

Moin, hilft Marks Artikel? [KMS – Key Management Service – Installation und Konfiguration | faq-o-matic.net] http://www.faq-o-matic.net/2013/04/29/kms-key-management-service-installation-und-konfiguration/ Gruß, Nils

Moin, ja, das stimmt. Ich habe das gerade mal ausdrücklich hingeschrieben. Gruß, Nils

Moin, korrekt, wobei du dich mit 10 GB dann schon hart am unteren Rande der Empfehlung befindest. Gruß, Nils

Moin, das wäre die einzige sinnvolle Variante. (Ist ja oben auch schon mal genannt worden.) Gruß, Nils

Moin, "technisch fehlerfrei" geht das natürlich auch heute noch, genau wie seit Windows 2000. Es ist genau wie damals aber nicht nur "nicht Best-Practice", sondern es ist aus vielen sattsam bekannten Gründen entschieden davon abzuraten. Gruß, Nils

Moin, ja. Steht in dem Artikel. Nein, es geht die ganze Zeit um den internen Namensraum. Meine Empfehlung lautet einfach: Der interne Namensraum sollte einen "offiziellen" Namen verwenden, der dem Unternehmen gehört, der aber idealerweise nicht für externe Zwecke verwendet wird. Gruß, Nils

Moin, äh - ich verstehe die Rückfragen zu meinem Artikel nicht recht. Dort spreche ich doch eine ausgesprochen deutliche Empfehlung aus: Was alles passieren kann, wenn der interne Namensraum im Internet jemand anderem gehört, haben wir in diesem Board auch erst kürzlich gehabt: http://www.mcseboard.de/topic/192507-nslookup-hängt-immer-dns-suffix-an/#entry1192179 Gruß, Nils Moin, dann registrier ihn doch selbst ... kostet etwa 10 EUR pro Jahr und ist damit ein Quentchen günstiger als jedes Troubleshooting. Gruß, Nils Ja, viele Unternehmen machen das so.

Moin, da wird IPv6 nicht die Ursache sein, das klingt eher nach einem zufälligen Zusammentreffen. Was sagt das Eventlog? Was ist noch an dem Server geändert worden? Gruß, Nils

Moin, von .local rate ich nach wie vor ab. Ansonsten ist alles Nötige zum Thema DNS-Namensraum für AD ja in meinem oben verlinkten Artikel schon gesagt. (Naja, gut, zumindest alles, was ich selbst als nötig erachte.) Es gibt bei einer neu aufgebauten Struktur normalerweise überhaupt keinen Grund, dass interner und externer DNS-Namensraum gleich heißen. Dafür gibt es gleich mehrere Gründe dagegen. Gruß, Nils

Moin, wie viele Netzwerkkarten haben die Hosts? Wie sind diese konfiguriert? Gruß, Nils