Created attachment 1713427 [details] yaml_sriov Description of problem: create a VMI with SR-IOV only and without any explicitly assigned MAC. The guest agent then exposes the IP in the status but then removes it again VMI Guest Agent expose link-local ipv6 address for sometime and then remove it. It is not fixed and without doing any changes to mac/ip of vm it keeps on changing. Attaching the report taken at the time of vm creation and few minutes later after vm creation. Version-Release number of selected component (if applicable): 2.4.1 How reproducible: always Steps to Reproduce: 1.Create standalone SR-IOV network without explicitly specifying ipv6. 2. 3. Actual results: ipaddress field generated by guest agent is unstable for ipv6 link-local Expected results: IPv6 local IP is generated and assigned by the guest so VMI should report it same everytime and should not go on/off. Additional info:
In the attached yaml there is only one interface under spec.domain.interfaces. Since its name will be ethN as we see in the status, the cloud-init there doesn't affect it, because it's hard coded to eth2. We should configure the secondary interfaces ourselves, and not depend on the default Network manager config of them. I managed to simulate it locally, by just not updating the secondary interfaces and I saw that the ipv6 link local in the VM itself comes and goes, hence the VM scheme is flaky as well. If you run "systemctl status NetworkManager-wait-online.service" in the VM, you might see this service has an error. Please add a fixed mac to spec.domain.interfaces secondary interface, for example "macAddress: aa:18:ab:e2:c8:cb". And then add the following cloud-init, or alternatives of it as you wish. bootcmd: - if [ ! -f /var/boot_happened ]; then - MAC=aa:18:ab:e2:c8:cb - IFACE=$(ip --brief l | grep $MAC | cut -f1 -d' ') - nmcli con add type ethernet con-name $IFACE ifname $IFACE - nmcli con mod $IFACE ipv4.addresses 10.200.3.1/24 ipv4.method manual connection.autoconnect-priority 1 ipv6.method ignore - nmcli con up $IFACE - touch /var/boot_happened - fi The important things here are: 1. It doesn't use a hard-coded interface name, as Edy researched on https://bugzilla.redhat.com/show_bug.cgi?id=1874096 we can't depend on the order. 2. It fits both configurations of "net.ifnames" in the kernel line which determine if ethN naming is used or not. 3. It doesn't recreate nmcli connections upon boot if it already exists, so if you run nmcli con after several boots, you will not see several zombie entries. With this config, the NetworkManager-wait-online.service should be gone (at least when i tried it), and no more flakiness of ips occurs. If you don't need ipv6, or you can use manual mode for it, it's best to have an expected and controlled configuration, in this case update the ipv6.method and give an address if you set it to manual, or just set it to disabled. Notes: 1. Please give at least 2 minutes after the VM finishes boot to let the interface stabilize. It's known it takes 2 minutes, especially after the first boot, we will fix it, but it's not related to this bugzilla. 2. There was a bug that after several reboots, the guest agent won't update about changes / current state anymore, a PR was merged to kubevirt to address it. https://github.com/kubevirt/kubevirt/pull/4253 Thanks
Verified the fix.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Virtualization 2.6.0 security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:0799