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