Disk image maken van bestaande hd voor gebruik met Qemu

[ph0t0nix]

Ik heb hier een Slackware servertje staan met daarin twee 160GB SATA harddisks in software RAID1. Ik heb twee grotere harddisks (320GB) gekocht voor deze server, ter vervanging van de bestaande. Omdat de Slack installatie al behoorlijk oud aan het worden is en ik onder de indruk ben geraakt van Debians package management wilde ik deze hardware upgrade aanpakken om ook de software te upgraden.
Daarom heb ik de twee nieuwe disks tijdelijk in een oude PC gehangen en daar Debian Etch op geinstalleerd. Omdat ik weinig (aaneengesloten) tijd heb om alle services van de oude server te migreren en toch zo min mogelijk downtime wil hebben, lijkt het me een aardig plan om de (enigszinds uitgeklede) slackware server als Qemu virtual machine onder debian te draaien (die dan op de echte server hardware draait).

Om dat voor elkaar te krijgen moet ik de verschillende partities van de slackware disks overzetten naar een image bestand dat Qemu kan lezen. Nu lijkt me dat het makkelijkst door te kiezen voor het raw formaat, zodat ik de image gewoon met dd kan maken.

Het probleem is echter dat de harddisks verdeeld zijn in meerdere partities die niet allemaal mee in de image hoeven te komen (mijn muziekcollectie en /home bijvoorbeeld kan ik met rsync zo overzetten op de debian disks). Ander is de 320GB nogal gauw vol .
Omdat de qemu image toch al op de twee debian disks komt te staan is RAID1 in Qemu niet echt meer nodig.
Slackware disk indeling:
/ staat op /dev/md1 en is ~10G
/boot staat op /dev/md0 en is ~40MB
verder staan er nog zaken als /var en /tmp in /dev/md2, die verder ingedeeld is met LVM2.
Om het mezelf niet veel moeilijker te maken, wil ik alle belanrgijke LVM2 lv's kopieren naar /. Dat geld ook voor /boot. Daar is genoeg ruimte voor op /dev/md1.

Volgens mij moet ik daarna alleen nog /dev/md1 met dd naar een image bestand sturen. Alleen mis ik dan nog een ding: het image bestand zal geen MBR en geen partitie bevatten. In plaats van /dev/hda1 zal ik dan in Qemu /dev/hda moeten mounten. Dat wordt volgens mij een probleem. En zonder MBR zal booten ook wel niet lukken.

Mijn vraag: hoe kan ik de huidge MBR en een partitie (/dev/md1) van mijn huidige schijven in een enkel image bestand voor Qemu krijgen? Vervolgens moet er ook nog wat ruimte voor een swap partitie ingebakken worden...

[deadinspace]

Volgensmij kun je dan het beste zorgen voor een HD image met partitie en MBR en al, dat zal in qemu waarschijnlijk het minste geklooi geven. De vraag is alleen hoe je dat het beste voor elkaar krijgt, want volgensmij wordt het benaderen van die partities in die image niet zo makkelijk. Misschien dat je iets met een loop device kunt.

Maar...

ph0t0nix schreef op maandag 03 december 2007 @ 16:47:
Ik heb hier een Slackware servertje staan met daarin twee 160GB SATA harddisks in software RAID1. Ik heb twee grotere harddisks (320GB) gekocht voor deze server, ter vervanging van de bestaande.

Is het dan niet handiger om zowel de nieuwe als de oude harddisks in de server te zetten, en dan de twee oude harddisks op te geven als harddisks voor qemu? Slackware draait dan gewoon van de twee oude disks, met MBR, RAID, LVM en al, alleen dan gevirtualiseerd in qemu.

[ph0t0nix]

deadinspace schreef op maandag 03 december 2007 @ 18:24:
Misschien dat je iets met een loop device kunt.

Hmm, daar ga ik eens over nadenken!

Is het dan niet handiger om zowel de nieuwe als de oude harddisks in de server te zetten, en dan de twee oude harddisks op te geven als harddisks voor qemu? Slackware draait dan gewoon van de twee oude disks, met MBR, RAID, LVM en al, alleen dan gevirtualiseerd in qemu.

Dat is idd handiger, maar ik kom dan een SATA aansluiting te kort (tenzij ik de Slackware RAID array natuurlijk degraded draai) omdat ik ook nog een losse 400GB SATA disk in de server heb zitten voor backups en m'n MythTV opnamen.
Daarnaast wil ik de 160GB disks gaan verkopen, maar dat heeft niet zoveel haast.

[deadinspace]

ph0t0nix schreef op maandag 03 december 2007 @ 18:55:
Hmm, daar ga ik eens over nadenken!

http://edseek.com/~jasonb/articles/linux_loopback.html is de URL die ik tegenkwam. Het lijkt me niet echt triviaal, maar wel mogelijk.

Alternatief zou je de image kunnen partitioneren vanuit een OS geboot in qemu, en daar zo ook de relevante dingen in kunnen kopieren.

Dat is idd handiger, maar ik kom dan een SATA aansluiting te kort (tenzij ik de Slackware RAID array natuurlijk degraded draai)

Het is een beetje de vraag hoe lang je migratie-traject moet gaan duren. Als het maar kortstondig is, dan is dat array degraded draaien best een werkbare oplossing (zeker omdat je altijd de andere disk nog hebt als backup).

Alleen als je dan - om wat voor reden dan ook - weer terug wil vallen op je oude Slackware systeem (niet gevirtualiseerd, draaiend vanaf RAID) moet je goed oppassen dat het resyncen de juiste disk overschrijft.

Als nog een alternatief kun je misschien een image maken van één van de 160GB disks, en die aan qemu/Slackware voeren. Dan kun je allerlei grote dingen eraf kopieren en proberen in Slackware je filesystems / partities / volumes / raidsets online te verkleinen. Daarna moet het ook wel mogelijk zijn de hd image kleiner te maken, zodat het niet zoveel van je 320GB opslokt. Ik vrees alleen dat dat online geverklein nog wat voeten in aarde kan hebben.

[ph0t0nix]

Al nadenkend typte ik:

Alternatief zou je de image kunnen partitioneren vanuit een OS geboot in qemu, en daar zo ook de relevante dingen in kunnen kopieren.

Dat lijkt in eerste instantie de beste optie. Dan hoef ik niet eens een raw image te gebruiken en kan ik gewoon een qcow2 formaat gebruiken. Als ik dan van een liveCD boot waarmee de boel partitioneer, kan ik vervolgens NFS mounts gebruiken. Dan is het een kwestie van cp -a van de relevante directories en vervolgens lilo aanpassen en runnen.
Uiteraard moet ik dat dan wel even voor elkaar zien te krijgen als het slackware systeem niet draait... Wellicht gewoon in runlevel 1. Hmm, maar dan heb je geen netwerk, dus geen NFS...

Het is een beetje de vraag hoe lang je migratie-traject moet gaan duren. Als het maar kortstondig is, dan is dat array degraded draaien best een werkbare oplossing (zeker omdat je altijd de andere disk nog hebt als backup).

Eigenlijk wil ik alles binnen een week migreren (een hoop is al gebeurd). Alleen de mailserver (Qmail) werkt nu perfect, en aangezien dat de belangrijkste taak is en ik nog geen tijd in postfix of exim heb gestoken, verwacht ik dat dat nog wel een hele tijd op Slack zal blijven draaien. Zeker omdat ik de komende maanden behoorlijk druk ben op het werk.

http://edseek.com/~jasonb/articles/linux_loopback.html is de URL die ik tegenkwam. Het lijkt me niet echt triviaal, maar wel mogelijk.

Ik heb de tekst even doorgelezen en het laatste gedeelte (over het extracten van een partitie uit een image file m.b.v. dd) lijkt me relevant en doenbaar. Daar ga ik eens mee prutsen. Als ik het goed begrepen heb was dat precies wat ik zocht: dd een offset meegeven van de partitie en dan het aantal sectoren dat 'ie moet lezen. Zo kan ik dd gaan vertellen dat 'ie vanaf het begin van de disk tot en met /dev/sda2 moet lezen. /dev/sda1 is onderdeel van /dev/md0, de /boot partitie en /dev/sda2 is onderdeel van /dev/md1, de / RAIDset. Vervolgens kan ik dat image dan aan qemu voeren, booten en dan zal 'ie /dev/sdb missen en in degraded RAID1 draaien, maar da's geen punt.

Ik ben benieuwd!

Alvast bedankt voor het meedenken!

[deadinspace]

ph0t0nix schreef op maandag 03 december 2007 @ 20:51:
Dat lijkt in eerste instantie de beste optie. Dan hoef ik niet eens een raw image te gebruiken en kan ik gewoon een qcow2 formaat gebruiken. Als ik dan van een liveCD boot waarmee de boel partitioneer, kan ik vervolgens NFS mounts gebruiken. Dan is het een kwestie van cp -a van de relevante directories en vervolgens lilo aanpassen en runnen.
Uiteraard moet ik dat dan wel even voor elkaar zien te krijgen als het slackware systeem niet draait... Wellicht gewoon in runlevel 1. Hmm, maar dan heb je geen netwerk, dus geen NFS...

Of je hangt (één van) de 160GB disks ook aan qemu, dan kun je de relevante partities in de live CD mounten en de inhoud kopieren.

Nou ik erover nadenk, als je toch alles in RAID1 hebt, dan kun je zelfs je Slackware server degrader verder laten draaien vanaf één disk, en dan van de andere disk in qemu op je gemak eraf halen wat je eraf wil halen.

In plaats van een live CD zou je ook tijdelijk nóg een disk image aan qemu kunnen hangen (hoeveel kan qemu er aan? ) en daarin een kleine Debian of Slackware install kunnen doen. Dat is misschien handiger, maar misschien ook niet.

Wat je ook doet, hou de inhoud van minstens één van je 160 GB disks veilig... Mocht er wat mis gaan ergens, dan ben je misschien heel erg blij met de inhoud daarvan

[ph0t0nix]

Ik heb net een dd image vanaf sector nul tot het einde van de tweede partitie gemaakt, zoals ik hierboven beschreef. De /boot partitie daarvan heb ik al succesvol gemount. Nu eens zien of de / ook wil...

Door alleen met dit image (op een externe USB disk) te werken hoef ik niet bang te zijn dat m'n "echte" slack install naar de haaien gaat.

Ha! Ook de / partitie kan ik mounten na het berekenen van de juiste sector .

En ook qemu start op als een tierelier . Man, wat zijn we goed !
Nou nog even vanuit runlevel 1 een net image maken waar ook /var netjes in zit (die staat nu nog op de lvm partitie) en dan kan de slack server virtueel gaan draaien.

Even een korte samenvatting voor later:
/dev/sda is lid van een RAID1 set. De eerste partitie is de /boot partitie, de tweede is /. /dev/sda3 is ook een RAID1 volume, maar dan met LVM2 indeling.
De wens was om /dev/sda{1,2} in een image te krijgen dat bruikbaar is voor qemu.
Dit is de partitieindeling:

# fdisk -l /dev/sda

Disk /dev/sda: 164.6 GB, 164696555520 bytes
255 heads, 63 sectors/track, 20023 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1           5       40131   fd  Linux raid autodetect
/dev/sda2               6        1222     9775552+  fd  Linux raid autodetect
/dev/sda3            1223       19457   146472637+  fd  Linux raid autodetect

# fdisk -l -u /dev/sda

Disk /dev/sda: 164.6 GB, 164696555520 bytes
255 heads, 63 sectors/track, 20023 cylinders, total 321672960 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63       80324       40131   fd  Linux raid autodetect
/dev/sda2           80325    19631429     9775552+  fd  Linux raid autodetect
/dev/sda3        19631430   312576704   146472637+  fd  Linux raid autodetect

De laatste geeft de partitiegrenzen in sectors, precies wat we willen. Het image maken gaat zo:

dd if=/dev/sda of=slackdis.raw bs=512 count=19631430

Ik heb de count met 1 verhoogd, zoals aangegeven in de link van deadinspace. Om te testen of de partities OK waren, heb ik ze even gemount:

 mount -o loop,offset=41126400 -t ext3 slackdis.raw /mnt/root
 mount -o loop,offset=32256 -t ext2 slackdis.raw /mnt/root/boot

De offsets zijn berekend door de groote van 1 sector in bytes (512) te vermenigvuldigen met de startsector van de gewenste partitie (dus 512 * 63 = 32256 voor de /boot partitie).

[ Voor 107% gewijzigd door ph0t0nix op 03-12-2007 22:41 ]