On Fri, May 11, 2018 at 1:42 AM, Daniel P. Berrangé <berrange@redhat.com> 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