OVH Community, votre nouvel espace communautaire.

Transférer une grosse VM (792G) d'un serveur proxmox à un autre


absolom
17/04/2015, 15h32
Merci, je connais déjà ce script, intéressant au demeurant.

Je m'en suis finalement sorti en relançant un vzmigrate qui aura duré une 20aine d'heure, mais qui à finalement réussit.

merci @ tous.

devnull
14/04/2015, 23h31
Hello !

Citation Envoyé par absolom
Oui, j'utilise des openvz.
Mmmmh... Regarde l'outil "openvz-diff-backups" à tout hasard :

- http://projets.developpeur-neurasthenique.fr/

Si tu contactes l'auteur il pourra peut-être t'aider.

A+

Kioob
14/04/2015, 17h11
Bah... à ce que je sache, ce n'est pas lié justement. C'est pas parce qu'on utilise un conteneur qu'on est obligé de tout mélanger sur le disque.

absolom
14/04/2015, 16h29
Oui, j'utilise des openvz.

Kioob
14/04/2015, 16h15
Ouais, donc tu as un seul «LV» fourre-tout. Inutile et peu pratique. Oublie la solution via dd, désolé.

absolom
14/04/2015, 14h48
Je pense que tout est installé la dessus : /dev/mapper/pve-data

lvdisplay
--- Logical volume ---
LV Path /dev/pve/data
LV Name data
VG Name pve
LV UUID lTGz1u-50Ht-verG-AHdK-QtoE-smuW-DHz3Qz
LV Write Access read/write
LV Creation host, time rescue.ovh.net, 2013-07-04 12:51:57 +0200
LV Status available
# open 1
LV Size 1.70 TiB
Current LE 445693
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
vgdisplay
--- Volume group ---
VG Name pve
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 36767
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 1.80 TiB
PE Size 4.00 MiB
Total PE 471550
Alloc PE / Size 445693 / 1.70 TiB
Free PE / Size 25857 / 101.00 GiB
VG UUID cBGo1o-bzAV-UBkN-FJ43-dXh9-fRYt-NEv12w

captainadmin
14/04/2015, 14h48
Hello

dd est une commande pour migrer un fichier ou une partition bit à bit.
Tu peux aussi lancer la commander pour migrer ton fichier backup d'un serveur à un autre
Soit
dd if="fichier source" bs=4M | ssh SERVEUR-DESTINATION "dd of=fichier destination"
Soit en changeant la destination et en utilisant une partition local

l'option bs définit la taille de block transféré, il faut trouvé le juste milieu pour un transfert rapide sans erreur, perso j'aurai mis 1M mais avec 4M ca ira plus vite surtout vu la taille du fichier à transféré.

Bon courage

Kioob
14/04/2015, 14h41
Ça ne répond pas du tout à ma question.

Mais du coup, si tu ne sais pas comment sont stockées les VM, effectivement on ne va pas chercher à optimiser ça, sous peine de faire des bêtises.

absolom
14/04/2015, 14h22
C'est une installation standard proxmox ovh...

Kioob
14/04/2015, 14h13
Ça dépend... tu as mis toutes les VM sur la même partition ? Tu n'utilises pas LVM pour isoler tes VMs ?

absolom
14/04/2015, 14h12
En gros, ça transfert toutes les VM ça ?

Kioob
14/04/2015, 12h57
Pour transférer une partition LVM, ça donnerait :
Code:
dd if=/dev/mapper/PARTITION-SOURCE bs=4M | ssh SERVEUR-DESTINATION "dd of=/dev/mapper/PARTITION-CIBLE"
Et donc :
- oui ça tourne aussi vite que les disques et le réseau le permettent, ce qui peut fortement impacter les perfs
- ça écrase complètement la partition cible, sans possibilité de récupérer quoi que ce soit si tu t'es planté
- si fait à chaud, le résultat est corrompu, d'où la seconde passe de synchronisation

absolom
14/04/2015, 12h00
Je veux bien de l'aide pour le premier transfert avec dd, je connais pas du tout ...

absolom
14/04/2015, 11h49
Bon, ben ça vient de plante lamentablement au but de 3 jours ...

Apr 11 20:50:50 INFO: creating archive '/mnt/pve/vs2/dump/vzdump-openvz-205-2015_04_11-20_50_50.tar.lzo'
Apr 14 12:26:46 ERROR: Backup of VM 205 failed - command '(cd /var/lib/vz/private/205;find . '(' -regex '^\.$' ')' -o '(' -type 's' -prune ')' -o -print0|sed 's/\\/\\\\/g'|tar cpf - --totals --sparse --numeric-owner --no-recursion --one-file-system --null -T -|lzop) >/mnt/pve/vs2/dump/vzdump-openvz-205-2015_04_11-20_50_50.tar.dat' failed: interrupted by signal

Ca saoule ...

Si je synchronise que le /var/lib/vz/205/private, ça va le faire ? Et à côté, je récupère la conf de la VM qui est dans /etc/pve/openvz ?

absolom
14/04/2015, 09h26
Intéressant, merci.
Si, j'ai pas mal de VM sur ce serveur, mais cette grosse VM me ralenti tout (traitement d'images et de vidéo).
Je vais maintenant attendre la fin du vzdump actuel (693G la).
Si jamais ça foire, je testerais le dd et le script qui m'a pas l'air mal, mais ça va nuire aux performances des autres VM du coup non ?
A faire la nuit plutôt si jamais.

Kioob
14/04/2015, 07h53
Boh, j'ai quelques VM de plusieurs To, justement parce que sur dédié gérer la redondance n'était vraiment pas pratique. Du coup c'est avant tout un problème de choix de technologie (DRBD, RBD, etc).

Mais c'est un peu tard pour changer maintenant. Par contre, pour accélérer ton transfert tu peux utiliser une synchronisation de blockdevice, un peu comme rsync.
C'est à dire que tu fais un premier transfert «tranquillement», à chaud, avec dd. Une fois que c'est fait, tu coupes la VM, puis tu resynchronise au maximum de la vitesse des disques, tu en auras pour environ 2H.

Exemple :
Code:
LOCAL_READ_DEVICE=/dev/XXX;REMOTE_WRITE_DEVICE=/dev/XXX;REMOTE_HOST=xxx;\

ssh $REMOTE_HOST "perl -'MDigest::MD5 md5' -ne 'BEGIN{\$/=\1024};print md5(\$_)' $REMOTE_WRITE_DEVICE | lzop -c" |\
    lzop -dc | perl -'MDigest::MD5 md5' -ne 'BEGIN{$/=\1024};$b=md5($_); read STDIN,$a,16;if ($a eq $b) {print "s"} else {print "c" . $_}' $LOCAL_READ_DEVICE | lzop -c |\
    ssh $REMOTE_HOST "lzop -dc | perl -ne 'BEGIN{\$/=\1} if (\$_ eq\"s\") {\$s++} else {if (\$s) { seek STDOUT,\$s*1024,1; \$s=0}; read ARGV,\$buf,1024; print \$buf}' 1<> $REMOTE_WRITE_DEVICE"
Source : http://www.mail-archive.com/rsync@li.../msg25887.html

captainadmin
13/04/2015, 16h40
En effet la question de base est pourquoi pas être sur un serveur dédié ?
Je suppose qu'il n'y a pas beaucoup d'autres vm sur ton serveur.

Impossible d'exporter un backup et impossible à migrer facilement, tu as perdu les 2 principaux avantages de la virtualisation.

Bon courage pour le temps qu'il reste de migration

absolom
13/04/2015, 16h33
C'est pas faux ...

NicolasFR
13/04/2015, 16h23
Citation Envoyé par absolom
Mais je trouve ça vraiment long,
792 G, faut pas non plus t'attendre à un truc trop rapide...
D'ailleurs, je vois pas trop l’intérêt d'une VM rendu à une taille de ce niveau puisque ça sera impossible à migrer rapidement ?!

absolom
13/04/2015, 15h06
Non, pas de backup sur cette vm car trop long justement ...
J'ai lancé un vzmigrate qui plante toujours à 64Go, même avec un répertoire temporaire pour rsync.

J'ai lancé un vzdump sur un réertoire du serveur de destinaton partagé en NFS samedi soir qui tourne toujours, mais c'est lent ... 500 G actuellement, il reste à arriver à 792 puis à faire la compression ... Et si ça se passe bien, un vzrestore .

Mais je trouve ça vraiment long, le vzmigrate allait bien plus vite.

buddy
10/04/2015, 20h44
Citation Envoyé par absolom
Merci pour vos réponses.
Quand vous parlez de dump avec rsync, c'est quoi au juste ?

Vous me conseillez de faire un vzdump directement sur le partage, c'est ça ?

Je vais tester avec le partage NFS et je vous dis ça, merci.

Aurélien.

tu fais des backups de ta VM de temps en temps ?
Si oui ensuite, tu "envoies" le fichier backup sur ton nouveau serveur via Rsync ou SCP par exemple. (je préfère nettement rsync)

captainadmin
10/04/2015, 19h48
Et pour faire plus ou moins aussi simple,

Pourquoi ne pas générer une nouvelle vm sur ton nouvelle hyperviseur et synchroniser les données entre les vm.
Je supposer que les 750G ne sont pas un seul meme et gros fichier.
De même, il n'y a pas moyen d'alléger ta vm pour qu'elle prenne moins de place sur le file system ?

Bon courage

absolom
10/04/2015, 18h42
Bon, pas mieux en NFS ...

Apr 10 18:16:09 INFO: Total bytes written: 21345361920 (20GiB, 1.6MiB/s)
Apr 10 18:16:09 INFO: tar: Exiting with failure status due to previous errors
Apr 10 18:17:12 ERROR: Backup of VM 205 failed - command '(cd /mnt/vzsnap0/private/205;find . '(' -regex '^\.$' ')' -o '(' -type 's' -prune ')' -o -print0|sed 's/\\/\\\\/g'|tar cpf - --totals --sparse --numeric-owner --no-recursion --one-file-system --null -T -|lzop) >/mnt/pve/vs2/dump/vzdump-openvz-205-2015_04_10-14_33_58.tar.dat' failed: exit code 2

J'étais en snapshot, je vais tester en mode stop pour voir si c'est mieux.

absolom
10/04/2015, 08h14
Merci pour vos réponses.
Quand vous parlez de dump avec rsync, c'est quoi au juste ?

Vous me conseillez de faire un vzdump directement sur le partage, c'est ça ?

Je vais tester avec le partage NFS et je vous dis ça, merci.

Aurélien.

captainadmin
09/04/2015, 19h25
Hello,

As-tu besoin que la vm soit fonctionnelle le temps de l'opération?
Ya plusieurs solutions pour ton problème.

Perso je ferais un partage nfs ou sshfs entre tes 2 serveurs, et je synchroniserais la sauvegarde vers ce partage de fichier.
Si ca marche pas à cause d'un "broken pipe" tu peux faire directement la sauvegarde sur le partage de fichier.
Pour le aider le rsync tu peux utiliser
rsync -razv --temp-dir=/var/tmp/rsync
Forcer un répertoire temporaire ca peut aider, surtout pour de gros volumes.

Bon courage
http://www.captainadmin.com

bbr18
09/04/2015, 19h11
et un dump ça ne passe pas non plus avec rsync ?

absolom
09/04/2015, 18h37
Bonjour @ tous,

J’essaie de transférer une VM en vain, d'un serveur ovh à un autre serveur ovh, mais ça plante à chaque fois.
J'ai testé vzmigrate, mais j'ai du broken pipe au bout d'un moment :

vzmigrate --live -vvvv -r no XX.XX.XX.XX 100

Idem avec rsync, ça ne suit pas et plante au bout d'un moment.

Des idées ?

La VM à transférer est énorme (792G) avec pleins de fichiers.

Merci d'avance,

Aurélien.