Archive for the ‘Backoffice’ Category
Weitere Links zu Windows Server “8” – Part 4

-> SR-IOV in Hyper-V Part-8
-> Why is the “Hyper-V Replica Broker” required?
-> Option to remove .BIN files with Hyper-V in Windows “8”
-> Cleaning up after VM upgrade with PowerShell in Windows “8”

Weitere Links zu Windows Server “8” – Part 3

-> SR-IOV in Hyper-V Part-5
-> SR-IOV in Hyper-V Part-6
-> SR-IOV in Hyper-V Part-7
-> Building an Optimized Private Cloud using Windows Server “8″ Server Core
-> New networking tab on Hyper-V Manager in Windows “8″

Weitere Links zu Windows Server “8” – Part 2

-> SR-IOV in Hyper-V Part-4
-> Windows Server “8″ – Taking Server Application Storage to Windows File Shares
-> Windows Server “8″ Beta Scale-Out File Server for SQL Server 2012 – Step-by-step Installation
-> Windows Server “8″ Beta Hyper-V Component Architecture Poster

Weitere Links zu Windows Server “8”

-> SR-IOV in Hyper-V Part-2
-> SR-IOV in Hyper-V Part-3
-> Using PowerShell to Storage Migrate with Windows Server “8″
-> Hyper-V Replica – Prerequisites for certificate based deployments
-> How does Storage Migration actually work?

Windows Server “8”, System Center 2012, …

Zu den in der Headline genannten Themen habe ich einige sehr interessante Links herausgesucht:

-> SR-IOV in Hyper-V Part-1
-> Doing a simple Storage Migration with Windows Server “8″
-> Windows Server “8″ Beta – Hyper-V Replica
-> Using PowerShell to mount virtual hard disks in Windows Server “8″
-> Using PowerShell to check Integration Services versions
-> Updating Integration Services in Windows Server “8″
-> Hyper-V Server “8″ Beta available for download
-> Live snapshot merging! [Windows Server "8"]

Des Weiteren ist vor ein paar Tagen die “System Center 2012 Virtual Machine Manager Service Pack 1 Community Technology Preview” erschienen. Mehr Informationen dazu findet ihr unter:

-> http://blogs.technet.com/b/scvmm/archive/2012/03/10/system-center-2012-ctp-for-windows-server-8-beta-support-now-available.aspx

SCVMM, Failover Clustering, Error 406

Gestern habe ich wieder ein wenig in meiner Testumgebung hantiert. Dabei ist mir eine doch interessante Sache aufgefallen beziehungsweise ein Fehler aufgetreten. Wenn man in seinem Hyper-V Failover Cluster auf einem der Clusterknoten den SCVMM installiert und dann versucht den Cluster dem SCVMM hinzu zu fügen, kann es schon einmal zu folgendem Fehler kommen:

Error (406)

Access has been denied while contacting the server <server name>.

Recommended Action

1. Verify that the specified user account has administrative privileges on <server name>.

2. Verify that DCOM access, launch, and activation permissions are enabled on <server name> for the Administrators group. Use dcomcnfg.exe to modify permissions, and then try the operation again.

Der Fehler kommt dadurch zustande, dass die Cluster Group auf dem Clusterknoten gehostet wird, auf dem auch der VMM Manager installiert ist. Das Problem kann gelöst werden in dem man mit dem folgenden Befehl die Cluster Group auf einen der anderen Clusterknoten verschiebt.

cluster group

Hiermit ermittelt man auf welchem Clusterknoten die Cluster Group gehostet wird.

Cluster1

cluster group “Cluster Group” /move:<server name>

Damit wird die Cluster Group auf einen anderen Clusterknoten verschoben.

Cluster2

Das Ergebnis ist perfekt und jetzt sollte auch nichts mehr dem Hinzufügen des Clusters zum SCVMM im Weg stehen.

RemoteFX und Live Migration

RemoteFX und Live Migration ist schon eine etwas außergewöhnliche Kombination. Man wird sie vermutlich im produktiven Umfeld eher weniger vorfinden. Was man dabei zu beachten hat, folgt in den nächsten Zeilen.

Zu Demozwecken bezüglich RemoteFX, verwende ich eine entsprechende VM auf meinem Hyper-V Host mit einer ATI Grafikkarte. Seit ein paar Tagen ist ein weiterer Hyper-V Host hinzugekommen, der auch eine ATI Grafikkarte beinhaltet. Nun war natürlich meine Neugierde geweckt, ob es ausreicht wenn die Grafikkarte vom selben Hersteller ist oder es exakt das gleiche Modell sein muss. Die Ernüchterung bekam ich durch den SCVMM 2012 RC Dialog sehr schnell.

RFX1

Es muss tatsächlich das gleiche Modell sein. Leider gibt es an dieser Stelle nicht die Möglichkeit, wie bei der CPU, einen entsprechenden Kompatibilitätsmodus zu aktivieren. Daher sollte man bei der Planung seines Hyper-V Failover Cluster auf folgende Dinge genau achten, falls man RemoteFX in Kombination mit der Live Migration nutzen möchte:

  • Identisches Modell der Grafikkarten
  • Identisches Modell der CPUs

Letzteres ist eher obsolet, da man den Kompatibilitätsmodus aktivieren kann. Wenn man aber schon beim Design ist, dann sollte man auch sämtliche CPUs aus der gleichen Modellreihe verwenden.