On Fri, May 11, 2018 at 1:42 AM, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > On Thu, May 10, 2018 at 11:53:23AM -0700, Ihar Hrachyshka wrote: >> Hi, >> >> In kubevirt, we discovered [1] that whenever e1000 is used for vNIC, >> link on the interface becomes ready several seconds after 'ifup' is >> executed, which for some buggy images like cirros may slow down boot >> process for up to 1 minute [2]. If we switch from e1000 to virtio, the >> link is brought up and ready almost immediately. >> >> For the record, I am using the following versions: >> - L0 kernel: 4.16.5-200.fc27.x86_64 #1 SMP >> - libvirt: 3.7.0-4.fc27 >> - guest kernel: 4.4.0-28-generic #47-Ubuntu >> >> Is there something specific about e1000 that makes it initialize the >> link too slowly on libvirt or guest side? > > Try the e1000e device instead perhaps. Thanks a lot for the suggestion, it works indeed. My understanding is that it's the default NIC for q35 machines starting 2.12, so indeed that's a great choice. > > If all other NIC models work, then this is likely to be a QEMU problem > and should be reported as a bug to them. I notice you're running Fedora 27 > though, so before reporting bugs please try with latest upstream QEMU > releases (2.12) to see if that's better Thanks for the suggestion. I reported a bug here: https://bugs.launchpad.net/qemu/+bug/1770724 I tried to reproduce it with 2.12 (built kubevirt stack with Fedora 29 packages) but I get some fundamental issues in the guest that block me from reproducing the slow link ready bug (with the new qemu / libvirt stack, I get kernel traces and irq interrupt error and no network link at all in the guest). I hope my report against 2.10 would still fit their bug report requirements. Thanks again, Ihar _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
