Sebastien Badia Engineer @eNovance, Puppet addict and Net Neutrality defender.
Published

Wed 06 August 2014

←Home

OpenStack block migration

Contexte

Niveau contexte, la plateforme en place n'utilise pas de shared-storage, mais les images sont au format qcow2 avec un backing_file ce qui permet d'avoir une image bien sparsé.

Lors d'une migration via nova/libvirt en mode block le comportement observé est un merge de l'image transférée + du backing_file + reste de l'image en mode raw (si on a une image non sparsé de 20Go, alors 20Go de zéro transitent sur le réseau, l'image n'est pas re-sparsifié de l'autre coté), mais la migration fonctionne.

Analyse

Les flags de live-migration par défaut dans nova icehouse (version 2014.1-2~bpo2012.04+1) sont VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER donc pas de « vraie » live-migration. Nova dispose de flags différents pour la migration en mode block les defaults étant VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER, VIR_MIGRATE_NON_SHARED_INC

Le cycle de live migration en mode block fait appel directement à libvirt à travers la méthode migrateToURI (ce qui est corroboré avec un simple lsof sur le disk qcow2 de destination/départ lors de la migration).

Au niveau des flags libvirt intéressant (dans le code actuel) il y a le VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT, cf la ML libvirt archives2012

« Management applications can pre-create the copy with a relative backing file name, and use the VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT flag to have qemu reuse the metadata; if the management application also copies the backing files to a new location, this can be used to perform live storage migration of an entire backing chain. »

Mais même comportement, avec une combinaison de VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_SHALLOW en gardant en mémoire de s'assurer que le backing_file était présent sur les différents computes (ce qui n'est pas le cas lorsque aucune image du même « type » n'a été booté sur le compute…), cette combinaison fonctionne (sans non-shared storage incrémental (VIR_MIGRATE_NON_SHARED_INC)).

Nova dispose d'une boucle de code pour synchroniser/vérifier que les rbase sont présent sur les compute, nous faisons donc le test d'évacuer un compute, booter une vm sur le deuxième et avant la migration, de supprimer les rbase (backing) et enfin de lancer la migration. Résultat tout se passe comme convenu, nova transfère le rbase correspondant avant la migration.

Tests

block_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_DOMAIN_BLOCK_REBASE_COPY,VIR_DOMAIN_BLOCK_REBASE_SHALLOW

Nova boot en précisant le compute (histoire de pouvoir tuer le rbase) (--availability_zone nova:compute-01) verif du qcow2.

qemu-img info /var/lib/nova/instances/<id>/disk

Identification du backing_file et remove sur la dest

mv /var/lib/nova/instances/_base/c99ee4f8dc122039d37be31ef5064345acf886be{,.back}

Puis migration:

nova live-migration --block-migrate myvm

Verifications du qcow2 et du backing (il est recré), donc pas d'effets de bord de la suppression du flag INC, et pas de soucis si le rbase est pas présent.

Littérature / pointeurs

Go Top