I wound up manually changing the network configs on my hosts during other updates, one at a time. Then I migrated off the lower MTU host and repeated. Seemed to be minor extra bit of pause after migration completed, then things were fine (and I manually updated MTU settings on the VMs at that time, without rebooting/shutdowns). I did have to reboot one VM that went to 100% cpu and didn’t recover, but it has done that before and I think it’s a different problem with that one in particular, not the process. Then I repeated on the other host. Both though the networks in question were not synchronized, but came up fine away. Once that was all done, I updated the MTU values via the database, and now ovirt thinks everything is happy. So the manaul process Loir describes for 3.4 works, and works for 3.5 if you manage it properly. I’m still set with my vdmds forced to ifcfg persistence due to troubles with bonded interfaces in 3.5, so this was easy for me. -Darrell

On Jan 28, 2015, at 11:37 AM, Donny Davis <donny@cloudspin.me> wrote:

So adding a new network was the way you went??On Jan 28, 2015 9:22 AM, Darrell Budic <budic@onholyground.com> wrote:

...

3.5.1. It’s really a “clean and tidy” thing now that I’ve got the network cleaned up, so not urgent but nice to have. Thanks for the info!

...

On Jan 28, 2015, at 4:05 AM, Dan Kenigsberg <danken@redhat.com> wrote:

On Wed, Jan 28, 2015 at 11:03:14AM +0200, Lior Vernia wrote:

...

Hi Darrell!

There's currently no clean way to do this - we'll be looking to fix this in 3.6 (https://bugzilla.redhat.com/show_bug.cgi?id=1055454).

You haven't mentioned which version of oVirt you're running - if it's 3.4 or lower, I think it would suffice to change ifcfg files on your hypervisors and restart the network service. The network will then appear as out-of-sync in the GUI, but should be fully functional with MTU 1500. You'd also want the network configuration to be saved in case of future rollbacks - Dan, how would that be done?

up to 3.4, nothing else should be done (assuming the network config was already declared "safe" and survived reboot). ifcfg is the only persistent copy.

...

If you're running 3.5, I think you need to run some vdsm shell commands on the hypervisor as we've added an abstraction layer for configuration persistence above ifcfg files - again I'll ask Dan to chime in.

In 3.5 we've added a Vdsm-side persistent copy of the network, which sits under /var/lib/vdsm/netconf/nets. You should edit the json definitions therein in order to ensure proper network startup after boot.

...

As for getting the engine network configuration to MTU 1500 (for future hypervisor configuration and for networks to not appear as out-of-sync on existing ones) without taking down all the VMs (or hot-unplugging NICs) at one point - I don't think there's currently a way other than hacking the DB... Just leaving the network out-of-sync on the hosts could result in inconveniences later on when configuring host networking.

Is it worth the trouble of getting MTU 1500 instead of 1448? I presume the difference in performance would be negligible. Or are you experiencing incoming frames being dropped due to having 1500 bytes instead of 1448?... Either way, as you mentioned taking down the VMs can be a last resort, or wait for 3.6 where it should be simpler :)

Yours, Lior.

On 27/01/15 19:43, Darrell Budic wrote:

...

I finally got a couple of networks our from behind a wan based layer 2 bridge that required me to run at MTU 1448, and would like to get back up to MTU 1500. I see the GUI won’t let me do that while the network is in use. Any way around this, clean or otherwise? Restarting VMs to update them is ok, just trying to avoid having to take everything down at the same time.

-Darrell _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users

_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users