conf: don't fail to parse <boot> when parsing a single device
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=895294 The symptom was that attempts to modify a network device using virDomainUpdateDeviceFlags() would fail if the original device had a <boot> element (e.g. "<boot order='1'/>"), even if the updated device had the same <boot> element. Instead, the following error would be logged: cannot modify network device boot index setting It's true that it's not possible to change boot order (internally known as bootIndex) of a live device; qemuDomainChangeNet checks for that, but the problem was that the information it was checking was incorrect. Explanation: When a complete domain is parsed, a global (to the domain) "bootMap" is passed down to the parse for each device; the bootMap is used to make sure that devices don't have conflicting settings for their boot orders. When a single device is parsed by itself (as in the case of virDomainUpdateDeviceFlags), there is no global bootMap that would be appropriate to send, so NULL is sent instead. However, although the lowest level function that parses just the boot order *does* simply skip the sanity check in that case, the next higher level "virDomainDeviceInfoParseXML" function refuses to call down to the lower "virDomainDeviceBootParseXML" if bootMap is NULL. So, the boot order is never set in the "new" device object, and when it is compared to the original (which does have a boot order), they don't match. The fix is to patch virDomainDeviceInfoParseXML to not care about bootMap, and just always call virDomainDeviceInfoBootParseXML whenever there is a <boot> element. When we are only parsing a single device, we don't care whether or not any specified boot order is consistent with the rest of the domain; we will always do this check later (in the current case, we do it by verifying that the net bootIndex exactly matches the old bootIndex).
Showing
想要评论请 注册 或 登录