[ovirt-users] change network MTU settings without taking all the VMs down?

[Darrell Budic]

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 at cloudspin.me> wrote:
> 
> So adding a new network was the way you went??On Jan 28, 2015 9:22 AM, Darrell Budic <budic at 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 at 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 at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users