Wei, Issue 7457 is very imilar to what I am experiencing. My test servers have been Windows 2022 with the latest 1.240 build of the virtio drivers, and Windows 2019 with an older build of the drivers installed. In my case, I am seeing the slot ID / rediscovery occur when the added interface is associated with either a L2 or an isolated network. My testing to this point has only had the slot ID change on the first reboot. The NICs and their configurations appear to be stable afterwards.
On Wed, Jan 24, 2024 at 3:30 AM Wei ZHOU <[email protected]> wrote: > Hi, > > Are the issues similar as > https://github.com/apache/cloudstack/issues/7457 > https://github.com/apache/cloudstack/issues/7490 > ? > > > -Wei > > On Wed, 24 Jan 2024 at 04:06, S.Fuller <[email protected]> wrote: > > > I am running Cloudstack 4.11 and have encountered an issue with hot added > > NICs on Windows guests. I add the NIC to a running guest, configure it, > and > > it works as expected. After the guest reboots, the NIC is assigned to a > > different PCI slot, and then needs to be reconfigured. This has caused > > issues when those hot-added network interfaces are used for ISCSI > traffic. > > > > I can see the slot reassignment in both Windows and in the XML when I do > a > > virsh dumpxml on the guest. I've also seen this behavior when hot adding > > volumes. That sometimes results in the volumes being in an offline state > > when the guest restarts. We can bring them online manually, and all of > the > > data is there. > > > > I assume someone else has encountered this. If so, have you worked around > > it somehow? For now, we're going to add interfaces and volumes only when > > the guest is powered off, but that does make things a bit more work. > > > > Thanks. > > > > -- > > Steve Fuller > > [email protected] > > > -- Steve Fuller [email protected]
