NilsK

Moin, dass er es kann, hat Azharu ja nicht gesagt - und dass BR-Leute gern mal auf Ideen kommen, habe ich auch schon erfahren dürfen. ;) Gruß, Nils

Moin, du musst hier mehrere Dinge unterscheiden. Was du offenbar versuchst, ist eine Live Migration: Verschieben einer laufenden VM von einem Host zum anderen. Ein Ex- oder Import ist etwas anderes. EIne Live Migration geht nur, wenn die Prozessorarchitektur und die wesentlichen CPU-Features identisch sind, wie Dunkelmann schon sagt. Siehe dazu auch: [Was die Prozessorkompatibilität in Hyper-V wirklich tut | faq-o-matic.net] http://www.faq-o-matic.net/2013/09/23/was-die-prozessorkompatibilitt-in-hyper-v-wirklich-tut/ Gruß, Nils

Moin, kann man natürlich machen. Finde ich aber unnötig und tendenziell zu komplex - neben den vNICs gibt es in dem Fall noch die pNICs, die zu verwalten sind. Wenn man die vNICs mit Bandbreitensteuerung einrichtet, tritt der von dir beschriebene Effekt gerade nicht auf. Man weist jedem Netzwerk ein Minimum zu, unter das es von anderen Netzwerken nicht gedrückt werden kann, sofern es selber Traffic hat. Wenn dann im Netzwerk aber nichts anderes los ist, laufen die Migrationen sehr schnell. Und da man in einem normalen Netzwerk ja nur selten migriert, belegt das LM-Netzwerk im Normalbetrieb gar nichts. Wenn aber mal ein Host evakuiert werden soll, ist es schon von Vorteil, mehr als 1 oder 2 Gbit zur Verfügung zu haben. Zudem: Schon die beiden 10-GbE-Karten belasten die Host-CPUs erheblich. Wenn sie sich dann auch noch um die anderen Karten kümmern müssen, die eigentlich aber keinen Nutzen ergeben, dann ist das eher von Nachteil. Gruß, Nils

Moin, Windows 10. Gruß, Nils PS. :D

Moin, hey - long time no see! :) Gruß, Nils

Moin, mir scheint da ein grundsätzliches Missverständnis vorzuliegen. Der Hyper-V-Host ist nur ein Host, nichts anderes. Auf dem Host läuft kein DHCP, kein DNS und sonst auch nichts. Nur Hyper-V. Vom Host aus öffnet man auch keinen Browser, um ins Internet zu gehen. Auf dem Host richtet man VMs ein. Dort laufen dann die Dienste, die man braucht. Ins Internet geht man nur von einem Client aus. Ein alleinstehender Host sollte (mindestens) zwei Netzwerkkarten haben. Eine konfiguriert man "ganz normal" so, dass der Host im LAN erreichbar ist und seinerseits die Domäne und WSUS usw. erreicht. Auf diese Karte bindet man keinen Hyper-V-Switch. Die andere Karte lässt man auf der Host-Ebene unkonfiguriert. Sie bindet man dann an den Hyper-V-Switch, auf dem man das Kästchen "Gemeinsame Verwendung ... zulassen" abschaltet. An den Switch bindet man dann die virtuellen Netzwerkkarten der VMs, die ihrerseits eine "normale" IP-Konfiguration bekommen, wie es auch bei physischen Rechnern wäre. Gruß, Nils

Moin, für solche Zwecke brauchst du das Recovery-Kennwort des DCs. Gruß, Nils

Moin, oh, das würde ich nicht automatisch erwarten. DDA ist keine universelle Schnittstelle. [Hyper-V 2016: Discrete Device Assignment | faq-o-matic.net] http://www.faq-o-matic.net/2015/12/07/hyper-v-2016-discrete-device-assignment/ Die Frage ist aber auch, ob der Zugriff so überhaupt sinnvoll wäre - die Hardware-Schnittstelle eines Hosts ist immer ein SPoF. Gruß, Nils

Moin, jein. CSV läuft auf dem SOFS. Der Hyper-V-Cluster nutzt dann selbst kein CSV. Gruß, Nils

Moin, hier gehen einige Dinge durcheinander, die man allerdings gerade als "Neuling" auch leicht verwechselt. CSV und SAN: Du kannst das Cluster-Storage klassisch mit einem iSCSI-Target (oder einem FC-SAN) aufbauen. In dem Fall richtest du die Cluster-Volumes, die Hyper-V nutzen soll, als CSV ein. Streng genommen, handelt es sich hier um "SAN" und nicht um "NAS". Das Storage ist der Single Point of Failure, müsste also über eigene Redundanz abgesichert werden, wenn das erforderlich ist. SMB 3 und Scale-out Fileserver: Hyper-V kann seine Daten auch auf einem SMB-3-Fileserver ablegen. Je nachdem, wie man den aufbaut, kann der selbst wiederum hochverfügbar ausgelegt werden, ggf. auch mit mehrfacher Datenablage. Hier kommt kein CSV ins Spiel. Beachte aber: Wenn das wirklich hochverfügbar sein soll, wird es auch mit diesem Konstrukt teuer, tendenziell eher teurer als eine "herkömmliche" SAN-Lösung. Und es ist ein "Eigenbau", den man weitgehend selbst supporten muss. S2D und Hyperconverged: Erst mit Windows 2016 gibt es die oben auch schon skizzierte Variante "Storage Spaces Direct" (S2D). Hier hat jeder Host selbst Platten und SSDs, die dann über alle Hosts hinweg einen Pool bilden. S2D kümmert sich um die Replikation. Der Ansatz ist vergleichbar zu Techniken von Nutanix oder Simplivity oder zum vSAN von VMware. Aber: Windows 2016 gibt es noch nicht. Und es wird voraussichtlich die Datacenter Edition dafür brauchen. Und man muss es eben selbst aufbauen und supporten, es ist keine fertige Lösung (wie etwa bei Nutanix). Gruß, Nils

Moin, ja, Lazarus kann man ganz gut dazu nutzen. Gruß, Nils

Moin, mit dem Modell könnte ich mich anfreunden! :D Gruß, Nils

Moin, das ist schon richtig beobachtet. Robocopy ist ja auch kein Backup-Programm. Gruß, Nils

Moin, dann wird es aber auf einer anderen Ebene angesprochen. Gruß, Nils

Moin, die BIN-Datei wird erst ab Windows 2012 nicht mehr erzeugt, wenn die Automatic Stop Action auf "Shut down" oder "Turn off" steht. Bis 2008 R2 wird die BIN-Datei anscheinend immer erzeugt. Also: Umgehend Plattenplatz hinzufügen, kurzfristigauf eine aktuelle Hyper-V-Version aktualisieren, mittelfristig das Design der Umgebung überarbeiten. Gruß, Nils PS. Übrigens findet man dies innerhalb von Minuten raus, wenn man nach "Hyper-V bin file" sucht ...

Moin, oder das eingebaute Backup, das deutlich besser ist als sein Ruf. Gruß, Nils

Moin, du kannst das schon so versuchen - allerdings gilt das Archivbit heute nicht mehr als aussagekräftig, weil es wohl Situationen gibt, in denen es nicht wie gewünscht behandelt wird. Ich kriege das aus dem Kopf nicht mehr zusammen; vielleicht verwechsle ich auch was. Du solltest aber auf jeden Fall prüfen, was du da sicherst. Sind deine Datenmengen denn so groß, dass du wirklich mit einem so komplexen Verfahren sichern willst? Bedenke, dass du damit u.U. das Recovery erschwerst. Ich habe auch lange nach so einem Verfahren gesichert, aber in den wenigen Fällen, wo ich es dann gebraucht hätte, war es mir eher im Weg. Zudem ist es bei dieser Sorte Backup schwer, den Erfolg zu kontrollieren. Gruß, Nils

Moin, öh - das sehe ich nicht so. Nach wie vor ist WINS ein Problemlöser, auch wenn viele das nicht hören wollen. Und wenn man es nutzt, ist es auf einem DC nicht grundsätzlich falsch aufgehoben. Gruß, Nils

Moin, aha. Nun ist es aber so, dass Microsoft DCs ausdrücklich als Anwendungsfall für Dynamic Memory benennt. Nicht dass ich ein Fan von DM wäre, aber dagegen spricht hier aus meiner Sicht gar nichts. In dem gegebenen Szenario würde ich durchaus 512 bis 2048 einstellen. Wenn der DC mehr als 512 braucht, wird er soweit auch nicht runtergehen. Für Normalsizing würde ich auch von 2 GB RAM ausgehen, aber bei 100 Usern sehe ich keinen Bedarf für zwei vCPUs. Gruß, Nils

Moin, ja. Du kannst aber, wie bei der ersten Antwort in dem anderen Thread angegeben, das Verhalten des Windows Explorer auch verändern, sodass er auch beim Verschieben die Ziel-Berechtigungen übernimmt. Hab ich lang nicht ausprobiert, sollte aber gehen. Gruß, Nils

Moin, hähä, genau das Phänomen diskutieren wir aktuell (mal wieder) in einem anderen Thread. Wenn man Dateien oder Ordner auf derselben Partition verschiebt, behalten sie ihre Berechtigungen. Das ist die einzige Situation, in der dies geschieht, weil hierbei die Daten gar nicht verändert werden, sondern nur der Pointer im Inhaltsverzeichnis. http://www.mcseboard.de/topic/202482-rechte-werde-nicht-richtig-vererbt/ Gruß, Nils

Moin, das ist ja alles richtig, aber der TO hat ja erneut gefragt. Eine richtige "Lösung" in dem Sinn, wie es dem TO vorschwebt, gibt es nicht, jedenfalls nicht mit dem Explorer und ohne Eingriffe. Es gibt nur Workarounds. EDIT: Also, noch mal zusammengefasst: Vermutlich bester Workaround: Das Verhalten des Windows Explorer ändern wie in der ersten Antwort dieses Threads angegeben (siehe KB-Artikel - sollte auch heute noch gehen, ich habe es aber nicht getestet). Nachteil: Das muss auf jedem Rechner gemacht werden. Wenn jemand mit "unmanipuliertem" Explorer arbeitet, greift es nicht. Alternativ: Anderes Programm nehmen, wo man das steuern kann. Alternativ: Nicht verschieben, sondern kopieren und löschen. Gruß, Nils

Moin, in solchen Fällen wäre es sinnvoll, wenn du deine konkrete Frage formulierst. In diesem Thread ist es etwas aufwändig herauszufinden, was denn jetzt "dein Problem" sein könnte. Ich nehme an, es geht um die Berechtigungen beim Verschieben. Ein Workaround wäre, dass du nicht verschiebst, sondern kopierst und danach die Quelle löschst. In dem Fall hast du immer dasselbe Verhalten, unabhängig, um welche Partition es geht. Gruß, Nils

Moin, da verstehe ich weder das Konzept noch deine Abfrage noch die Frage, die du stellst. Gruß, Nils

Moin, mit einer Liste der DHCP-Server, Excel, psexec und netsh solltest du das hinbekommen. [Excel: Admins unbekannter Liebling | faq-o-matic.net] http://www.faq-o-matic.net/2008/01/19/excel-admins-unbekannter-liebling/ [Netsh commands for DHCP] https://technet.microsoft.com/en-us/library/bb490941.aspx [PsExec] https://technet.microsoft.com/de-de/sysinternals/psexec Gruß, Nils