Mailing List Archive: Usage of ifconfig in /etc/xen/scripts/vif-route

Usage of ifconfig in /etc/xen/scripts/vif-route

Mar 29, 2019, 1:43 PM

Post #1 of 3 (448 views)

Hi there,

On a fresh install of xen-hypervisor (4.8) on a Debian stretch machine,
the vif-route script still uses ifconfig. This gives a non-descriptive
error when creating a domU, as you can see at the end of this email.
I've used xen-create-image for preparing the VM and can provide the
exact command if needed, although I'm quite sure this doesn't help for
solving the problem at hand.

The Debian stretch installation did not have net-tools installed. The
package net-tools installs ifconfig et al. Although this may be a
distribution packaging problem, I've checked the current HEAD
(cb70a26f78) of https://xenbits.xen.org/git-http/xen.git and the last
commit for tools/hotplug/Linux/vif-route was in 2014. git blame reveals
that the line containing ifconfig dates from 2011, commit cd98e007143.

Since ifconfig has been deprecated in a couple of major
distributions[0][1] some 8-10 years ago, I was wondering whether there
is an equivalent iproute2 command for creating the vif in
/etc/xen/scripts/vif-route. Currently it is: ifconfig ${dev} ${main_ip}
netmask 255.255.255.255 up

I've searched the mailing lists for an iproute2 equivalent, but did not
find it. I've tried to replace the ifconfig command (just below the
"online)" case) into `ip link add name ${dev} type dummy`, but that
errors with "RTNETLINK answers: File exists."
(/var/log/xen/xen-hotplug.log).

Anyone got a good idea for not using the deprecated ifconfig here?

Best regards,
Gerdriaan Mulder

[0] https://lists.debian.org/debian-devel/2009/03/msg00780.html
[1] https://www.archlinux.org/news/deprecation-of-net-tools/

+++ error messages from `xl create -c <configfile>`
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
/etc/xen/scripts/vif-route online [25514] exited with error status 1
libxl: error: libxl_device.c:1237:device_hotplug_child_death_cb: script:
/etc/xen/scripts/vif-route failed; error detected.
libxl: error: libxl_create.c:1461:domcreate_attach_devices: unable to
add nic devices
libxl: error: libxl.c:1575:libxl__destroy_domid: non-existant domain 14
libxl: error: libxl.c:1534:domain_destroy_callback: unable to destroy
guest with domid 14
libxl: error: libxl.c:1463:domain_destroy_cb: destruction of domain 14
failed

_______________________________________________
Xen-users mailing list
Xen-users@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-users

Re: Usage of ifconfig in /etc/xen/scripts/vif-route [ In reply to ]

hans at knorrie

Mar 31, 2019, 9:14 AM

Post #2 of 3 (446 views)

Permalink

Hoi,

On 3/29/19 9:43 PM, Gerdriaan Mulder wrote:
>
> On a fresh install of xen-hypervisor (4.8) on a Debian stretch machine,
> the vif-route script still uses ifconfig. This gives a non-descriptive
> error when creating a domU, as you can see at the end of this email.

Yes, ugly non-user-friendly error is ugly.

> I've used xen-create-image for preparing the VM and can provide the
> exact command if needed, although I'm quite sure this doesn't help for
> solving the problem at hand.
>
> The Debian stretch installation did not have net-tools installed. The
> package net-tools installs ifconfig et al. Although this may be a
> distribution packaging problem,

It is a packaging problem yes, you're right. That net-tools dependency
should be added.

> I've checked the current HEAD
> (cb70a26f78) of https://xenbits.xen.org/git-http/xen.git and the last
> commit for tools/hotplug/Linux/vif-route was in 2014. git blame reveals
> that the line containing ifconfig dates from 2011, commit cd98e007143.

A git log --follow, or tig --follow or any other way to follow renames,
reveils the code is from 2005.

> Since ifconfig has been deprecated in a couple of major
> distributions[0][1] some 8-10 years ago, I was wondering whether there
> is an equivalent iproute2 command for creating the vif in
> /etc/xen/scripts/vif-route. Currently it is: ifconfig ${dev} ${main_ip}
> netmask 255.255.255.255 up
>
> I've searched the mailing lists for an iproute2 equivalent, but did not
> find it. I've tried to replace the ifconfig command (just below the
> "online)" case) into `ip link add name ${dev} type dummy`, but that
> errors with "RTNETLINK answers: File exists."
> (/var/log/xen/xen-hotplug.log).

I did not test this, but I think it would be:

ip link set up dev ${dev}
ip addr add ${main_ip}/32 dev ${dev}

However, I'm wondering why it would use /32. I never used vif-route,
only vif-bridge in the past and vif-openvswitch for a long time now.

What do relevant lines in output of ip a and ip r look like after doing
it with the current script (with net-tools installed)?

> Anyone got a good idea for not using the deprecated ifconfig here?

I think it makes the most sense to convert the upstream linux scripts to
use iproute2 based commands...

tools/hotplug/Linux/vif-bridge
tools/hotplug/Linux/vif-nat
tools/hotplug/Linux/vif-route

...and then it will also end up in Debian, but that will be in Buster+1.
In the meantime we might be able to bring back the dependency on
net-tools piggy-backing on a stable/security update. It's important
functionality (I mean, who starts a domU without networking?) and is
broken by default if the user has no other packages that accidentally
drag in net-tools. (In my case that's munin-plugins-core everywhere I
think).

The vif-openvswitch script in there was added in 2013 and already uses
ip link.

I had a deja vu feeling about this, and it seems I fixed a similar thing
a while ago:

https://salsa.debian.org/xen-team/debian-xen/commit/354019fccc76d66f308cad9c41602bd5db9d767d

However, for some reason I wasn't clever enough to also start grepping
outside debian/ for other occurences...

So, summarizing:
1) Can you test the above suggested alternative?
2) We should create a Debian bug about this (add missing dependency)
against src:xen.
3) If you can test vif-route, then I know someone on IRC who uses
vif-bridge, which I can ask, and if someone else wants to test vif-nat,
then I don't mind formatting and sending a proper patch with the
changes. I only currently don't have spare time to set up different
networking scenarios in a test environment to trigger all usage scenarios.

Hans

> Best regards,
> Gerdriaan Mulder
>
> [0] https://lists.debian.org/debian-devel/2009/03/msg00780.html
> [1] https://www.archlinux.org/news/deprecation-of-net-tools/
>
> +++ error messages from `xl create -c <configfile>`
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
> /etc/xen/scripts/vif-route online [25514] exited with error status 1
> libxl: error: libxl_device.c:1237:device_hotplug_child_death_cb: script:
> /etc/xen/scripts/vif-route failed; error detected.
> libxl: error: libxl_create.c:1461:domcreate_attach_devices: unable to
> add nic devices
> libxl: error: libxl.c:1575:libxl__destroy_domid: non-existant domain 14
> libxl: error: libxl.c:1534:domain_destroy_callback: unable to destroy
> guest with domid 14
> libxl: error: libxl.c:1463:domain_destroy_cb: destruction of domain 14
> failed

_______________________________________________
Xen-users mailing list
Xen-users@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-users

Re: Usage of ifconfig in /etc/xen/scripts/vif-route [ In reply to ]

hello at moeilijklastig

Apr 1, 2019, 1:15 AM

Post #3 of 3 (446 views)

Permalink

Hi,

On 31/03/2019 18:14, Hans van Kranenburg wrote:
> A git log --follow, or tig --follow or any other way to follow renames,
> reveils the code is from 2005.

Ah, I've only looked at the last modification, but this is also useful
to know.

>> Since ifconfig has been deprecated in a couple of major
>> distributions[0][1] some 8-10 years ago, I was wondering whether there
>> is an equivalent iproute2 command for creating the vif in
>> /etc/xen/scripts/vif-route. Currently it is: ifconfig ${dev} ${main_ip}
>> netmask 255.255.255.255 up
> I did not test this, but I think it would be:
>
> ip link set up dev ${dev}
> ip addr add ${main_ip}/32 dev ${dev}

I've modified vif-route per your suggestion (after pasting the relevant
lines somewhat below here). That works as intended.

> However, I'm wondering why it would use /32. I never used vif-route,
> only vif-bridge in the past and vif-openvswitch for a long time now.

Interestingly enough, it appears adding the address is not necessary. In
vif-route, after verifying your suggestion worked, I've left out adding
the address and started the domU. To my surprise, this also worked. I
must note that the current setup uses NAT from vif* to eno1, but I can
test it without that if necessary.

> What do relevant lines in output of ip a and ip r look like after doing
> it with the current script (with net-tools installed)?

# ip a
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 44:37:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.0.252/24 brd 192.168.0.255 scope global eno1
valid_lft forever preferred_lft forever
inet6 2001:470:1f15:55f:xx/64 scope global mngtmpaddr dynamic
valid_lft 3585sec preferred_lft 3585sec
inet6 fe80::xx:/64 scope link
valid_lft forever preferred_lft forever
3: vif1.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet 192.168.0.252/32 brd 192.168.0.255 scope global vif1.0
valid_lft forever preferred_lft forever
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
# ip r
default via 192.168.0.1 dev eno1
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.252
198.51.100.42 dev vif1.0 scope link src 192.168.0.252

> ...and then it will also end up in Debian, but that will be in Buster+1.
> In the meantime we might be able to bring back the dependency on
> net-tools piggy-backing on a stable/security update. It's important
> functionality (I mean, who starts a domU without networking?) and is
> broken by default if the user has no other packages that accidentally
> drag in net-tools. (In my case that's munin-plugins-core everywhere I
> think).

(for what it's worth: `apt-cache rdepends net-tools`, the only
connection with xen is "dtc-xen").

> So, summarizing:
> 1) Can you test the above suggested alternative?

[x] done

> 2) We should create a Debian bug about this (add missing dependency)
> against src:xen.

> 3) If you can test vif-route, then I know someone on IRC who uses
> vif-bridge, which I can ask, and if someone else wants to test vif-nat,
> then I don't mind formatting and sending a proper patch with the
> changes. I only currently don't have spare time to set up different
> networking scenarios in a test environment to trigger all usage scenarios.

As mentioned, I've shortly tested vif-route, although dom0 uses NAT to
provide access to other networks for now. I'll test it with a proper
routed setup later this week.

-- Gerdriaan

_______________________________________________
Xen-users mailing list
Xen-users@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-users