> > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list