7:28 a.m.
I have a SAN Network defined in oVirt where I have enabled Jumbo frames
(by setting the MTU to 9000).
Still I see now VM Nic;s attached to this network get MTU 1500 and are
therefore basically not working.
I have created several VMs before all (still) have Jumbo Frames on the
their san-interface, but newly created VMs get 1500.
Currently on 3.4 Beta2 (upgraded from alpha --> beta1 --->) and this
behaviour have started somewhere along the way..
The host physical interface
em2 Link encap:Ethernet HWaddr D0:67:E5:F9:2E:1C
inet6 addr: fe80::d267:e5ff:fef9:2e1c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:503209263 errors:0 dropped:0 overruns:0 frame:0
TX packets:483040537 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2395173035170 (2.1 TiB) TX bytes:408352341106
(380.3 GiB)
And on a VM
vnet25 Link encap:Ethernet HWaddr FE:1A:4A:2F:D2:A3
inet6 addr: fe80::fc1a:4aff:fe2f:d2a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:167 errors:0 dropped:0 overruns:0 frame:0
TX packets:137 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:17662 (17.2 KiB) TX bytes:26684 (26.0 KiB)
If manully setting the MTU everything work as expected.. (Until you
reboot the machine)
Anyone else seen this ?
Rgds Jonas
5:36 a.m.
----- Original Message -----
From: "Jonas Israelsson" <jonas(a)israelsson.com>
To: users(a)ovirt.org
Sent: Saturday, March 1, 2014 3:28:15 PM
Subject: [Users] oVirt 3.4 - MTU Override not honoured by virtual NICs
I have a SAN Network defined in oVirt where I have enabled Jumbo frames
(by setting the MTU to 9000).
Still I see now VM Nic;s attached to this network get MTU 1500 and are
therefore basically not working.
I have created several VMs before all (still) have Jumbo Frames on the
their san-interface, but newly created VMs get 1500.
Currently on 3.4 Beta2 (upgraded from alpha --> beta1 --->) and this
behaviour have started somewhere along the way..
The host physical interface
em2 Link encap:Ethernet HWaddr D0:67:E5:F9:2E:1C
inet6 addr: fe80::d267:e5ff:fef9:2e1c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:503209263 errors:0 dropped:0 overruns:0 frame:0
TX packets:483040537 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2395173035170 (2.1 TiB) TX bytes:408352341106
(380.3 GiB)
And on a VM
vnet25 Link encap:Ethernet HWaddr FE:1A:4A:2F:D2:A3
inet6 addr: fe80::fc1a:4aff:fe2f:d2a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:167 errors:0 dropped:0 overruns:0 frame:0
TX packets:137 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:17662 (17.2 KiB) TX bytes:26684 (26.0 KiB)
If manully setting the MTU everything work as expected.. (Until you
reboot the machine)
Anyone else seen this ?
This sounds like a reasonable behaviour since there is a clear separation
between the host networking configuration to the vms networking configuration.
What you're attempting to achieve is guest-os level network configuration which
isn't controlled by the ovirt-engine.
The current method to control guest network internals is by using the
cloud-init-integration
however MTU is not part of its api [1].
You can add it to the 3.5 planning thread as a requested item.
[1] http://www.ovirt.org/Features/Cloud-Init_Integration
Rgds Jonas
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
7:59 a.m.
This sounds like a reasonable behaviour since there is a clear
separation
between the host networking configuration to the vms networking configuration.
What you're attempting to achieve is guest-os level network configuration which
isn't controlled by the ovirt-engine.
If I understand this correctly the the
VMs NIC is mapped to a Virtual
Nic in the Host with a similar MAC, created when the VM starts.
# VM internal NIC
eth1 Link encap:Ethernet HWaddr 00:1A:4A:2F:D2:A8
inet addr:192.168.43.15 Bcast:192.168.43.255 Mask:255.255.255.0
inet6 addr: fe80::21a:4aff:fe2f:d2a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:468 (468.0 b) TX bytes:578 (578.0 b)
# Host Virtual Nic
vnet26 Link encap:Ethernet HWaddr FE:1A:4A:2F:D2:A8
inet6 addr: fe80::fc1a:4aff:fe2f:d2a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:648 (648.0 b) TX bytes:468 (468.0 b)
As you can see the MTU differs between the two. If setting the MTU of
vnet26 to match the VM;s internal nic (and the host physical NIC for
that matter), everything is back to normal.
I'm quite sure that nic (vnet26) must match what is set on the host
physical NIC, I cant see how it would work otherwise.
Rgds Jonas
8:49 a.m.
----- Original Message -----
> This sounds like a reasonable behaviour since there is a clear separation
> between the host networking configuration to the vms networking
> configuration.
> What you're attempting to achieve is guest-os level network configuration
> which
> isn't controlled by the ovirt-engine.
If I understand this correctly the the VMs NIC is mapped to a Virtual
Nic in the Host with a similar MAC, created when the VM starts.
# VM internal NIC
eth1 Link encap:Ethernet HWaddr 00:1A:4A:2F:D2:A8
inet addr:192.168.43.15 Bcast:192.168.43.255 Mask:255.255.255.0
inet6 addr: fe80::21a:4aff:fe2f:d2a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:468 (468.0 b) TX bytes:578 (578.0 b)
# Host Virtual Nic
vnet26 Link encap:Ethernet HWaddr FE:1A:4A:2F:D2:A8
inet6 addr: fe80::fc1a:4aff:fe2f:d2a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:648 (648.0 b) TX bytes:468 (468.0 b)
Tap should definitely have the same MTU as the bridge it's started on.
As you can see the MTU differs between the two. If setting the MTU of
vnet26 to match the VM;s internal nic (and the host physical NIC for
that matter), everything is back to normal.
I'm quite sure that nic (vnet26) must match what is set on the host
physical NIC, I cant see how it would work otherwise.
You are correct, can you please open a bug for it?
Also please specify libvirt/vdsm/kernel versions that you're using (maybe it was
already fixed in updated version?)
Rgds Jonas
12:19 p.m.
On 02/03/14 15:49, Mike Kolesnik wrote:
----- Original Message -----
>> This sounds like a reasonable behaviour since there is a clear separation
>> between the host networking configuration to the vms networking
>> configuration.
>> What you're attempting to achieve is guest-os level network configuration
>> which
>> isn't controlled by the ovirt-engine.
> If I understand this correctly the the VMs NIC is mapped to a Virtual
> Nic in the Host with a similar MAC, created when the VM starts.
>
> # VM internal NIC
> eth1 Link encap:Ethernet HWaddr 00:1A:4A:2F:D2:A8
> inet addr:192.168.43.15 Bcast:192.168.43.255 Mask:255.255.255.0
> inet6 addr: fe80::21a:4aff:fe2f:d2a8/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
> RX packets:6 errors:0 dropped:0 overruns:0 frame:0
> TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:468 (468.0 b) TX bytes:578 (578.0 b)
>
> # Host Virtual Nic
> vnet26 Link encap:Ethernet HWaddr FE:1A:4A:2F:D2:A8
> inet6 addr: fe80::fc1a:4aff:fe2f:d2a8/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:8 errors:0 dropped:0 overruns:0 frame:0
> TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:500
> RX bytes:648 (648.0 b) TX bytes:468 (468.0 b)
Tap should definitely have the same MTU as the bridge it's started on.
>
> As you can see the MTU differs between the two. If setting the MTU of
> vnet26 to match the VM;s internal nic (and the host physical NIC for
> that matter), everything is back to normal.
>
> I'm quite sure that nic (vnet26) must match what is set on the host
> physical NIC, I cant see how it would work otherwise.
You are correct, can you please open a bug for it?
Also please specify libvirt/vdsm/kernel versions that you're using (maybe it was
already fixed in updated version?)
Thanks, BZ 1071660
3714
days inactive
3715
days old
4 comments
3 participants
participants (3)
-
Jonas Israelsson -
Mike Kolesnik -
Moti Asayag