[libvirt] [PATCH v2] qemu: clean up network interfaces before qemuProcessKill is called in qemuProcessStop

In qemuProcessStop we explicitly remove the port from the openvswitch bridge after qemuProcessKill is called. But there is a certain interval of time between deleting tap device and removing it from bridge. The problem occurs when two vms start and shutdown with the same name's network interface attached to the same openvswitch bridge. When one vm with the nic named "vnet0" stopping, it deleted tap device without timely removing the port from bridge. At this time, another vm created the tap device named "vnet0" and added port to the same bridge. Then, the first vm removed the port from the same bridge. Finally, the tap device of the second vm did not attached to the bridge. We need to delete the bridge port before deleting the tap device instead of after. So what's needed is to move the loop in qemuProcessStop that cleans up network interfaces so that it happens before qemuProcessKill is called. Signed-off-by: Zhipeng Lu <lu.zhipeng@zte.com.cn> Signed-off-by: Laine Stump <laine@laine.org> --- src/qemu/qemu_process.c | 99 ++++++++++++++++++++++++------------------------- 1 file changed, 49 insertions(+), 50 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 53170d7..f76ced1 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -6253,56 +6253,6 @@ void qemuProcessStop(virQEMUDriverPtr driver, qemuProcessCleanupChardevDevice, NULL)); - - /* shut it off for sure */ - ignore_value(qemuProcessKill(vm, - VIR_QEMU_PROCESS_KILL_FORCE| - VIR_QEMU_PROCESS_KILL_NOCHECK)); - - qemuDomainCleanupRun(driver, vm); - - /* Stop autodestroy in case guest is restarted */ - qemuProcessAutoDestroyRemove(driver, vm); - - /* now that we know it's stopped call the hook if present */ - if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) { - char *xml = qemuDomainDefFormatXML(driver, vm->def, 0); - - /* we can't stop the operation even if the script raised an error */ - ignore_value(virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, - VIR_HOOK_QEMU_OP_STOPPED, VIR_HOOK_SUBOP_END, - NULL, xml, NULL)); - VIR_FREE(xml); - } - - /* Reset Security Labels unless caller don't want us to */ - if (!(flags & VIR_QEMU_PROCESS_STOP_NO_RELABEL)) - qemuSecurityRestoreAllLabel(driver, vm, - !!(flags & VIR_QEMU_PROCESS_STOP_MIGRATED)); - - qemuSecurityReleaseLabel(driver->securityManager, vm->def); - - for (i = 0; i < vm->def->ndisks; i++) { - virDomainDeviceDef dev; - virDomainDiskDefPtr disk = vm->def->disks[i]; - - dev.type = VIR_DOMAIN_DEVICE_DISK; - dev.data.disk = disk; - ignore_value(qemuRemoveSharedDevice(driver, &dev, vm->def->name)); - } - - /* Clear out dynamically assigned labels */ - for (i = 0; i < vm->def->nseclabels; i++) { - if (vm->def->seclabels[i]->type == VIR_DOMAIN_SECLABEL_DYNAMIC) - VIR_FREE(vm->def->seclabels[i]->label); - VIR_FREE(vm->def->seclabels[i]->imagelabel); - } - - virStringListFree(priv->qemuDevices); - priv->qemuDevices = NULL; - - qemuHostdevReAttachDomainDevices(driver, vm->def); - def = vm->def; for (i = 0; i < def->nnets; i++) { virDomainNetDefPtr net = def->nets[i]; @@ -6360,6 +6310,55 @@ void qemuProcessStop(virQEMUDriverPtr driver, networkReleaseActualDevice(vm->def, net); } + /* shut it off for sure */ + ignore_value(qemuProcessKill(vm, + VIR_QEMU_PROCESS_KILL_FORCE| + VIR_QEMU_PROCESS_KILL_NOCHECK)); + + qemuDomainCleanupRun(driver, vm); + + /* Stop autodestroy in case guest is restarted */ + qemuProcessAutoDestroyRemove(driver, vm); + + /* now that we know it's stopped call the hook if present */ + if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) { + char *xml = qemuDomainDefFormatXML(driver, vm->def, 0); + + /* we can't stop the operation even if the script raised an error */ + ignore_value(virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, + VIR_HOOK_QEMU_OP_STOPPED, VIR_HOOK_SUBOP_END, + NULL, xml, NULL)); + VIR_FREE(xml); + } + + /* Reset Security Labels unless caller don't want us to */ + if (!(flags & VIR_QEMU_PROCESS_STOP_NO_RELABEL)) + qemuSecurityRestoreAllLabel(driver, vm, + !!(flags & VIR_QEMU_PROCESS_STOP_MIGRATED)); + + qemuSecurityReleaseLabel(driver->securityManager, vm->def); + + for (i = 0; i < vm->def->ndisks; i++) { + virDomainDeviceDef dev; + virDomainDiskDefPtr disk = vm->def->disks[i]; + + dev.type = VIR_DOMAIN_DEVICE_DISK; + dev.data.disk = disk; + ignore_value(qemuRemoveSharedDevice(driver, &dev, vm->def->name)); + } + + /* Clear out dynamically assigned labels */ + for (i = 0; i < vm->def->nseclabels; i++) { + if (vm->def->seclabels[i]->type == VIR_DOMAIN_SECLABEL_DYNAMIC) + VIR_FREE(vm->def->seclabels[i]->label); + VIR_FREE(vm->def->seclabels[i]->imagelabel); + } + + virStringListFree(priv->qemuDevices); + priv->qemuDevices = NULL; + + qemuHostdevReAttachDomainDevices(driver, vm->def); + retry: if ((ret = qemuRemoveCgroup(vm)) < 0) { if (ret == -EBUSY && (retries++ < 5)) { -- 1.8.3.1

On Mon, May 08, 2017 at 03:03:30PM +0800, ZhiPeng Lu wrote:
In qemuProcessStop we explicitly remove the port from the openvswitch bridge after qemuProcessKill is called. But there is a certain interval of time between deleting tap device and removing it from bridge. The problem occurs when two vms start and shutdown with the same name's network interface attached to the same openvswitch bridge. When one vm with the nic named "vnet0" stopping, it deleted tap device without timely removing the port from bridge. At this time, another vm created the tap device named "vnet0" and added port to the same bridge. Then, the first vm removed the port from the same bridge. Finally, the tap device of the second vm did not attached to the bridge. We need to delete the bridge port before deleting the tap device instead of after. So what's needed is to move the loop in qemuProcessStop that cleans up network interfaces so that it happens before qemuProcessKill is called.
This fix won't work correctly either. You cannot assume that libvirt has control over when the QEMU process exits. It may exit itself *before* libvirt runs any of its cleanup code. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

77yeVGhpcyBmaXggd29uJ3Qgd29yayBjb3JyZWN0bHkgZWl0aGVyLiBZb3UgY2Fubm90IGFzc3Vt ZSB0aGF0IGxpYnZpcnQgaGFz77yeY29udHJvbCBvdmVyIHdoZW4gdGhlIFFFTVUgcHJvY2VzcyBl eGl0cy4gSXQgbWF5IGV4aXQgaXRzZWxmICpiZWZvcmUq77yebGlidmlydCBydW5zIGFueSBvZiBp dHMgY2xlYW51cCBjb2RlLg0KDQpJIGRvbid0IHRoaW5rIHRoZXJlJ3MgYSBwcm9ibGVtLiAgQWx0 aG91Z2ggIGxpYnZpcnQgZG9lcyBub3QgcnVucyBjbGVhbnVwIGNvZGUgLmJ1dCB0YXAgZGV2aWNl cyBkb24ndCBleGlzdCB3aGVuIHdoZW4gdGhlIFFFTVUgcHJvY2VzcyBleGl0cy4NCg0KDQpsaWJ2 aXJ0IGNhbiBjcmVhdGUgIHRhcCBkZXZpY2UgYW5kIGFkZCBwb3J0IHRvIHRoZSBicmlkZ2UgYWdh aW4gYnkgY2FsbGluZyB2aXJOZXREZXZPcGVudnN3aXRjaEFkZFBvcnQgLg0KDQogaSBjYW4gIG9u bHkgZGVsZXRlIHRoZSBwb3J0IGZyb20gb3BlbnZzd2l0Y2ggYnJpZGdlICBhbmQgY2xlYW51cCAg b3RoZXIgbmV0d29yayBpbnRlcmZhY2VzIGFmdGVyIHRoZSBRRU1VIHByb2Nlc3MgZXhpdHMuDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCuS4uuS6huiuqeaCqOeahFZQbGF06Jma5ouf5YyW5pWF 6Zqc5b6X5Yiw6auY5pWI55qE5aSE55CG77yM6K+35LiK5oql5pWF6Zqc5YiwOiAkVlBsYXTmioDm nK/mlK/mjIHjgIINCg0KDQroiqblv5fmnIsgbHV6aGlwZW5nDQoNCg0KDQoNCg0KDQpJVOW8gOWP keW3peeoi+W4iCBJVCBEZXZlbG9wbWVudApFbmdpbmVlcg0K5pON5L2c57O757uf5Lqn5ZOB6YOo L+S4reW/g+eglOeptumZoi/ns7vnu5/kuqflk4EgT1MgUHJvZHVjdCBEZXB0Li9DZW50cmFsIFLv vIZEIEluc3RpdHV0ZS9TeXN0ZW0gUHJvZHVjdA0KDQoNCg0KDQoNCg0KDQoNCg0K5rex5Zyz5biC 5Y2X5bGx5Yy656eR5oqA5Y2X6LevNTXlj7fkuK3lhbTpgJrorq/noJTlj5HlpKfmpbwzM+alvCAN CjMzL0YsIFImRCBCdWlsZGluZywgWlRFCkNvcnBvcmF0aW9uIEhpLXRlY2ggUm9hZCBTb3V0aCwg DQpIaS10ZWNoCkluZHVzdHJpYWwgUGFyayBOYW5zaGFuIERpc3RyaWN0LCBTaGVuemhlbiwgUC5S LkNoaW5hLCA1MTgwNTcgDQpUOiArODYgNzU1IHh4eHh4eHh4IEY6Kzg2IDc1NSB4eHh4eHh4eCAN Ck06ICs4NiB4eHh4eHh4eHh4eCANCkU6IGx1LnpoaXBlbmdAenRlLmNvbS5jbiANCnd3dy56dGUu Y29tLmNuDQoNCg0KDQoNCg0KDQrljp/lp4vpgq7ku7YNCg0KDQoNCuWPkeS7tuS6uu+8miDvvJxi ZXJyYW5nZUByZWRoYXQuY29t77yeDQrmlLbku7bkurrvvJroiqblv5fmnIsxMDEwODI3Mg0K5oqE 6YCB5Lq677yaIO+8nGxpYnZpci1saXN0QHJlZGhhdC5jb23vvJ4g77ycbGFpbmVAbGFpbmUub3Jn 77yeDQrml6Ug5pyfIO+8mjIwMTflubQwNeaciDA45pelIDE2OjM5DQrkuLsg6aKYIO+8mlJlOiBb bGlidmlydF0gW1BBVENIIHYyXSBxZW11OiBjbGVhbiB1cCBuZXR3b3JrIGludGVyZmFjZXMgYmVm b3JlcWVtdVByb2Nlc3NLaWxsIGlzIGNhbGxlZCBpbiBxZW11UHJvY2Vzc1N0b3ANCg0KDQoNCg0K DQpPbiBNb24sIE1heSAwOCwgMjAxNyBhdCAwMzowMzozMFBNICswODAwLCBaaGlQZW5nIEx1IHdy b3RlOg0K77yeIEluIHFlbXVQcm9jZXNzU3RvcCB3ZSBleHBsaWNpdGx5IHJlbW92ZSB0aGUgcG9y dCBmcm9tIHRoZSBvcGVudnN3aXRjaCBicmlkZ2UgYWZ0ZXINCu+8niBxZW11UHJvY2Vzc0tpbGwg aXMgY2FsbGVkLiBCdXQgdGhlcmUgaXMgYSBjZXJ0YWluIGludGVydmFsIG9mIHRpbWUgYmV0d2Vl bg0K77yeIGRlbGV0aW5nIHRhcCBkZXZpY2UgYW5kIHJlbW92aW5nIGl0IGZyb20gYnJpZGdlLiBU aGUgcHJvYmxlbSBvY2N1cnMgd2hlbiB0d28gdm1zDQrvvJ4gc3RhcnQgYW5kIHNodXRkb3duIHdp dGggdGhlIHNhbWUgbmFtZSdzIG5ldHdvcmsgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHRoZSBzYW1l DQrvvJ4gb3BlbnZzd2l0Y2ggYnJpZGdlLiBXaGVuIG9uZSB2bSB3aXRoIHRoZSBuaWMgbmFtZWQg InZuZXQwIiBzdG9wcGluZywgaXQgZGVsZXRlZA0K77yeIHRhcCBkZXZpY2Ugd2l0aG91dCB0aW1l bHkgcmVtb3ZpbmcgdGhlIHBvcnQgZnJvbSBicmlkZ2UuDQrvvJ4gQXQgdGhpcyB0aW1lLCBhbm90 aGVyIHZtIGNyZWF0ZWQgdGhlIHRhcCBkZXZpY2UgbmFtZWQgInZuZXQwIiBhbmQgYWRkZWQgcG9y dCB0byB0aGUNCu+8niBzYW1lIGJyaWRnZS4gVGhlbiwgdGhlIGZpcnN0IHZtIHJlbW92ZWQgdGhl IHBvcnQgZnJvbSB0aGUgc2FtZSBicmlkZ2UuDQrvvJ4gRmluYWxseSwgdGhlIHRhcCBkZXZpY2Ug b2YgdGhlIHNlY29uZCB2bSBkaWQgbm90IGF0dGFjaGVkIHRvIHRoZSBicmlkZ2UuDQrvvJ4gV2Ug bmVlZCB0byBkZWxldGUgdGhlIGJyaWRnZSBwb3J0IGJlZm9yZSBkZWxldGluZyB0aGUgdGFwIGRl dmljZSBpbnN0ZWFkIG9mIGFmdGVyLg0K77yeIFNvIHdoYXQncyBuZWVkZWQgaXMgdG8gbW92ZSB0 aGUgbG9vcCBpbiBxZW11UHJvY2Vzc1N0b3AgdGhhdCBjbGVhbnMgdXANCu+8niBuZXR3b3JrIGlu dGVyZmFjZXMgc28gdGhhdCBpdCBoYXBwZW5zIGJlZm9yZSBxZW11UHJvY2Vzc0tpbGwgaXMgY2Fs bGVkLg0KDQpUaGlzIGZpeCB3b24ndCB3b3JrIGNvcnJlY3RseSBlaXRoZXIuIFlvdSBjYW5ub3Qg YXNzdW1lIHRoYXQgbGlidmlydCBoYXMNCmNvbnRyb2wgb3ZlciB3aGVuIHRoZSBRRU1VIHByb2Nl c3MgZXhpdHMuIEl0IG1heSBleGl0IGl0c2VsZiAqYmVmb3JlKg0KbGlidmlydCBydW5zIGFueSBv ZiBpdHMgY2xlYW51cCBjb2RlLg0KDQoNClJlZ2FyZHMsDQpEYW5pZWwNCi0tIA0KfDogaHR0cHM6 Ly9iZXJyYW5nZS5jb20gICAgICAtby0gICAgaHR0cHM6Ly93d3cuZmxpY2tyLmNvbS9waG90b3Mv ZGJlcnJhbmdlIDp8DQp8OiBodHRwczovL2xpYnZpcnQub3JnICAgICAgICAgLW8tICAgICAgICAg ICAgaHR0cHM6Ly9mc3RvcDEzOC5iZXJyYW5nZS5jb20gOnwNCnw6IGh0dHBzOi8vZW50YW5nbGUt cGhvdG8ub3JnICAgIC1vLSAgICBodHRwczovL3d3dy5pbnN0YWdyYW0uY29tL2RiZXJyYW5nZSA6 fA0KDQotLQ0KbGlidmlyLWxpc3QgbWFpbGluZyBsaXN0DQpsaWJ2aXItbGlzdEByZWRoYXQuY29t DQpodHRwczovL3d3dy5yZWRoYXQuY29tL21haWxtYW4vbGlzdGluZm8vbGlidmlyLWxpc3Q=

On Mon, May 08, 2017 at 05:18:17PM +0800, lu.zhipeng@zte.com.cn wrote:
>This fix won't work correctly either. You cannot assume that libvirt has >control over when the QEMU process exits. It may exit itself *before* >libvirt runs any of its cleanup code.
I don't think there's a problem. Although libvirt does not runs cleanup code .but tap devices don't exist when when the QEMU process exits.
That still does not make sense. There is no difference in the way tap devices are cleaned up whether QEMU exits "normally" on its own, or when libvirt kills QEMU explicitly Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

SSBtYXkgbm90IGhhdmUgZGVzY3JpYmVkIGl0IGNsZWFybHkuICANCg0KaSBuZWVkIHRvIGVuc3Vy ZSAgdGhlIG9yZGVyIG9mICBhZGRpbmcgcG9ydCB0byBicmlkZ2UgYW5kIGRlbGV0aW5nIGZyb20g YnJpZGdlLg0KDQppICByZW5hbWUgdGFwIGRldmljZSB0byBhdm9pZCB0aGUgcHJvYmxlbSAgaW4g bXkgZmlyc3QgcGF0Y2guaSB0aGluayBpdCBjYW4gc29sdmUgdGhlIHByb2JsZW0uDQoNCm15IHNl Y29uZCBwYXRjaCBtYXkgY2FuJ3QgcmVzb2x2ZSB0aGUgcHJvYmxlbSAuDQoNCkRvIHlvdSAgaGF2 ZSBhbnkgYmV0dGVyIGlkZWFzPw0KDQp0aGFua3MNCg0KDQoNCuS4uuS6huiuqeaCqOeahFZQbGF0 6Jma5ouf5YyW5pWF6Zqc5b6X5Yiw6auY5pWI55qE5aSE55CG77yM6K+35LiK5oql5pWF6Zqc5Yiw OiAkVlBsYXTmioDmnK/mlK/mjIHjgIINCg0KDQroiqblv5fmnIsgbHV6aGlwZW5nDQoNCg0KDQoN Cg0KDQpJVOW8gOWPkeW3peeoi+W4iCBJVCBEZXZlbG9wbWVudApFbmdpbmVlcg0K5pON5L2c57O7 57uf5Lqn5ZOB6YOoL+S4reW/g+eglOeptumZoi/ns7vnu5/kuqflk4EgT1MgUHJvZHVjdCBEZXB0 Li9DZW50cmFsIFLvvIZEIEluc3RpdHV0ZS9TeXN0ZW0gUHJvZHVjdA0KDQoNCg0KDQoNCg0KDQoN Cg0K5rex5Zyz5biC5Y2X5bGx5Yy656eR5oqA5Y2X6LevNTXlj7fkuK3lhbTpgJrorq/noJTlj5Hl pKfmpbwzM+alvCANCjMzL0YsIFImRCBCdWlsZGluZywgWlRFCkNvcnBvcmF0aW9uIEhpLXRlY2gg Um9hZCBTb3V0aCwgDQpIaS10ZWNoCkluZHVzdHJpYWwgUGFyayBOYW5zaGFuIERpc3RyaWN0LCBT aGVuemhlbiwgUC5SLkNoaW5hLCA1MTgwNTcgDQpUOiArODYgNzU1IHh4eHh4eHh4IEY6Kzg2IDc1 NSB4eHh4eHh4eCANCk06ICs4NiB4eHh4eHh4eHh4eCANCkU6IGx1LnpoaXBlbmdAenRlLmNvbS5j biANCnd3dy56dGUuY29tLmNuDQoNCg0KDQoNCg0KDQrljp/lp4vpgq7ku7YNCg0KDQoNCuWPkeS7 tuS6uu+8miDvvJxiZXJyYW5nZUByZWRoYXQuY29t77yeDQrmlLbku7bkurrvvJroiqblv5fmnIsx MDEwODI3Mg0K5oqE6YCB5Lq677yaIO+8nGxpYnZpci1saXN0QHJlZGhhdC5jb23vvJ4g77ycbGFp bmVAbGFpbmUub3Jn77yeDQrml6Ug5pyfIO+8mjIwMTflubQwNeaciDA45pelIDE3OjQyDQrkuLsg 6aKYIO+8mlJlOiBbbGlidmlydF3nrZTlpI06IFJlOiAgW1BBVENIIHYyXSBxZW11OiBjbGVhbiB1 cCBuZXR3b3JrIGludGVyZmFjZXMgYmVmb3JlcWVtdVByb2Nlc3NLaWxsIGlzIGNhbGxlZCBpbiBx ZW11UHJvY2Vzc1N0b3ANCg0KDQoNCg0KDQpPbiBNb24sIE1heSAwOCwgMjAxNyBhdCAwNToxODox N1BNICswODAwLCBsdS56aGlwZW5nQHp0ZS5jb20uY24gd3JvdGU6DQrvvJ4g77yeVGhpcyBmaXgg d29uJ3Qgd29yayBjb3JyZWN0bHkgZWl0aGVyLiBZb3UgY2Fubm90IGFzc3VtZSB0aGF0IGxpYnZp cnQgaGFzDQrvvJ4g77yeY29udHJvbCBvdmVyIHdoZW4gdGhlIFFFTVUgcHJvY2VzcyBleGl0cy4g SXQgbWF5IGV4aXQgaXRzZWxmICpiZWZvcmUqDQrvvJ4g77yebGlidmlydCBydW5zIGFueSBvZiBp dHMgY2xlYW51cCBjb2RlLg0K77yeIA0K77yeIEkgZG9uJ3QgdGhpbmsgdGhlcmUncyBhIHByb2Js ZW0uICBBbHRob3VnaCAgbGlidmlydCBkb2VzIG5vdCBydW5zIGNsZWFudXANCu+8niBjb2RlIC5i dXQgdGFwIGRldmljZXMgZG9uJ3QgZXhpc3Qgd2hlbiB3aGVuIHRoZSBRRU1VIHByb2Nlc3MgZXhp dHMuDQoNClRoYXQgc3RpbGwgZG9lcyBub3QgbWFrZSBzZW5zZS4gVGhlcmUgaXMgbm8gZGlmZmVy ZW5jZSBpbiB0aGUgd2F5IHRhcCBkZXZpY2VzDQphcmUgY2xlYW5lZCB1cCB3aGV0aGVyIFFFTVUg ZXhpdHMgIm5vcm1hbGx5IiBvbiBpdHMgb3duLCBvciB3aGVuIGxpYnZpcnQga2lsbHMNClFFTVUg ZXhwbGljaXRseQ0KDQoNClJlZ2FyZHMsDQpEYW5pZWwNCi0tIA0KfDogaHR0cHM6Ly9iZXJyYW5n ZS5jb20gICAgICAtby0gICAgaHR0cHM6Ly93d3cuZmxpY2tyLmNvbS9waG90b3MvZGJlcnJhbmdl IDp8DQp8OiBodHRwczovL2xpYnZpcnQub3JnICAgICAgICAgLW8tICAgICAgICAgICAgaHR0cHM6 Ly9mc3RvcDEzOC5iZXJyYW5nZS5jb20gOnwNCnw6IGh0dHBzOi8vZW50YW5nbGUtcGhvdG8ub3Jn ICAgIC1vLSAgICBodHRwczovL3d3dy5pbnN0YWdyYW0uY29tL2RiZXJyYW5nZSA6fA0KDQotLQ0K bGlidmlyLWxpc3QgbWFpbGluZyBsaXN0DQpsaWJ2aXItbGlzdEByZWRoYXQuY29tDQpodHRwczov L3d3dy5yZWRoYXQuY29tL21haWxtYW4vbGlzdGluZm8vbGlidmlyLWxpc3Q=

On Mon, May 08, 2017 at 06:18:25PM +0800, lu.zhipeng@zte.com.cn wrote:
I may not have described it clearly.
i need to ensure the order of adding port to bridge and deleting from bridge.
i rename tap device to avoid the problem in my first patch.i think it can solve the problem.
my second patch may can't resolve the problem .
Do you have any better ideas?
Remove the tap device fromthe bridge port and then delete the tap device, as suggested in replay to your first patch. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (3)
-
Daniel P. Berrange
-
lu.zhipeng@zte.com.cn
-
ZhiPeng Lu