KVM: if a volume is detached before OS has boot and migrated, admin not able to attach back #3290
Description
ISSUE TYPE
- Bug Report
COMPONENT NAME
Volumes, VM deployment
CLOUDSTACK VERSION
4.11
CONFIGURATION
OS / ENVIRONMENT
Observed with KVM, should be agnostic of distro and version. We tested on:
# virsh version
Compiled against library: libvirt 4.5.0
Using library: libvirt 4.5.0
Using API: QEMU 4.5.0
Running hypervisor: QEMU 1.5.3
# cat /etc/centos-release
CentOS Linux release 7.4.1708 (Core)
# uname -a
Linux <stripped> 3.10.0-693.11.1.el7.x86_64 #1 SMP Mon Dec 4 23:52:40 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
SUMMARY
When a user creates a VM without starting it, and then start and detach the volume before the guest OS has booted, post migration the volume cannot be attached back.
STEPS TO REPRODUCE
1. Create a VM with a data disk without starting it
2. Start the VM
3. Before the VM has booted, detach the disk
4. Migrate the data disk to another storage pool
5. Try to attach back the volume to the same VM
EXPECTED RESULTS
Volume being attached
ACTUAL RESULTS
Failed to attach volume test to VM VM-827b8faf-4ed6-414b-9c4f-29c7dcefd06c; org.libvirt.LibvirtException: XML error: target 'vdb' duplicated for disk sources '/mnt/610e0939-6665-311d-9401-bdcd354a275c/96912f59-95a5-458b-81c2-3e91c0687799' and '/mnt/610e0939-6665-311d-9401-bdcd354a275c/21d022d9-a2ba-4db0-acb4-e8f3044239c0'
It seems that the old record is not properly cleaned up when the volume is detached, and post migration we got a new path which creates a conflict and cloudstack is not able to attach the volume.
Workaround:
This could be escaped if the user waits enough for the Guest OS to boot. After that detaching seems to be cleaning properly the records.
Another way if the VM is already messed is to Stop and Start the VM, after that user is able to attach the volume.
Reactions are currently unavailable