[libvirt] [PATCH] qemu: don't fail update netdev on bridge detach failure
When a network device's bridge connection is changed by virDomainUpdateDevice, libvirt first removes the netdev's tap from its old bridge, then adds it to the new bridge. Sometimes, due to a network being destroyed while a guest device is still attached, the tap may already be "removed" from the old bridge (or the old bridge may not even exist any more); the existing code was needlessly failing the update when this happened, making it impossible to recover from the situation without completely detaching (i.e. removing) the netdev from the guest and re-attaching. Instead of failing the entire operation when removal of the tap from the old bridge fails, this patch changes qemuDomainChangeNetBridge to just log a warning and continue, allowing a reasonable recover from the situation. (you'll appreciate this change if you ever accidentally destroy a network while your guests are still using it). --- src/qemu/qemu_hotplug.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 3dfdb65..e9a5e35 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1306,8 +1306,14 @@ qemuDomainChangeNetBridge(virConnectPtr conn, if (oldbridge) { ret = virNetDevBridgeRemovePort(oldbridge, olddev->ifname); virDomainAuditNet(vm, olddev, NULL, "detach", ret == 0); - if (ret < 0) - goto cleanup; + if (ret < 0) { + /* warn but continue - possibly the old network + * had been destroyed and reconstructed, leaving the + * tap device orphaned. + */ + VIR_WARN("Unable to detach device %s from bridge %s", + olddev->ifname, oldbridge); + } } ret = virNetDevBridgeAddPort(newbridge, olddev->ifname); -- 1.7.11.7
On 12/13/2012 05:40 PM, Laine Stump wrote:
When a network device's bridge connection is changed by virDomainUpdateDevice, libvirt first removes the netdev's tap from its old bridge, then adds it to the new bridge. Sometimes, due to a network being destroyed while a guest device is still attached, the tap may already be "removed" from the old bridge (or the old bridge may not even exist any more); the existing code was needlessly failing the update when this happened, making it impossible to recover from the situation without completely detaching (i.e. removing) the netdev from the guest and re-attaching.
Instead of failing the entire operation when removal of the tap from the old bridge fails, this patch changes qemuDomainChangeNetBridge to just log a warning and continue, allowing a reasonable recover from the situation.
(you'll appreciate this change if you ever accidentally destroy a network while your guests are still using it).
Hmm, I think that may have happened to me while testing dnsmasq fixes lately, and I probably just chalked it up to user error...
--- src/qemu/qemu_hotplug.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
Matches the commit message, which makes sense. ACK. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 12/13/2012 07:44 PM, Eric Blake wrote:
On 12/13/2012 05:40 PM, Laine Stump wrote:
When a network device's bridge connection is changed by virDomainUpdateDevice, libvirt first removes the netdev's tap from its old bridge, then adds it to the new bridge. Sometimes, due to a network being destroyed while a guest device is still attached, the tap may already be "removed" from the old bridge (or the old bridge may not even exist any more); the existing code was needlessly failing the update when this happened, making it impossible to recover from the situation without completely detaching (i.e. removing) the netdev from the guest and re-attaching.
Instead of failing the entire operation when removal of the tap from the old bridge fails, this patch changes qemuDomainChangeNetBridge to just log a warning and continue, allowing a reasonable recover from the situation.
(you'll appreciate this change if you ever accidentally destroy a network while your guests are still using it). Hmm, I think that may have happened to me while testing dnsmasq fixes lately, and I probably just chalked it up to user error...
Depends on your definition of user error :-) If you stop and start a network that has guests attached, the guests will not be reattached to the bridge. In order to restore proper operation, you'll need to update-device each network device moving it to a different bridge, then back to the original.
--- src/qemu/qemu_hotplug.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) Matches the commit message, which makes sense. ACK.
Pushed. Thanks!
participants (2)
-
Eric Blake -
Laine Stump