[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
xvifX.Y vs sysctl_create() returning 22 (EINVAL)
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)
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
- 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
- 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 "$1" 2>/dev/null || echo "$2"
- use it to query the "vifname" keys; obviously, keep the "xvifX.Y" as
- 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."
Main Index |
Thread Index |