@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
?