Bug 1510336 - [RFE] - Automatically instruct MTU to the guest
Summary: [RFE] - Automatically instruct MTU to the guest
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 4.1.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-4.3.0
: ---
Assignee: Dominik Holler
QA Contact: msheena
URL:
Whiteboard:
Depends On: 1408701 1451342
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-07 09:14 UTC by Yaniv Lavi
Modified: 2019-05-08 12:36 UTC (History)
33 users (show)

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.
Clone Of: 1408701
Environment:
Last Closed: 2019-05-08 12:35:59 UTC
oVirt Team: Network
Target Upstream Version:
mburman: testing_plan_complete+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:1077 0 None None None 2019-05-08 12:36:29 UTC

Comment 9 Yaniv Kaul 2017-11-13 08:00:49 UTC
This is what I'm seeing:
Host:

[ykaul@ykaul perfmon]$ brctl show
bridge name	bridge id		STP enabled	interfaces
9a51-07e0587		8000.52540043b356	yes		9a51-07e587-nic
							vnet1
							vnet5
							vnet9
9a51-7428207		8000.52540032b4bc	yes		9a51-742207-nic
							vnet0
							vnet4
							vnet8
9a51-9465d1e		8000.52540016aacb	yes		9a51-946d1e-nic
							vnet2
							vnet3
							vnet6
							vnet7
virbr0		8000.5254006a9c08	yes		virbr0-nic
virbr1		8000.52540010c667	yes		virbr1-nic
[ykaul@ykaul perfmon]$ ip -o -4 link |grep 9000
212: 9a51-07e0587: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000\    link/ether 52:54:00:43:b3:56 brd ff:ff:ff:ff:ff:ff
213: 9a51-07e587-nic: <BROADCAST,MULTICAST> mtu 9000 qdisc fq_codel master 9a51-07e0587 state DOWN mode DEFAULT group default qlen 1000\    link/ether 52:54:00:43:b3:56 brd ff:ff:ff:ff:ff:ff
219: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel master 9a51-07e0587 state UNKNOWN mode DEFAULT group default qlen 1000\    link/ether fe:52:c0:a8:c8:02 brd ff:ff:ff:ff:ff:ff
223: vnet5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel master 9a51-07e0587 state UNKNOWN mode DEFAULT group default qlen 1000\    link/ether fe:52:c0:a8:c8:03 brd ff:ff:ff:ff:ff:ff
227: vnet9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel master 9a51-07e0587 state UNKNOWN mode DEFAULT group default qlen 1000\    link/ether fe:52:c0:a8:c8:04 brd ff:ff:ff:ff:ff:ff
[ykaul@ykaul perfmon]$ ps -ef |grep qemu
qemu      8331     1 50 09:25 ?        00:02:03 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=9a511e10-lago-basic-suite-master-host-0,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-58-9a511e10-lago-basic-/master-key.aes -machine pc-i440fx-2.9,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,+kvm_pv_eoi -m 2047 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 -uuid 4b4df209-b2db-4fd9-ad54-e1bcf5a6384a -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-58-9a511e10-lago-basic-/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/ykaul/ovirt-system-tests/deployment-basic-suite-master/default/images/lago-basic-suite-master-host-0_root.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,serial=1,cache=writeback,discard=unmap -device virtio-blk-pci,iothread=iothread1,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:c0:a8:c9:02,bus=pci.0,addr=0x2 -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 -netdev tap,fd=32,id=hostnet2,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet2,id=net2,mac=54:52:c0:a8:ca:02,bus=pci.0,addr=0x4 -netdev tap,fd=34,id=hostnet3,vhost=on,vhostfd=35 -device virtio-net-pci,netdev=hostnet3,id=net3,mac=54:52:c0:a8:ca:03,bus=pci.0,addr=0x5 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-58-9a511e10-lago-basic-/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev pty,id=charconsole0 -device virtconsole,chardev=charconsole0,id=console0 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x9 -msg timestamp=on

Guest:

[root@lago-basic-suite-master-host-0 ~]# ip -o -4 link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT qlen 1\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000\    link/ether 54:52:c0:a8:c9:02 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000\    link/ether 54:52:c0:a8:c8:02 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000\    link/ether 54:52:c0:a8:ca:02 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000\    link/ether 54:52:c0:a8:ca:03 brd ff:ff:ff:ff:ff:ff

[root@lago-basic-suite-master-host-0 ~]# ethtool eth1
Settings for eth1:
	Link detected: yes
[root@lago-basic-suite-master-host-0 ~]# ethtool -i eth1
driver: virtio_net
version: 1.0.0
firmware-version: 
expansion-rom-version: 
bus-info: 0000:00:03.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no


[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

Comment 10 Maxime Coquelin 2017-11-13 08:25:45 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

Comment 11 Yaniv Kaul 2017-11-13 08:42:53 UTC
(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

Comment 12 Yaniv Kaul 2017-11-13 09:39:59 UTC
(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

Comment 13 Maxime Coquelin 2017-11-13 09:51:38 UTC
(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

Comment 20 Dan Kenigsberg 2018-09-02 09:06:52 UTC
This has been included in RHV-4.2.5 by means of bug 1451342

Comment 21 msheena 2019-01-15 11:15:09 UTC
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

Comment 22 msheena 2019-01-22 08:44:52 UTC
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)

Comment 24 Dan Kenigsberg 2019-02-12 21:29:47 UTC
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.

Comment 25 Dominik Holler 2019-02-12 21:34:11 UTC
(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.

Comment 31 errata-xmlrpc 2019-05-08 12:35:59 UTC
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


Note You need to log in before you can comment on or make changes to this bug.