xen (live) migration/suspend/resume is incompatible with disk/nic attach/detach
|Assignee:||Javi Fontan||% Done:|
|Category:||Drivers - VM|
|Target version:||Release 5.0|
|Affected Versions:||OpenNebula 4.10|
If xen (4.4.1) VM has dynamically attached disk and do live migration, then attached disk is lost in VM.
If we detach disk and do live migration, then VM fails (go to UNKNOWN state).
The cause of problem is that attach/detach doesn't update VM config file deployment.X - live migration use it when restoring.
If we poweroff and resume VM before live migration, then it works as expected, because VM config file deployment.X is updated/regenerated.
The same problem could be for NICs and cold migration and suspend/resume.
#2 Updated by Ruben S. Montero about 6 years ago
- Status changed from Pending to New
- Target version set to Release 4.14
Moving this to 4.14. My preferred way to handle this is to re-generate the deployment file server side. This is done in multiple operations but not for live migrate; my proposal is to:
1.- Update the migrate API call to generate the deployment file including any attached device
2.- Update the live-migrate operation to fetch the deployment file (same as deploy)
THANKS for the feedback!!
#3 Updated by Rolandas Naujikas about 6 years ago
We should update deployment.* on disk attach/detach and run xl config-update, because xen block-attach/detach is volatile (probably xen bug).
If we reboot VM, then attached disk could be lost, because xen recreates VM from original config file (or internal copy).
We can look how libvirt solves similar problem for kvm. Also recent libvirt version supports xen already.