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
- Super doc d'Ovirt à propos des contextes/migrations
- Bug posé à l'origine sur nova
- Migration en mode blocopy
- Et w/o shared
- Quelques flags intéressants
- Optims de sync pour les rbases
- Différences p2p/tun