Bug 827544

According to the trace, the netdev_del/netdev_add pair works just fine; indeed do_netdev_del() in the qemu source removes the id:

  int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
  {
      const char *id = qdict_get_str(qdict, "id");
      VLANClientState *vc;

      vc = qemu_find_netdev(id);
      if (!vc) {
          qerror_report(QERR_DEVICE_NOT_FOUND, id);
          return -1;
      }
      qemu_del_vlan_client(vc);
      qemu_opts_del(qemu_opts_find(&qemu_netdev_opts, id)); /* HERE */
      return 0;
  }

do_device_add/do_device_del seem to work differently (device_add is the one failing in the trace).

do_device_del()
  qdev_unplug()
    dev->info->unplug(dev)

I didn't try to track the funcptr, but I guess it doesn't clean up the qemu options. However do_device_add() checks for unicity:

do_device_add()
  qemu_opts_from_qdict()
    qemu_opts_create()
      qemu_opts_find()
      qerror_report(QERR_DUPLICATE_ID, ...) -- reports the cited error

Upstream qemu lacks do_device_del() completely, only an unused prototype exists in hw/qdev.h. Instead it has qmp_device_del() (and hmp_device_del(), calling it), but the underlying qdev_unplug() doesn't seem to be very different. This could be a problem in upstream qemu as well (ie. device_del not pruning the qemu_find_opts("device") QemuOptsList, that is, "qemu_device_opts").

The problem is narrower than I initially thought. The guest where I saw the problem was RHEL5. I tried the same operation on RHEL6 and WinXP guests and they had no problem re-using the id of a previously detached device.

I also noticed that this guest doesn't show any signs that the device has been added even the first time - nothing in dmesg, no new device showing up in ifconfig -a.

I had thought that adding and removing devices was happening at a low enough level that it didn't matter what OS was running on the guest, or whether or not the guest acknowledged it. Is this not the case? Beyond that, is there some known issue with RHEL5 and hotplugging of network devices, or is my guest somehow broken?

From discussion with qemu people, I've learned that that qemu *does* recycle the device alias names, but not until it receives confirmation from the guest that it really has released the hardware and that pci hotplug support is more or less non-existent in RHEL5. So my choice of test OS was unfortunate, since qemu is waiting for the guest to release the hardware, but the guest doesn't even know that it had it to begin with (and wouldn't know how to release it if it did).

On the other hand, when I used a RHEL6 guest, the device alias *is* properly recycled and can be re-used.

Since the problem is only manifests itself as an inability to hotplug any more devices, and it's only a problem when using a guest that doesn't support hotplug anyway, this is (mostly) a non-issue. 

The one issue is that there appears to be a race, since libvirt makes the alias available for re-use immediately, while qemu won't recycle it until the guest has notified qemu that it's completely finished, and apparently that happens asynchronous to the detach command, and there is no way for libvirt to be notified of that event. Until that theoretical race is actually witnessed on a guest that properly supports hotplug, I think we can close this as NOTABUG.

(In reply to comment #3)
> The one issue is that there appears to be a race, since libvirt makes the
> alias available for re-use immediately, while qemu won't recycle it until
> the guest has notified qemu that it's completely finished, and apparently
> that happens asynchronous to the detach command, and there is no way for
> libvirt to be notified of that event. Until that theoretical race is
> actually witnessed on a guest that properly supports hotplug, I think we can
> close this as NOTABUG.

Can you open a BZ against qemu for an event in this case?  There are other hotplug cases which behave similarly, and qemu will be providing an event so that libvirt can tell when the operation's complete.

*** Bug 844622 has been marked as a duplicate of this bug. ***