IPv6 support in XCP-ng for the management interface - feedback wanted

olivierlambert

Thanks for your feedback @LeMatz

@BenjiReis will take a look.

For the short notation, I think that was simply not taken into account.
What about the repo? It should work out of the box (our repo are IPv6 compatible)
XCP-ng Center is not maintained by us, so we won't solve this anyway. For XO, it should work out of the box. Your issue is with the XO deploy thing, we are aware of it

LeMatz

sure thing, thanks.

I edited the thing with the repo out of my post, I was just a bit too blind.

Is there any way on the XCP-ng host to test the DNS resolution? "dig" is not available there. Our host is somehow not able to resolve to mirrors.xcp-ng.org.
Our chosen DNS server is very well able to resolve your mirror.

I know that XCP-ng Center is not maintained by your team, but it's currently the only GUI that works for us :).

Is there a different way to deploy XO instead of the quick install? I'm not sure, if the build from source is worth the effort.

Thanks again,
Matthias

hoerup

@lematz
In the first picture of "hostname and dns configuration":
It doesn't look like you have any double colon '::' in the first 2 entries but you have them in all fields on the last picture

LeMatz

@hoerup Jeeez, you are right, thanks a lot.
I'm feeling bad now

Reminder: do not work past 9 p.m. :D.

olivierlambert

haha good catch, so it might support short format ipv6 Can you double check?

LeMatz

@olivierlambert Well, I'd like to. But the console is giving me a hard time.

Our given DNS servers were not recognized:

I'm not able to change the entries. Hitting "Enter" does not do anything. For all the other entries works "Enter" perfectly.

Olivier recommended in https://xcp-ng.org/forum/topic/5412/installation-of-xo-with-just-one-ip/2?_=1642003322780 to use one IPv6 for dom0 and bind the IPv4 to a VM like pfSense. Thanks to MAC-address binding of our provider, that made everything worse. Of cause we can't have the same MAC-address on more than one NIC.

I think this IPv6 experiment ends here for us.

Thanks for all the answers and help!
Matz

olivierlambert

Sadly @BenjiReis is really busy ATM working on our next 8.2.1 release But he'll come back here as soon he can!

LeMatz

It's okay, releases are important

Dennis 0

Short format works fine

IPv6-only server still running for almost a year now without problems.

Not using it for anything mission critical as of yet, as installing updates is a bit "exciting" trying to combine main repo with the experimental ipv6-repo (avoid overwriting ipv6-patched packages on update) but still getting CVE's fixed from kernel etc. Haven't broken anything yet (AFAIK) - just looking forward to see this in a release.

(+ There might be a few useful details hiding here: https://github.com/xcp-ng/xcp/issues/437 in case)

DennisGlindhart created this issue in xcp-ng/xcp

closed IPv6 support on host #437

BenjiReis

Hi all! Long time no see ^^

I'm glad to say i'm back on IPv6 and will (soon-ish) provide a new IPv6 iso to test XCP-ng with an IPv6 management interface.
I've made some fixes to DNS management.

Before the new ISO i'd like to support ideally DHCPv6 and autoconf.
For now I managed to :

sometimes have an IP with DHCPv6 and sometimes a DNS - no gateway but it's exepected with stateless DHCPv6.
Have an IP with Autoconf - No Gateway & no DNS

I'm looking for help as my field of expertise is more ocaml dev than IPv6.
I'm thinking especially of @AtaxyaNetwork and @bnerickson that I know have more knowledge than me for IPv6. Any help from a forum users would be greatly appreciated.

For DHCPv6 this is the conf of dhclient:

interface "xenbr0" {
  send fqdn.fqdn = gethostname();
  request subnet-mask, broadcast-address, time-offset, host-name, interface-mtu, dhcp6.nis-servers, dhcp6.nisp-servers, nis-domain-name, nisp-domain-name, dhcp6.sntp-servers, dhcp6.fqdn, routers, dhcp6.domain-search, dhcp6.name-servers;
}

For Autoconf here's what's done:

/sbin/sysctl -q -w net.ipv6.conf.xenbr0.autoconf=1
/sbin/sysctl -q -w net.ipv6.conf.xenbr0.accept_ra=1

Am I missing something obvious? I can provide more info if requested.
Also I can made available a test iso before the real one but it'd be really a experimental ISO.

Thanks!

BenjiReis

@AtaxyaNetwork also, i tried to reproduce you XOA deploy issue buf failed, did you add [] around the IPv6 of your XCP-ng when filling up the deploy form?

Thanks.

AtaxyaNetwork

@BenjiReis Hello !
I don't remember exactly, but I will try to retest all in the incoming days

BenjiReis

@AtaxyaNetwork there are some issues, but on XOA's side.
For now the deploy script specifically wait for an IPv4 to complete succesfully so it won't even though the XOA VM is up and running.
For some reason it seems the XO app is not reachable with the IPv6 address in a web browser. I'm still investigating that.

AtaxyaNetwork

@BenjiReis Ok !
Don't hesitate to ping me if you need help to debug the XOA side

BenjiReis

@AtaxyaNetwork so infact the issue was with our IPv6 lab config (lol) so XOA is reachable in fact with an IPv6 address ahah.
So you can play with it.

Now i'm back on my DHCPv6/Autoconf/SLAAC investigations

BenjiReis

Hi all!

8.2.1 IPv6 ISO available!

Here's a new ISO for IPv6 based on XCP-ng 8.2.1!
The ISO can be used to upgrade an existing server installed with the previous IPv6 test ISO or install a brand new XCP-ng 8.2.1 with IPv6 support on management interface.

A non-IPv6 8.2.0 would remain non-IPv6 after an upgrade as it's not possible to edit the management interface's primary adress type.

An 8.2.0 IPv6 hosts can also be upgraded via yum: yum upgrade --enablerepo=xcp-ng-updates,xcp-ng-ipv6.

What's new

All 8.2.1 fixes
Better DNS management in the case of both IPv4 and IPv6 configured on a PIF
Partial support of IPv6 DHCP and autoconf

What to test

Your daily uses of XCP-ng but with IPv6
DHCP and autoconf (I have reached the limits of my knowledge so help from the community with more IPv6 expertise would be very VERY VERY helpful! :D)
The goal of this ISO release is mainly to get help and leads about what's missing in DHCP and Autoconf.

Any issue encountered (and what works fine also) can be reported in this thread.

Usual warning

This a test ISO with an experimental feature still in development.
IPv6 on management interface is not officially supported by XCP-ng yet and so, we do not recommend to use it for a production environment.

Thanks a lot for the help and I hope the ISO will work well for everyone.

AtaxyaNetwork

@BenjiReis Hello !
Thank you for the ISO !

I just tested the install in a VM (for the moment, soon I will have a physical machine available)

First review:
So far, the autoconf seem to be working !
But, during the installation, I provide a IPv6 DNS (the Cloudflare one, 2606:4700:4700::1111), but DNS is not working, as I have 1.1.1.1 in my /etc/resolv.conf
I don't know if is the autoconf who is pushing the 1.1.1.1 (i need to check my router first), but I think is better if when we give a DNS, it bypass the autoconf

More test is coming the next few day

(sorry if my English is a bit bad)

Thank you and the team for all you work !

BenjiReis

@AtaxyaNetwork thanks for the report.

I reproduced the issue, for some reason at first boot XCP-ng launch an IPv4 dhclient request (even though IPv4 is not configured on the management interface...) which overrides the DNS set after the request is replied to.

mbunkus

@BenjiReis I've just started giving the IPv6-enabled 8.2.1 a try. Right within the first hour I've stumbled across the following two issues on an IPv6-only server:

Repository mirrors

The preconfigured repositories use mirrors.xcp-ng.org. That one returns the address of an actual mirror. And if that mirror happens not to have an IPv6 address, doing anything (e.g. yum makecache) fails.

Re-running it might return on with AAAA records; then it does work — or maybe it'll be another AAAA-less mirror.

NFS mounting via host name

NFS mounting doesn't work if I use a host name that has both A and AAAA records (the problem isn't the A record, though). I've tried to do this via XOA. After entering everything the list of exports available on the server is actually populated, but selecting one will result in the following error in /var/log/SMlog:

Jun  9 19:38:55 ul SM: [7165] ['mount.nfs', 'sweet-chili.int.bunkus.org:/srv/nfs4/home/', '/var/run/sr-mount/probe', '-o', 'soft,proto=tcp,vers=3,acdirmin=0,acdirmax=0']
Jun  9 19:38:55 ul SM: [7165] FAILED in util.pread: (rc 32) stdout: '', stderr: 'mount.nfs: Network is unreachable
Jun  9 19:38:55 ul SM: [7165] '
Jun  9 19:38:55 ul SM: [7165] Raising exception [73, NFS mount error [opterr=mount failed with return code 32]]
Jun  9 19:38:55 ul SM: [7165] lock: released /var/lock/sm/sr
Jun  9 19:38:55 ul SM: [7165] ***** generic exception: sr_probe: EXCEPTION <class 'SR.SROSError'>, NFS mount error [opterr=mount failed with return code 32]
Jun  9 19:38:55 ul SM: [7165]   File "/opt/xensource/sm/SRCommand.py", line 110, in run
Jun  9 19:38:55 ul SM: [7165]     return self._run_locked(sr)
Jun  9 19:38:55 ul SM: [7165]   File "/opt/xensource/sm/SRCommand.py", line 159, in _run_locked
Jun  9 19:38:55 ul SM: [7165]     rv = self._run(sr, target)
Jun  9 19:38:55 ul SM: [7165]   File "/opt/xensource/sm/SRCommand.py", line 332, in _run
Jun  9 19:38:55 ul SM: [7165]     txt = sr.probe()
Jun  9 19:38:55 ul SM: [7165]   File "/opt/xensource/sm/NFSSR", line 170, in probe
Jun  9 19:38:55 ul SM: [7165]     self.mount(temppath, self.remotepath)
Jun  9 19:38:55 ul SM: [7165]   File "/opt/xensource/sm/NFSSR", line 133, in mount
Jun  9 19:38:55 ul SM: [7165]     raise xs_errors.XenError('NFSMount', opterr=exc.errstr)

The problem here is mount.nfs -o proto=tcp. As can be seen in man 5 nfs the udp and tcp protocols only use IPv4 where as udp6 and tcp6 only use IPv6. I'm not aware of a way of saying "use TCP as the protocol, resolve the name, prefer IPv6 over IPv4", unfortunately.

This isn't limited to XOA, obviously; the corresponding call xe sr-probe type=nfs device-config:server=sweet-chili.int.bunkus.org device-config:serverpath=/srv/nfs4/space fails the same way.

One possible way of addressing this could be to resolve the host name right before constructing the mount commands & using the correct proto depending on whether the management interface is IPv6 enabled.

Note that using an IPv6 address instead of a host name does not work either: even though sr-create works as proto=tcp6 is used in the mount calls according to /var/log/SMlog, the later sr-create does not work with similar error messages.

I can file issues for both on Github, if that helps. The second one in xcp-ng/xcp, I guess, but where would I file the first one? vatesfr/xen-orchestra?

BenjiReis

@mbunkus thanks for the report.

About entering an IPv6 address for NFS in XOA: did you put the [] around the IPv6?
If so and it still failed you can indeed create an issue on vatesfr/xen-orchestra repo (make sure to reference this thread if you do).

For the rest, no need to create issues, i'm aware of them and I'll note them in our internal board for next devs.

Regards