OSA and bridge_role=primary on boot

[Benjamin Jakob Zimmermann]

Hello,
I am using debian stretch and I am trying to have openvswitch to work right
after rebooting the machine.

So far, I manually configure the card with znetconf and then start
openvswitch and then manually bring up the interfaces.

To visualize my approach, I list the commands (bridge and port had already
been added to ovs beforehand):
# znetconf -a [ccwdev0] -o layer2=1 -o bridge_role=primary
# systemctl start openvswitch-switch
# ip l s [ccwdev0] up
# ip l s br0 up

Everything works out fine, I can now live migrate vm's via virsh.

What options do I have to add to
/etc/sysconfig/hardware/config-ccw-0.0.[ccwdev0] to set the bridge_role
when the interface is brought up?

Best,
Benjamin.

[Viktor Mihajlovski]

Post by Benjamin Jakob Zimmermann
Hello,
I am using debian stretch and I am trying to have openvswitch to work right
after rebooting the machine.
So far, I manually configure the card with znetconf and then start
openvswitch and then manually bring up the interfaces.
To visualize my approach, I list the commands (bridge and port had already
# znetconf -a [ccwdev0] -o layer2=1 -o bridge_role=primary
# systemctl start openvswitch-switch
# ip l s [ccwdev0] up
# ip l s br0 up
Everything works out fine, I can now live migrate vm's via virsh.
What options do I have to add to
/etc/sysconfig/hardware/config-ccw-0.0.[ccwdev0] to set the bridge_role
when the interface is brought up?
Best,
Benjamin.

Hi,

I fear there's no out-of-the box support for the bridge_role property in
sysconfig-hardware. As a temporary circumvention you could apply the
following change in /etc/sysconfig/scripts/hardware/hwup-ccw-group:

1. locate the line containing
write_setting "portno" "$QETH_PORTNO'
2. insert the following line
write_setting "bridge_role" "$QETH_BRIDGE_ROLE'

Then you can add
QETH_BRIDGE_ROLE=primary
to the config file.

Needless to say that this will not survive a package update. You might
be better served by setting the property in a post-up command for the
interface.

I am not really sure whether it makes sense to add more properties to
the sysconfig handling because in the long run persistent CCW device
configurations should be done using chzdev, see
https://www.ibm.com/developerworks/linux/linux390/s390-tools-1.33.0.html#newtools
On the other hand, this will probably not happen for stretch :-(.

[Benjamin Jakob Zimmermann]

Ok,
thank you for pointing me into the right direction.

The working solution is the following entry in /etc/network/interfaces:
[...]
allow-ovs br0
iface br0 inet manual

allow-ovs [ccwdev0-encif]
iface [ccwdev0-encif]
pre-up znetconf -a [ccwdev0] -o layer2=1 -o bridge_role=primary
[...]

This way both interfaces come up as soon as I am starting open vswitch
('systemctl start openvswitch-switch').

I did not manage to set bridge_role in the post-up, since it is already
online at that point of time.
I had also no success with changes in /etc/sysconfig/scripts/
hardware/hwup-ccw-group.

Do you know if 'chzdev' will be in future s390-tools in stretch?

Post by Benjamin Jakob Zimmermann

Post by Benjamin Jakob Zimmermann
Hello,
I am using debian stretch and I am trying to have openvswitch to work

right

Post by Benjamin Jakob Zimmermann
after rebooting the machine.
So far, I manually configure the card with znetconf and then start
openvswitch and then manually bring up the interfaces.
To visualize my approach, I list the commands (bridge and port had

already

Post by Benjamin Jakob Zimmermann
# znetconf -a [ccwdev0] -o layer2=1 -o bridge_role=primary
# systemctl start openvswitch-switch
# ip l s [ccwdev0] up
# ip l s br0 up
Everything works out fine, I can now live migrate vm's via virsh.
What options do I have to add to
/etc/sysconfig/hardware/config-ccw-0.0.[ccwdev0] to set the bridge_role
when the interface is brought up?
Best,
Benjamin.

Hi,
I fear there's no out-of-the box support for the bridge_role property in
sysconfig-hardware. As a temporary circumvention you could apply the
1. locate the line containing
write_setting "portno" "$QETH_PORTNO'
2. insert the following line
write_setting "bridge_role" "$QETH_BRIDGE_ROLE'
Then you can add
QETH_BRIDGE_ROLE=primary
to the config file.
Needless to say that this will not survive a package update. You might
be better served by setting the property in a post-up command for the
interface.
I am not really sure whether it makes sense to add more properties to
the sysconfig handling because in the long run persistent CCW device
configurations should be done using chzdev, see
https://www.ibm.com/developerworks/linux/linux390/s390-tools-1.33.0.html#
newtools
On the other hand, this will probably not happen for stretch :-(.
--
Mit freundlichen GrÌßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
GeschÀftsfÌhrung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

[Viktor Mihajlovski]

Post by Benjamin Jakob Zimmermann
Ok,
thank you for pointing me into the right direction.
[...]
allow-ovs br0
iface br0 inet manual
allow-ovs [ccwdev0-encif]
iface [ccwdev0-encif]
pre-up znetconf -a [ccwdev0] -o layer2=1 -o bridge_role=primary
[...]
This way both interfaces come up as soon as I am starting open vswitch
('systemctl start openvswitch-switch').
I did not manage to set bridge_role in the post-up, since it is already
online at that point of time.
I had also no success with changes in /etc/sysconfig/scripts/
hardware/hwup-ccw-group.
Do you know if 'chzdev' will be in future s390-tools in stretch?

[...]
Well, it's contained in the upstream source package, so it would just be
a matter of including the binaries lszdev and chzdev (plus the man pages).
The other thing is that one has to get rid of the old-style config
files, e.g. by not installing them in the first place, which what Ubuntu
did.
It might be nice if the Ubuntu changes to s390-tools and
d-i/sysconfig-writer could be backported to Debian (Dimitri?).

[Dimitri John Ledkov]

On 26 April 2017 at 12:17, Viktor Mihajlovski

Post by Viktor Mihajlovski

Post by Benjamin Jakob Zimmermann
Ok,
thank you for pointing me into the right direction.
[...]
allow-ovs br0
iface br0 inet manual
allow-ovs [ccwdev0-encif]
iface [ccwdev0-encif]
pre-up znetconf -a [ccwdev0] -o layer2=1 -o bridge_role=primary
[...]
This way both interfaces come up as soon as I am starting open vswitch
('systemctl start openvswitch-switch').
I did not manage to set bridge_role in the post-up, since it is already
online at that point of time.
I had also no success with changes in /etc/sysconfig/scripts/
hardware/hwup-ccw-group.
Do you know if 'chzdev' will be in future s390-tools in stretch?

[...]
Well, it's contained in the upstream source package, so it would just be
a matter of including the binaries lszdev and chzdev (plus the man pages).
The other thing is that one has to get rid of the old-style config
files, e.g. by not installing them in the first place, which what Ubuntu
did.
It might be nice if the Ubuntu changes to s390-tools and
d-i/sysconfig-writer could be backported to Debian (Dimitri?).

Yeah, in Ubuntu we kind of cheat. The installer is using sysconfig
stuff, but at the end of the install uses chzdev to take a dump of the
running configuration and store that on disk. This way all installed
systems only use chzdev/lszdev.

You can install and use ubuntu package, and chzdev/lszdev configs are
not conflicting with existing stuff as they simply generate udev rules
that one places in /etc/udev/rules.d/ dir.

I was late on many things for stretch =/

Ideally I was hoping to have full chzdev support in d-i, such that one
can preseed any devices, with any of the supported args (e.g. to be
able to install the system with e.g. bridge_role=primary et al)

[Philipp Kern]

Post by Dimitri John Ledkov
Yeah, in Ubuntu we kind of cheat. The installer is using sysconfig
stuff, but at the end of the install uses chzdev to take a dump of the
running configuration and store that on disk. This way all installed
systems only use chzdev/lszdev.
You can install and use ubuntu package, and chzdev/lszdev configs are
not conflicting with existing stuff as they simply generate udev rules
that one places in /etc/udev/rules.d/ dir.
I was late on many things for stretch =/
Ideally I was hoping to have full chzdev support in d-i, such that one
can preseed any devices, with any of the supported args (e.g. to be
able to install the system with e.g. bridge_role=primary et al)

FWIW, you don't need to hold back on git commits to d-i for chzdev
support even during freeze time. We can also negotiate uploads to
experimental for s390-tools if needed.

Now if something like Viktor's suggestion would've worked, I think we
could've fixed stretch using that as well. But then it's true that
chzdev should be the way forward. And there's too little man power to
just make it happen in Debian right now.[*]

Kind regards
Philipp Kern

[*] I hold that Ubuntu could've just made it happen within Debian
without much trouble. Even though I sort of understand the context why
that didn't happen.