Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

xvifX.Y vs sysctl_create() returning 22 (EINVAL)

Hi list,

Due to the syntax currently used for xvif(4) interfaces, their creation
during a domU start results in the following messages logged:

Jan 10 00:02:26 paris /netbsd: xvif108.0: could not attach sysctl nodes
Jan 10 00:02:57 paris /netbsd: sysctl_createv: sysctl_create(xvif108.0)
returned 22

Consequently, the interface is not visible under net.interfaces in

Fixing this issue would need to get rid of the "." from the interface
name, and replace it with a correct char acceptable for the MIB.

Sadly, we cannot make such a "radical" change without breaking current
scripts used for vif initialization, like etc/xen/scripts/vif-ip or
vif-bridge (the pattern is hardcoded within).

I would like to propose the following changes, so to ease the transition
a bit:

- similar to what is done for XenSource's Linux, create a "vifname" node
inside XenStore, which contains the vifnames (doh!) for the domain just
created. In our case, for dom0, that would be "xvifX-Y", or anything
that avoid using dots in the name (X being domU ID and Y the frontend
interface ID).

- modify the vif-ip and vif-bridge scripts: introduce a
"xenstore_read_default" function, like done for Linux:

# xenstore_read_default <path> <default>
# Read the given path, returning the value there or the given default
# if the path is not present.
xenstore_read_default() {
  xenstore-read "$1" 2>/dev/null || echo "$2"

- use it to query the "vifname" keys; obviously, keep the "xvifX.Y" as
default syntax.

- wait for an arbitrary amount of time (TBD), so that Xen scripts get
eventually replaced by their newer versions.

- finally, modify the syntax in kernel. Consequence: vifname will change
its syntax within xenstore for each new domU, and the newer scripts will
take that into account "automagically."


Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index