Bug 1510336
Summary: | [RFE] - Automatically instruct MTU to the guest | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Yaniv Lavi <ylavi> |
Component: | vdsm | Assignee: | Dominik Holler <dholler> |
Status: | CLOSED ERRATA | QA Contact: | msheena |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.1.6 | CC: | aconole, ailan, atelang, chayang, danken, dholler, dyuan, egarver, emarcus, fbaudin, fleitner, jherrman, jsuchane, juzhang, ktraynor, laine, lhuang, lsurette, maxime.coquelin, mburman, mprivozn, mst, mtessun, ovasik, pezhang, rdlugyhe, rkhan, srevivo, virt-bugs, wtownsen, xuzhang, yalzhang, ycui |
Target Milestone: | ovirt-4.3.0 | Keywords: | FutureFeature |
Target Release: | --- | Flags: | mburman:
testing_plan_complete+
|
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | ovirt-engine-4.3.0-0.5.alpha1.el7 | Doc Type: | Enhancement |
Doc Text: |
This release adds the ability to manage the MTU of VM networks in a centralized way, enabling oVirt to manage MTU all the way from the host network to the guest in the VM. This feature allows for the consistent use of MTUs in logical networks with small MTU (e.g., tunneled networks) and large MTU (e.g., jumbo frames) in VMs, even without DHCP.
|
Story Points: | --- |
Clone Of: | 1408701 | Environment: | |
Last Closed: | 2019-05-08 12:35:59 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1408701, 1451342 | ||
Bug Blocks: |
Comment 9
Yaniv Kaul
2017-11-13 08:00:49 UTC
(In reply to Yaniv Kaul from comment #9) > This is what I'm seeing: > Host: .. > [ykaul@ykaul perfmon]$ ps -ef |grep qemu > qemu 8331 1 50 09:25 ? 00:02:03 /usr/bin/qemu-system-x86_64 ... > -netdev tap,fd=30,id=hostnet1,vhost=on,vhostfd=31 -device > virtio-net-pci,host_mtu=9000,netdev=hostnet1,id=net1,mac=54:52:c0:a8:c8:02, > bus=pci.0,addr=0x3 This device is properly configured here, sa the host_mtu parameter is set. > Guest: ... > [root@lago-basic-suite-master-host-0 virtio:virtio_net]# pwd > /sys/module/virtio_net/drivers/virtio:virtio_net > [root@lago-basic-suite-master-host-0 virtio:virtio_net]# cat > virtio*/features |sort |uniq > 1100010111111111111101010000110010000000000000000000000000000000 But the VIRTIO_NET_F_MTU feature hasn't been negotiated. What is the guest Kernel version? Regards, Maxime (In reply to Maxime Coquelin from comment #10) > (In reply to Yaniv Kaul from comment #9) > > This is what I'm seeing: > > Host: > .. > > [ykaul@ykaul perfmon]$ ps -ef |grep qemu > > qemu 8331 1 50 09:25 ? 00:02:03 /usr/bin/qemu-system-x86_64 > ... > > -netdev tap,fd=30,id=hostnet1,vhost=on,vhostfd=31 -device > > virtio-net-pci,host_mtu=9000,netdev=hostnet1,id=net1,mac=54:52:c0:a8:c8:02, > > bus=pci.0,addr=0x3 > This device is properly configured here, sa the host_mtu parameter is set. > > > Guest: > ... > > [root@lago-basic-suite-master-host-0 virtio:virtio_net]# pwd > > /sys/module/virtio_net/drivers/virtio:virtio_net > > [root@lago-basic-suite-master-host-0 virtio:virtio_net]# cat > > virtio*/features |sort |uniq > > 1100010111111111111101010000110010000000000000000000000000000000 > > But the VIRTIO_NET_F_MTU feature hasn't been negotiated. > What is the guest Kernel version? 3.10.0-327.10.1.el7.x86_64 > > Regards, > Maxime (In reply to Yaniv Kaul from comment #11) > (In reply to Maxime Coquelin from comment #10) > > (In reply to Yaniv Kaul from comment #9) > > > This is what I'm seeing: > > > Host: > > .. > > > [ykaul@ykaul perfmon]$ ps -ef |grep qemu > > > qemu 8331 1 50 09:25 ? 00:02:03 /usr/bin/qemu-system-x86_64 > > ... > > > -netdev tap,fd=30,id=hostnet1,vhost=on,vhostfd=31 -device > > > virtio-net-pci,host_mtu=9000,netdev=hostnet1,id=net1,mac=54:52:c0:a8:c8:02, > > > bus=pci.0,addr=0x3 > > This device is properly configured here, sa the host_mtu parameter is set. > > > > > Guest: > > ... > > > [root@lago-basic-suite-master-host-0 virtio:virtio_net]# pwd > > > /sys/module/virtio_net/drivers/virtio:virtio_net > > > [root@lago-basic-suite-master-host-0 virtio:virtio_net]# cat > > > virtio*/features |sort |uniq > > > 1100010111111111111101010000110010000000000000000000000000000000 > > > > But the VIRTIO_NET_F_MTU feature hasn't been negotiated. > > What is the guest Kernel version? > > 3.10.0-327.10.1.el7.x86_64 Also with 3.10.0-693.5.2.el7.x86_64: [root@lago-basic-suite-master-host-0 virtio:virtio_net]# cat virtio*/features |sort |uniq 1100010111111111111101010000110010000000000000000000000000000000 > > > > > > Regards, > > Maxime (In reply to Yaniv Kaul from comment #12) > (In reply to Yaniv Kaul from comment #11) > > (In reply to Maxime Coquelin from comment #10) > > > (In reply to Yaniv Kaul from comment #9) > > > > This is what I'm seeing: > > > > Host: > > > .. > > > > [ykaul@ykaul perfmon]$ ps -ef |grep qemu > > > > qemu 8331 1 50 09:25 ? 00:02:03 /usr/bin/qemu-system-x86_64 > > > ... > > > > -netdev tap,fd=30,id=hostnet1,vhost=on,vhostfd=31 -device > > > > virtio-net-pci,host_mtu=9000,netdev=hostnet1,id=net1,mac=54:52:c0:a8:c8:02, > > > > bus=pci.0,addr=0x3 > > > This device is properly configured here, sa the host_mtu parameter is set. > > > > > > > Guest: > > > ... > > > > [root@lago-basic-suite-master-host-0 virtio:virtio_net]# pwd > > > > /sys/module/virtio_net/drivers/virtio:virtio_net > > > > [root@lago-basic-suite-master-host-0 virtio:virtio_net]# cat > > > > virtio*/features |sort |uniq > > > > 1100010111111111111101010000110010000000000000000000000000000000 > > > > > > But the VIRTIO_NET_F_MTU feature hasn't been negotiated. > > > What is the guest Kernel version? > > > > 3.10.0-327.10.1.el7.x86_64 This kernel version does not support the MTU feature, so this is expected. > Also with 3.10.0-693.5.2.el7.x86_64: > [root@lago-basic-suite-master-host-0 virtio:virtio_net]# cat > virtio*/features |sort |uniq > 1100010111111111111101010000110010000000000000000000000000000000 But here, this kernel support this feature, so it should have been negociated for the single device passing host_mtu parameter. Let me check what could cause the negotiation to fail. Thanks, Maxime > > > > > > > > > > Regards, > > > Maxime This has been included in RHV-4.2.5 by means of bug 1451342 Verified on: (Engine): 4.3.0-0.6.master.20190109150110.gitafe5251.el7 vdsm-4.30.4-92.git2282ef2.el7.x86_64 libvirt-4.5.0-10.el7_6.3.x86_64 qemu-kvm-ev-2.12.0-18.el7_6.1.1.x86_64 Adding versions that were used for verification: RHV - 4.3.0-0.8.rc2.el7 libvirt-4.5.0-10.el7_6.3.x86_64 qemu-kvm-rhev-2.12.0-18.el7_6.1.x86_64 qemu-img-rhev-2.12.0-18.el7_6.1.x86_64 libvirt-daemon-driver-qemu-4.5.0-10.el7_6.3.x86_64 qemu-kvm-common-rhev-2.12.0-18.el7_6.1.x86_64 Red Hat Enterprise Linux Server release 7.6 (Maipo) (host and guest) I find the original doc text of https://bugzilla.redhat.com/show_bug.cgi?id=1451342 more complete and more precise. I'd rather we just copy it. (In reply to Dan Kenigsberg from comment #24) > I find the original doc text of > https://bugzilla.redhat.com/show_bug.cgi?id=1451342 more complete and more > precise. I'd rather we just copy it. Ack. 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, 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/RHBA-2019:1077 |