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