IPv6 support in XCP-ng for the management interface - feedback wanted
@BenjiReis Ok !
Don't hesitate to ping me if you need help to debug the XOA side
@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
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.
- 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.
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.
@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)
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 184.108.40.206 in my /etc/resolv.conf
I don't know if is the autoconf who is pushing the 220.127.116.11 (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 !
@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.
@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:
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
Jun 9 19:38:55 ul SM:  ['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:  FAILED in util.pread: (rc 32) stdout: '', stderr: 'mount.nfs: Network is unreachable Jun 9 19:38:55 ul SM:  ' Jun 9 19:38:55 ul SM:  Raising exception [73, NFS mount error [opterr=mount failed with return code 32]] Jun 9 19:38:55 ul SM:  lock: released /var/lock/sm/sr Jun 9 19:38:55 ul SM:  ***** 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:  File "/opt/xensource/sm/SRCommand.py", line 110, in run Jun 9 19:38:55 ul SM:  return self._run_locked(sr) Jun 9 19:38:55 ul SM:  File "/opt/xensource/sm/SRCommand.py", line 159, in _run_locked Jun 9 19:38:55 ul SM:  rv = self._run(sr, target) Jun 9 19:38:55 ul SM:  File "/opt/xensource/sm/SRCommand.py", line 332, in _run Jun 9 19:38:55 ul SM:  txt = sr.probe() Jun 9 19:38:55 ul SM:  File "/opt/xensource/sm/NFSSR", line 170, in probe Jun 9 19:38:55 ul SM:  self.mount(temppath, self.remotepath) Jun 9 19:38:55 ul SM:  File "/opt/xensource/sm/NFSSR", line 133, in mount Jun 9 19:38:55 ul SM:  raise xs_errors.XenError('NFSMount', opterr=exc.errstr)
The problem here is
mount.nfs -o proto=tcp. As can be seen in
man 5 nfsthe
tcpprotocols only use IPv4 where as
tcp6only 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/spacefails 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
protodepending 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
proto=tcp6is used in the mount calls according to
/var/log/SMlog, the later
sr-createdoes 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?
@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-orchestrarepo (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.
Thanks for your work !
I'm little new in xcp-ng, I was on xen few year ago.
I'm trying xcp-ng with an ipv6 only server.
ISO file is Ok for install.
Just a little thing, mirrors of packages don't all have an ipv6 record, and on a ipv6 installation I have some error.
I just change the file
... baseurl=http://mirrors.xcp-ng.org/8/8.2/base/x86_64/ http://updates.xcp-ng.org/8/8.2/base/x86_64/ ...
... baseurl=https://updates.xcp-ng.org/8/8.2/base/x86_64/ ...
Hey good catch! Let me check and fix that ASAP!
Are you sure about this?
olivier@test:~$ ping mirrors.xcp-ng.org PING mirrors.xcp-ng.org(alpha.xcp-ng.org (2a01:240:ab08:2::2)) 56 data bytes 64 bytes from alpha.xcp-ng.org (2a01:240:ab08:2::2): icmp_seq=1 ttl=63 time=0.386 ms 64 bytes from alpha.xcp-ng.org (2a01:240:ab08:2::2): icmp_seq=2 ttl=63 time=0.264 ms ^C --- mirrors.xcp-ng.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 0.264/0.325/0.386/0.061 ms olivier@test:~$ ping updates.xcp-ng.org PING updates.xcp-ng.org(alpha.xcp-ng.org (2a01:240:ab08:2::2)) 56 data bytes 64 bytes from alpha.xcp-ng.org (2a01:240:ab08:2::2): icmp_seq=1 ttl=63 time=0.672 ms 64 bytes from alpha.xcp-ng.org (2a01:240:ab08:2::2): icmp_seq=2 ttl=63 time=0.295 ms ^C --- updates.xcp-ng.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1010ms rtt min/avg/max/mdev = 0.295/0.483/0.672/0.188 ms
edit: aaaaah I see! It's just that SOME mirrors aren't IPv6 ready (ours are). This is indeed less trivial to solve. We'll discuss that with @stormi
Yes, the problem is on
http://mirrors.xcp-ng.org/8/8.2/base/x86_64/repodata/repomd.xml, there is
302 Foundto non-IPv6 urls
You can try with :
curl -IvL http://mirrors.xcp-ng.org/8/8.2/base/x86_64/repodata/repomd.xml
You will see the differents mirrors associated (Link), and some of them redirect to ipv4.
< Link: <https://xcpng-mirror.as208069.net/8/8.2/base/x86_64/repodata/repomd.xml>; rel=duplicate; pri=1; geo=fr Link: <https://xcpng-mirror.as208069.net/8/8.2/base/x86_64/repodata/repomd.xml>; rel=duplicate; pri=1; geo=fr < Link: <https://mirror.as50046.net/xcp-ng/8/8.2/base/x86_64/repodata/repomd.xml>; rel=duplicate; pri=2; geo=fr Link: <https://mirror.as50046.net/xcp-ng/8/8.2/base/x86_64/repodata/repomd.xml>; rel=duplicate; pri=2; geo=fr < Link: <https://mirror-xcpng.torontot.fr/8/8.2/base/x86_64/repodata/repomd.xml>; rel=duplicate; pri=3; geo=fr Link: <https://mirror-xcpng.torontot.fr/8/8.2/base/x86_64/repodata/repomd.xml>; rel=duplicate; pri=3; geo=fr < Link: <https://updates.xcp-ng.org/8/8.2/base/x86_64/repodata/repomd.xml>; rel=duplicate; pri=4; geo=fr Link: <https://updates.xcp-ng.org/8/8.2/base/x86_64/repodata/repomd.xml>; rel=duplicate; pri=4; geo=fr < Location: https://rg2-xcpng-mirror.reptigo.fr/8/8.2/base/x86_64/repodata/repomd.xml Location: https://rg2-xcpng-mirror.reptigo.fr/8/8.2/base/x86_64/repodata/repomd.xml ... couldn't connect to host at rg2-xcpng-mirror.reptigo.fr:443: Failed to connect to 18.104.22.168
Howdy, all, just wondering what the status of this feature is as I'm looking to go IPv6-only on my LAN. If it's complete, is there a way for me to add it to an existing installation of 8.2.1 (stable, i.e. an installation that was not made using one of test ISOs mentioned in this thread)?
EDIT: Just my luck that I see this feature mentioned in the 8.3 Beta 1 blog post minutes after I post this! If there's any recommended path to enter the beta so that I can upgrade my existing 8.2.1 installation to it and get this feature, I'd love to know how
Hi. Check XCP-ng 8.3 beta 1: https://xcp-ng.org/blog/2023/06/22/xcp-ng-8-3-beta-1/
Sorry, I replied based on the e-mail notification I got, and missed your EDIT