Creation and migration flows VDSM Creation and migration flows March 12, 2014 Francesco Romani

Agenda VM startup flows Creation Recovery Dehibernate/restore Migration Code walkthrough: http://www.ovirt.org/VDSM_VM_startup

VM Creation API verb: “create” translate the device representation (buildConfDevices) normalization of devices and enforcing the device limits setup of the drive paths/images build libvirt XML create the libvirt Domain

VM Creation /2 perform post-creation domain checks start the statistics gathering thread, one per VM connect to Guest Agent handle paused VM (disk space exausted) set up niceness and guest scheduler parameters if the VM was paused, recover the pause code; extend the VM drives if needed (...again.) [all of this is shared with the other flows]

VM Recovering carried automatically by VDSM (no API verb) VM running in an host should not be affected by VDSM restarts, and they should continue to run. when VDSM returns up, it resyncs with the running VMs to regain the control. uses the data saved by the saveState call to restore most of its internal state, and merges those informations with the data provided by libvirt. libvirt is authoritative about existing Vms. skips many startup errors to avoid to get stuck on the recovery of a single unresponsive VM. Recover as much as is possible.

VM Dehibernation/snapshot restoring API verb: “hibernate” (check the parameters) implemented as special case of migration recycling of the snapshotting infrastructure updates configuration from reference (“source”) XML (e.g. the backing store paths) reattaches to the domain by UUID resume the suspended the domain

VM Migration API verb: “migrate” background: libvirt/qemu peer to peer flow delegation chain: VDSM -> libvirt -> QEMU the source is in control the ownership of the VM is passed from source to destination host after a successful migration if migration fails, the source keeps running and the destination is trasparently (= without explicit user intervention) destroyed.

VM Migration /2 a migration is managed by a service thread, MigrationSourceThread, with the help of more threds MigrationMonitorThread polls libvirt periodically and report the migration progress MigrationDowntimeThread controls the maximum allowed downtime and updates libvirt during the migration.

VM Migration /3 MigrationSourceThread flow: Connects to destination host prepares the destination machine parameters from the migration source creates the destination VM, empty. Here on the destination hosts starts the 'Migration Destination' startup flow run the Downtime control and the Migration Monitor threads. starts the actual migration using libvirt saves the Source VM state and puts it Down

VM Migration /4 API verb: “migrationCreate” (internal) preparation steps compute the migration timeout and wait for VM to come up, either by libvirt notification (successfull migration or error) or by timeout expiration. Now the destination VM is created and running, and it is ready to receive (or already been receiving) such data. receives the actual data (memory)

Refactoring vm.py the virt package sampling.py vm.py vm*.py split out devices in a subpackage [?] clean the libvirt integration (pubsub) [?] per-flow (= verb) split split out threads migration