Red Hat Bugzilla – Bug 1248514
cannot hotplug device with <boot order=X/> to VM with no devices, because XML defaults to <boot dev='hd'/>
Last modified: 2016-05-16 00:24:58 EDT
Description of problem: When a domain with no devices is created, libvirt explicitly adds "<boot dev='hd'>" to the domain definition. If one then tries to attach a device with a "<boot index='1'>", this fails. When one tries to redefine the domain XML without the "<boot dev='hd'>" element, libvirt simply readds it, so it cannot be removed before calling virDomainAttachDeviceFlags. This causes the problem where a domain created with no NICs and no drives cannot have any devices attached with a boot index definition through virDomainAttachDeviceFlags. Version-Release number of selected component (if applicable): Tested on 1.2.16 How reproducible: 100% of the time Steps to Reproduce: 1. echo '<domain type="kvm"> <name>myvm</name><memory unit="KiB">200000</memory><os><type arch="x86_64">hvm</type></os></domain>' > /tmp/myvm.yml 2. virsh create /tmp/myvm.yml 3. echo "<interface type='network'><source network='default'/><target dev='vnet0'/><alias name='net0'/><model type='virtio'/><boot order='1'/></interface>" > /tmp/myvm-nic.xml 4. virsh attach-device myvm /tmp/myvm-nic.xml 5. virsh dumpxml --inactive --security-info myvm | grep -v 'boot dev' > /tmp/myvm-nobootdev.xml 6. virsh define /tmp/myvm-nobootdev.xml 7. virsh attach-device myvm /tmp/myvm-nic.xml Actual results: error: unsupported configuration: per-device boot elements cannot be used together with os/boot elements Expected results: The explicitly added "<boot dev='hd'>" gets removed and an interface gets added with "<boot index='1'>" Additional info:
These are some possible solutions: - Allow the removal of "<os><boot dev='foo'/></os>" element through XML redefinition (detect that it was explicitly removed by the user) - Allow the removal of "<os><boot dev='foo'/></os>" element through an API method - Internally remove "<os><boot dev='foo'></os>" when a device gets attached with a defined "<boot order='foo'/>" (this assumes that whoever attaches that device takes responsibility for boot ordering) I do not see a use case where the device attachment should be refused (and the os boot element kept) when a device gets attached with a defined boot order, so that seems preferable to me, but I could be missing something.
We could probably special case it: when there's no other bootable devices attached to the VM, have <boot order=X/> override the default <boot dev='hd'/> setting