Could it be that this fix introduced the behavior below?
1. Build a VM OS Debian : instances.root_device_name = /dev/sda
2. Attach a volume to the instance
3. Rebuid this VM with OS Ubuntu : instances.root_device_name is still /dev/sda while in the VM itself it is now /dev/vda
4. The volume is no longer attached and fails with
Failed to attach f3c12921-66ab-47b4-99dc-ed2dc67c32ba at /dev/vda: libvirt.libvirtError: internal error: unable to execute QEMU command 'device_add': Duplicate ID 'virtio-disk0' for device
This fixes the issue :
MariaDB [novadb]> UPDATE instances SET root_device_name="/dev/vda" WHERE uuid='f6a607aa-7142-47ba-a87a-e027c0b58dbb' LIMIT 1;
Hi,
Hi,
Could it be that this fix introduced the behavior below?
1. Build a VM OS Debian : instances. root_device_ name = /dev/sda root_device_ name is still /dev/sda while in the VM itself it is now /dev/vda
2. Attach a volume to the instance
3. Rebuid this VM with OS Ubuntu : instances.
4. The volume is no longer attached and fails with
Failed to attach f3c12921- 66ab-47b4- 99dc-ed2dc67c32 ba at /dev/vda: libvirt. libvirtError: internal error: unable to execute QEMU command 'device_add': Duplicate ID 'virtio-disk0' for device
This fixes the issue : name="/ dev/vda" WHERE uuid='f6a607aa- 7142-47ba- a87a-e027c0b58d bb' LIMIT 1;
MariaDB [novadb]> UPDATE instances SET root_device_