> The hash iterator visits in an unpredictable order. It
shouldn't matter
> because for this usage, all that is important is that 'nextslot' eventually
> ends up with the largest slot ID + 1.
We don't want the first unused slot, rather the last slot reservation
that was in place before the reconnect (often the first unused slot if
you haven't done a lot of hot-unplugging, but not necessarily the case).
The only way I can see to get at this is to revisit the reservations in
the same order as they were reserved, rather than in the random order
Actually, thinking about it you are right that setting nextslot to the largest
slot used + 1 is not always correct. Even when no PCI devices are
added/removed after a guest is started, nextslot doesn't have to look like
that. E.g., if there is a device with explicit PCI address 0:0:31 in the XML.
Although in normal configurations it would work.
However, if we start thinking about hot(un)plugging PCI devices, even your
suggestion of revisiting reservations in the original order wouldn't help much
since the last device which influenced nextslot value might have been already
unplugged from the guest. The only solution which really updates nextslot to
exactly the same value it had before restarting libvirt is storing it in the
runtime XML inside <domstatus>, from where it can be just read when the domain
is being reconnected.
Jirka