Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.

Disk Clone - Was übernehmen?

Moderatoren: Dayworker, continuum, Tschoergez, irix

Experte
Beiträge: 1301
Registriert: 30.03.2009, 17:13

Disk Clone - Was übernehmen?

Beitragvon UrsDerBär » 02.03.2015, 20:32

Hallo Leute,

Bin gerade dabei eine viel zu grosse Partion zu verkleinern und anschliessend auf eine neue Disc zu clonen.
Das ganze mache ich wie üblich mit gparted. Bis dato habe ich das aber nur bei Datendisc gemacht. Der erste Versuch scheiterte kläglich. --> Kein Boot ohne RescuDisc

Nach kurzer Recherche habe ich einen Tipp gefunden, dass die Bootsektoren nicht mit kopiert werden also per DD nen Disk-Clone Task gestartet und nach einiger Zeit abgebrochen. Danach den Kopiervorgang erneut gestartet.

Nun frage ich mich aber, ob ich die Angaben im Discdescriptor-File ebenfalls 1:1 kopieren soll, bis auf die Anzahl Zylinder, damit Windows nicht das Gefühl hat, es hätte ne neue Disc.

Also: CID, uuid, hardwareversion, longcontentid übernehmen

Dass die alte Disc dann nicht wirklich wieder angeschlossen werden sollte (vermutlich an keine VM), ist mir schon bewusst. Bootet die neue Platte, wird die alte direkt entsorgt. Wenn nicht, die neue Platte und von vorne.

Vielen Dank für Inputs!

Member
Beiträge: 173
Registriert: 06.06.2006, 08:50
Wohnort: Kaiserslautern
Kontaktdaten:

Beitragvon moo2102 » 03.03.2015, 07:02

Kurze frage warum machst du das nicht mit dem Converter?
Da hast du absolut keinen ärger und die Maschine geht direkt wieder, nur die Netzwerkconfig musst du teilweise neu machen.

Experte
Beiträge: 1301
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 03.03.2015, 07:09

Weil ich nicht so ganz nachvollziehen kann, was das Ding alles macht.

Zudem ist es mit gparted ein leichtes die Disc/Partition zu klonen. Möchte nur die Gewissheit haben, dass die Platte anschliessend bis auf die Grösse 'identisch' mit der alten ist und eben die entsprechenden Angaben im Descriptor Files tätigen, damit der Wechsel für Windows transparent ist.

Die Frage ist nun, welche Angaben sollten dazu kopiert werden oder eben nicht.

Experte
Beiträge: 1956
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 03.03.2015, 08:37

Nach meinem Verständnis sind die externen Descriptor-Daten der VMDK für die interne Windows-Installation völlig transparent. Ich würde die Partition mit dem Drive Snapshot sichern, eine kleinere Platte neu erstellen und das Image unter Beachtung der Mindestgröße zurückspielen. Man kann auch mit einer Windows-Bootdisk die Partition vor dem Klonen verkleinern.

Experte
Beiträge: 1301
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 03.03.2015, 08:53

Das ist doch viel komplizierter als mit gparted.

Ich habe es einfach mal ausprobiert (über nacht ne sicherung gezogen). Disk-Clone, 2min (damit Bootsektor kopiert wird) laufen lassen, abgebrochen und anschliessend die Partition kopiert.

Hab alle genannten Parameter in den Descriptor übernommen (ob nötig oder nicht) und dann die VM neu gestartet. Hat wunderbar funktioniert.

Würde mich aber trotzdem interessieren was Windows von den ID's genau mitbekommt oder ob es total irrelevant ist.

Grüsse und trotzdem Danke für die Inputs!

Experte
Beiträge: 1956
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 03.03.2015, 11:07

UrsDerBär hat geschrieben:Das ist doch viel komplizierter als mit gparted.

Ja - dafür speichert Drive Snapshot auch den MBR und die Partitionstabelle und kann diese ggf. wiederherstellen. gparted ist optimal fürs Kopieren einzelner Partitionen.

Experte
Beiträge: 1301
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 03.03.2015, 11:24

OK. Das stimmt. Wobei die neueren gparted das glaub auch direkt per GUI können.
Bei den alten musst einfach nen normalen DD Copy-Job per Kommandozeile starten und 1-2 Minuten rödeln lassen. Dann kannst abbrechen und die Partition kopieren. Somit ist Bootsektor kopiert.

Experte
Beiträge: 1956
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 03.03.2015, 12:04

Ich habe mal die 0.21 getestet. Was geht: Quellpartition verkleinern, Zielplatte partitionieren, alle Partitionen kopieren, Bootable Flag setzen. Was nicht geht: MBR Code kopieren.

Man kann nach erfolgter Kopie einmal mit der Windows-DVD booten und die Systemstartreparatur losschicken, diese repariert den MBR Code auch.

Experte
Beiträge: 1301
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 03.03.2015, 12:14

Hmm dann also doch nicht via GUI. Via Shell gehts aber problemlos:
1. Terminal öffnen
2. dd if=/dev/sda of=/dev/sdb
--> sda = Laufwerk mit den Infos
--> sdb = Ziellaufwerk

3. Nach 1-2 min abbrechen
Anstatt abbrechen soll auch der zusatz von bs=512 count=1 nur den Bootsektor kopieren.

4. gparted GUI aktualisieren, allfällig bereits erstellt Partionen löschen. Partion rüberkopieren. BootFlag setzen. Fertig.

Experte
Beiträge: 1956
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 03.03.2015, 12:25

UrsDerBär hat geschrieben:Anstatt abbrechen soll auch der zusatz von bs=512 count=1 nur den Bootsektor kopieren.

Das sollte gehen. Ist deine Zieldisk gleich groß? Wenn nein, was sagt gparted zu der ungültigen Partition?

Experte
Beiträge: 1301
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 03.03.2015, 13:32

Nope, Disk nicht identisch gross. Die Partition habe ich aber vorgängi mit gparted verkleinert, insofern passt sie nun auf die Disk. Sonst würde das ganze ja keinen Sinn machen.

Eine allfällige Partitionstabelle kann man aber auch löschen, ohne dass die Bootsektoren gelöscht werden. Danach die Tabelle neu erstellen, Partition kopieren und darauf achten, dass der Startsektor identisch ist. Bei mir gabs keinerlei Probleme. Wäre auch unlogisch wenn der Rest der "Pseudo-physichen-Parameter" identisch ist.

Experte
Beiträge: 1956
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 03.03.2015, 14:25

UrsDerBär hat geschrieben:Sonst würde das ganze ja keinen Sinn machen.

Ich hatte irgendwie quer-verlesen, dass du vorübergehend ein 1:1 Abbild erstellst - warum auch immer.

Benutzeravatar
Moderator
Beiträge: 14692
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 03.03.2015, 18:29

Bin gerade dabei eine viel zu grosse Partion zu verkleinern und anschliessend auf eine neue Disc zu clonen.


Ruf doch mal an - ich mache sowas auch ohne Clone.
Das Verfahren ist tricky aber sicher.

0172 6248374

Benutzeravatar
Moderator
Beiträge: 14692
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 04.03.2015, 13:11

Anleitung zum Verkleinern von ESXi-vmdks:

Beispiel: vmdk mit einer Windows-datenpartition E: von 2048 Gb - GPT-table
Problem: vmdk wurde so gross angelegt wie 5.1 es erlaubt - dann lassen sich aber keine Snapshots mehr nutzen
Ziel: neue Grösse 2000 GB damit man unter 5.1 Snapshots erstellen kann.

1. im Gast: defragmentieren von E:
2. Snapshot anlegen
3. per Gparted-LiveCD :resize der NTFS-partition auf 2000Gb
4. im Gast: chkdsk /f /x e:
5. wenn alles gut ist - VM herunterfahren und snapshot entfernen

6. sichere neue Grösse ermitteln:
1 MB offset vor der Partition
+ 2000 x 1024 MB für die neue Partition
+ 8 MB oder mehr leeren Raum nach Ende der Partition
----------------------------------------------------------------

2048009 MB
/ 8 Teilen
-------------------------
256001.125

aufrunden
------------------
256002

x 8
------------------
2048016

Das wäre zB eine sichere neue vmdk-Grösse 2048016 Mb

7. Abschneiden der original vmdk auf die neue Länge:
dd if=/dev/zero bs=1M count=1 of=name.vmdk seek=2048015


!!! Der seek Wert ist kritisch: Hier bitte 1 abziehen vom Wunschwert. Dann passiert folgendes: dd schreibt einen leeren 1MB in die original-vmdk. Dieser Block fängt dann nach 2048015 MB an und hört genau am Ende der Wunschlänge auf. Die vmdk wird dann nach dem leeren Block abgeschnitten.

Das dd Kommando kann man per putty direkt auf dem Datastore ausführen.

Nach dem Abschneiden VM aus Inventory entfernen und die vmdk Beschreibung ediotieren:

2048016 x 1024 x 1024 = size in bytes
size in bytes / 512 = size in sectors
------------------
4194336768

Das ist dann der neue Wert für die extentdescripütion

4194336768 / 16065 =
261085.3886087768

Abrunden
-----------------
261085 - das ist der neue Wert für die SCSI-geometrie


Nach dem Editieren der vmdk VM neu registrieren und in Gparted CD booten.
Gparted meckert weil die GPT-tabelle daneben ist und keine Backupkopie am Ende der Platte liegt - klar - deie haben wir ja abgeschnitten.
Nach der Reparatur mit Gparted kann man dann wieder ins Original OS booten und ein chkdsk laufen lassen.


VORSICHT: wer sich verrechnet zerstört seine Daten

VORTEIL: keine "unnötigen Clonevorgänge erforderlich.

Tip: den dd-Befehl unbedingt vorher an Testdateien üben

Experte
Beiträge: 1301
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 04.03.2015, 13:45

Hello!

Puuh vielen Dank... Sollte man sich nicht verrechnen! *g*
Denke bei grösseren Platten und wenig Platz auf dem Main-Storage ist das schon ein sehr guter Weg!

Experte
Beiträge: 1956
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 04.03.2015, 13:46

@continuum

In der Kurzversion:
1. GPT-Datenpartition verkleinern
2. 1 MB Nullen in das letzte MB der reduzierten VMDK schreiben
3. VMDK durch Eintragen von kleineren Werten in die Descriptoren abschneiden
4. GPT reparieren

Ist das Überschreiben mit Nullen eine Vorsichtsmaßnahme für GPT (damit da kein "Unsinn" steht)?

Das Verfahren sollte auch mit MS-DOS Partitionstabellen gehen. Kann dann Schritt 2 unterbleiben und ist Schritt 4 auch mit MS-DOS Partitionstabellen notwendig?


@Urs

Man kann auch gparted eine neue Partitionstabelle anlegen lassen und nach dem Verkleinern und Kopieren der Partitionen und dem Setzen des Boot-Flags mit

Code: Alles auswählen

dd if=/dev/sda of=/dev/sdb bs=446 count=1

nur den MBR Code kopieren.

Benutzeravatar
Moderator
Beiträge: 14692
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 05.03.2015, 06:59

Vorsicht - das Abschneiden passiert durch das Schreiben des einen Leerblock

guckk mal ...

Bild

Das Editieren der vmdk ist nur als Hilfe für den ESXi damit der sich nicht so zickig wie normal einfach mal mit der unerwartet veränderte VMDK abfindet.

Ich verwende grundsätzlich hier immer bs=1M
und wenn es geht einfache Vielfache von 8 MB. Dann erhält man vmdks die sich allignen lassen oder alligned bleiben können.
Ergibt auch schönere vmdk-to-disk Maps mitz vmkfstools - t0.

Das wichtigste ist aber die Gewöhnung an eine feste Methode.

Jedesmal wenn ich das selber mache geht es um Produktions-VMs bei denen absolut nichts schief gehen darf. - Ohne Routine ist das oft ein wirklich nerven-aufreibender Einsatz. Ein Fehler und schon sind alle hinter dir her ...

8)

Experte
Beiträge: 1956
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 05.03.2015, 10:15

Hui - danke für die Info. Von "außerhalb" der VM einfach ein Paar Nullen in eine Datei zu schreiben und sie damit zu kürzen, ist nicht wirklich intuitiv :D .

Ich habe das mal mit Test-VMs und gparted-live-0.21.0 durchgespielt. Funktioniert einwandfrei.

Eine MS-DOS-Partitionstabelle ist nach dem Kürzen der Disk nicht ungültig, da sie keinerlei Informationen zur Gesamtgröße oder der ursprünglichen Zylinderzahl enthält.

Mit einer GPT findet gparted-0.21.0 die dann zu kleine Disk dagegen nicht witzig und zeigt sie als "unallocated" an. Man kann die Reparatur über

Code: Alles auswählen

gdisk /dev/sda

expert options (Taste x) und relocate copy (Taste e) gefolgt vom erneuten Schreiben (Taste w) reparieren und dann ist gparted auch zufrieden.

Experte
Beiträge: 1443
Registriert: 04.10.2011, 14:06

Beitragvon JustMe » 05.03.2015, 10:39

~thc hat geschrieben:da sie keinerlei Informationen zur Gesamtgröße oder der ursprünglichen Zylinderzahl

Sorry, aber dem wuerde ich jetzt erst einmal vehement widersprechen, wenn wir unter dem Begriff "Partitiontabelle" dasselbe verstehen.

Die Partitiontabelle an sich enthaelt tatsaechlich keine Groessenhinweise (ohne Partitions kann sie aus "alles 0" bestehen), aber die Partitiontabellen-Eintraege enthalten sehr wohl Informationen zu C/H/S bzw. Blockanzahl. Und letztlich besteht die Partitiontabelle nur aus diesen Eintraegen.

Und ob eine partitionierte, und auf diese Weise "verkuerzte" Festplatte, als die sich die vmdk dem Gastbetriebssystem darstellt, auch wirklich immer sauber bearbeitet wird, duerfte ganz davon abhaengen, was genau man damit anstellt ;-)

Solange die von continuum et.al. angegebenen Sicherheitshinweise beachtet werden, und die eingerichteten Partitions auf der vmdk auch wirklich saemtlich *vor* dem ausgenullten Block enden, sollte alles ok bleiben. Aufpassen solte man da insbesondere bei der Verwendung von "Erweiterten" Partitions (0x05/0x0F), die nicht komplett belegt sind...

Experte
Beiträge: 1956
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 05.03.2015, 10:58

Stimmt. Genauer ausgedrückt:

In der MS-DOS-Partitionstabelle sind bei der Verwendung von primären Partitionen nach dem Verkleinern der Partition keine CHS-Werte mehr zu finden, die über die Zylinderanzahl der gekürzten Festplatte hinaus zeigen. Somit ist nach dem Kürzen der VMDK eine solche Partitonstabelle unverändert gültig.

Dein Einwand mit der erweiterten und logischen Partitionen ist richtig.


Zurück zu „vSphere 5.5 / ESXi 5.5“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast