GitHub user dstoy53 added a comment to the discussion: disabling security groups cleanly
Both are true, the zone has security groups enabled, and a given in-use network uses an offering with security groups. If the zone has SG enabled and I eliminate all SG networks, then the system VMs fail to deploy with the error I found in the logs. I considered doing the swap you've described, but doing it in-place (same VLAN/VNI, my switch config won't change) has me concerned about the VR/DHCP behavior. I also haven't tested if the bypass checkbox for overlapping vlans/vnis would cause the network implementation to fail in a strange way. Maybe an option could be to power off the VR in the old network, create the new network with an overlapping vlan and address space (unless this fails), and swap the NIC (enough times to land on the original MAC+IP+virtual PCI slot in the guest), then tear down the old network. I can test this out in my lab. I'm over-complicating this shuffle to avoid changing netplan config in the guest, since a new NIC would have a new (different) MAC, and I also can't delete all NICs from a VM to avoid a conflict. I tend to find myself in strange in-place migration scenarios where I also want VMs to remain live. I feel like the most comprehensive solution would be to allow more changes to an implemented network, even if it initially requires a hit on re-applying the network. For example the VLAN ID can't be changed today, but maybe someone has a totally reasonable reason to re-assign the vlan for a live network. Today that would be a shuffle for the VM NICs, not an in-place change for the network (to which the VM would be oblivious). The NIC shuffle also feels like it could be improved by the ability to change the network assignment directly on a NIC, without doing a shuffle. From what I've read the updateDeviceFlags method in libvirt would be the live way to attach to a different bridge. This would be like esxi's ability to set a VM NIC's port group via drop down (along with the necessary API implementation). I'm still learning about some of these behaviors both in KVM and in cloudstack, so it's hard to tell when I'm hitting a skill issue vs normal behavior. It seems to me that enabling security groups is a one way door. GitHub link: https://github.com/apache/cloudstack/discussions/11864#discussioncomment-14727187 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
