Reales System virtuell abbilden?

[Volker Racho 10]

Hallo Virtualisten!

 

Ich würde gerne wissen, was mich beim Update von SQL 2000 auf SQL 2005 erwartet und hatte dabei den Plan einen bestehenden Win2K3 Server mit SQL2K abzubilden, um an diesem virtuellen Server dann das Update exemplarisch auszuprobieren.

 

Wir haben hier Virtual PC für unsere Windows Systeme im Einsatz. Bisher habe ich immer nur ein System neu installiert, nie ein bestehndes System in einer virtuellen Maschine abgebbildet. Geht das überhaupt? Macht das Sinn? Und: Wie geht's?

 

 

Beste Grüße,

MD

[Lian 2.361]

Hallo,

 

ja, das geht: Physical-to-Virtual - Wikipedia, the free encyclopedia

 

Stichworte sind: Physical to Virtual, P2V

[Volker Racho 10]

Alles klar, wonderbra. Genau die Stichworte fehlten mir.

Danke sehr!

 

MD

[Lian 2.361]

Gerne. ;)

Der VMWare Converter verrichtet seinen Dienst recht gut, auch für Remote Systeme und das kostenfrei:

VMware vCenter Converter, Convert Physical Machines to Virtual Machines - VMware

[Volker Racho 10]

Klasse, Lian, das probiere ich gleich mal aus.

 

Gruß & herzlichen Dank!

MD

[Volker Racho 10]

Hallo Lian!

 

Leider gibt mir der Konverter bei der Installation einen Runtime (C++)-Fehler aus. Egal auf welchem Server ich es installiere.

...

[Gabriel70 10]

..Leider gibt mir der Konverter bei der Installation einen Runtime (C++)-Fehler aus. Egal auf welchem Server ich es installiere....

 

Hallo!

 

Systeme aktuell gepatcht?

Was steht dazu im Eventlog?

 

Gruß

[Lian 2.361]

Den Converter kann man von einer Workstation aus starten, es wird dann nur ein Agent auf dem Server installiert, den man nach dem Convert wieder loswerden kann.

[Volker Racho 10]

Das ist ja noch besser.

Leider aber kann er mein Hostsystem nicht kopieren, da er den dort laufenden SQL-Server nicht einfangen kann - und bricht dann ab. Vielleicht würde es gehen, wenn ich den SQL stoppe, aber dass kann ich erst später ausprobieren, da er gerade gebraucht wird.

...

[m2k2 10]

@lian:

 

ich würde den Thread gerne nochmal aufnehmen.

 

Ich habe einige physik. Server im Einsatz und der 1. (auch FSMO Holder) inkl. Exchange macht mir etwas Kopfschmerzen im Bezug auf ein schnelles Desaster Recovery. Mein Gedanke ist: ich habe einen Server inkl. VMware Server 2.0 (Einstieg in die VM für die Zukunft). Über den vCenter Converter würde ich nun den 1.DC inkl. Exchange 2003 P2V bringen um im Desaster diese VM hochzufahren. Ich habe nun schon eine XP Pro konvertiert, dann einen 64bit NLB Server 2003. Hat beides wunderbar funktioniert. Jetzt steht der Exchange an.

 

1. Ist der Gedanke eines Desaster Recoverys im Bezug auf VM Maschinen vielleicht doch der falsche Ansatz ?

 

2. Könnte es Komplikationen geben auf dem physik. Exchange nach der Konvertierung.

 

3. Was ist, wenn der physik. wegbricht und die VM hochfährt (SID usw.)

 

Mein Gedanke ist der, ich hätte genug Zeit die neue Hardware zu beschaffen, die FSMO Rollen auf den 2. oder 3. DC zu verschieben und anschließend einen neuen Server ins Netz zu integrieren. Natürlich können die User nicht die volle Performance erwarten, jedoch sind diese noch handlungsfähig.

 

Ich meine gelesen zu haben, dass der vCenter Converter blockbased seinen Dienst verrichtet ??

[Lian 2.361]

1. Ist der Gedanke eines Desaster Recoverys im Bezug auf VM Maschinen vielleicht doch der falsche Ansatz ?

Mein Vorschlag oben bezog sich auf die Anforderung "Testsystem" ;)

 

Virtualisierte Server zu betreiben im Produktivbetrieb stellt an sich kein Problem dar. Allerdings ist nicht alles möglich, sinnvoll oder supported:

Microsoft server software and supported virtualization environments

 

Mein Gedanke ist der, ich hätte genug Zeit die neue Hardware zu beschaffen, die FSMO Rollen auf den 2. oder 3. DC zu verschieben und anschließend einen neuen Server ins Netz zu integrieren. Natürlich können die User nicht die volle Performance erwarten, jedoch sind diese noch handlungsfähig.

Wie gesagt: Das sollte für den produktiven Einsatz genau überlegt sein. Die Lösung für ein temporäres Disaster Recovery sollte dann fix und fertig dokumentiert in der Schublade liegen.

Wird in so einem Fall nicht 100% ordentlich gearbeitet, kann einiges schiefgehen.

 

Mein Fazit: DCs und NLB Nodes lieber über Redundanz verfügbar halten, Exchange mittels Backup absichern und ggf. Clustern.