XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

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

    Scheduled Pinned Locked Moved News
    61 Posts 12 Posters 20.1k Views 13 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L Offline
      lethedata @jivanpal
      last edited by

      @jivanpal It's good that that works but I can see high change for data loss if the installation changes or adjusts the partition size during the install. It could wipe the data and prevent recovery of the SR. That's also not mentioning any local modifications done to the hosts that may be required and have to be redone.

      As a side note, I don't need to do a migration of the management interface and was just theorizing that it looked possible to do via xAPI without reinstalling based on documentation I was reading. I ran into a situation on one of my lab servers where running an emergency reset broke v6 management interfaces. I just reinstalled but was curious of how one could recover from that state.

      1 Reply Last reply Reply Quote 1
      • BenjiReisB Offline
        BenjiReis Vates 🪐 XCP-ng Team @jivanpal
        last edited by

        In order to upgrade an XCP-ng host and put in IPv6 what could be done also:

        • Do the upgrade
        • xe host-management-disable && xe pif-set-primary-address-type uuid=<udid> primary_address_type=IPv6 ; xe host-management-reconfigure pif-uuid=<uuid>
        BenjiReisB 1 Reply Last reply Reply Quote 2
        • BenjiReisB Offline
          BenjiReis Vates 🪐 XCP-ng Team @BenjiReis
          last edited by

          @jivanpal you wrote in the 8.3 beta thread:

          There is no way to configure IPv6 on the management interface via xsconsole, such as if one wants to switch between static configuration, autoconf via RAs, or DHCPv6.

          True but we'll soon release an new version of xsconsole adapted for IPV6 allowing to configure IPv6 for management interface 👍

          There is apparently no support for IPv6 DNS servers, only IPv4. For example, if I try to add an IPv6 address like fd00::1 or [fd00::1] as a DNS server via xsconsole, there is apparently no change to the configuration. Editing /etc/resolv.conf works to achieve this (e.g. adding the line nameserver fd00::1), but this is known not to persist across reboots.

          Should be solved by the future xsconsole release as well 🙂

          There is apparently no support for RDNSS (advertisement of DNS servers in RAs rather than via DHCPv6).

          DHCPv6 is one of the major blindspot for now indeed, I'm working on it but I don't have much knowledge on this so any hints are welcome if you spot if something is missing somewhere.

          The "autoconf" option (available during installation, after choosing IPv6-only or dual-stack, and then being asked which mode to use to configure IPv6 addresses) appears to only be used at installation time to determine values such as the gateway's link-local address, the available address prefixes, and perform SLAAC and DAD, but then the resulting values are hard-coded and don't change according to changes in the environment, such as an upstream change in network prefix. (I will need to do some more testing to really confirm this, but this seems to be the case in my experience.) Compare this to when IPv4 is configured to use DHCP(v4), in which the management interface may have a different IPv4 address at different times, namely if it's assigned a different address by the DHCP server when it attempts to get or renew a lease.

          I'm not aware of this issue, i'll try to reproduce in our env.

          Some repos are unreachable in IPv6-only environments, which I'm aware is already known, and I can get around this by using NAT64 (either with CLAT to perform 464XLAT; or with DNS64), but this fact is currently a blocker for me to move to being IPv6-only.

          We contacted the mirrors many times, still trying to have'em all advertising IPv4 and 6 and also trying to find a solution that could "smartly" redirect towards a compatible mirror.

          Speaking of NAT64, this is just a question, I haven't tested or looked into this myself: Does XCP-ng include a CLAT daemon and support for auto-configuring 464XLAT using either the "PREF64" RA option (RFC8781) or resolution of ipv4only.arpa via a DNS64 server (RFC7050)?

          Haven't tested either for now, feel free to do and report if you get here before me.

          Again, thank you for the report, this is greatly appreciated and any info about what's missing for IPv6 (and perhaps how to achieve it when possible) is welcomed.

          Regards!

          jivanpalJ 1 Reply Last reply Reply Quote 2
          • stormiS Offline
            stormi Vates 🪐 XCP-ng Team
            last edited by

            FYI, I have finally reviewed all mirrors that provide updates for XCP-ng and disabled the remaining 6 which didn't support IPv6 (and notified their owners. I'll enable them again if they enable IPv6).

            So, if you experience any issues installing updates via IPv6, tell us so that we investigate faulty mirrors.

            T 1 Reply Last reply Reply Quote 1
            • T Offline
              TheFrisianClause @stormi
              last edited by

              @stormi

              Stil having this issue:

              Failed to set locale, defaulting to C
              Loaded plugins: fastestmirror
              Loading mirror speeds from cached hostfile
              Excluding mirror: updates.xcp-ng.org
               * xcp-ng-base: mirrors.xcp-ng.org
              Excluding mirror: updates.xcp-ng.org
               * xcp-ng-updates: mirrors.xcp-ng.org
              http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2a01:240:ab08:2::2: Cannot assign requested address"
              Trying other mirror.
              http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2a01:240:ab08:2::2: Cannot assign requested address"
              Trying other mirror.
              http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2a01:240:ab08:2::2: Cannot assign requested address"
              Trying other mirror.
              http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2a01:240:ab08:2::2: Cannot assign requested address"
              Trying other mirror.
              http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2a01:240:ab08:2::2: Cannot assign requested address"
              Trying other mirror.
              http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2a01:240:ab08:2::2: Cannot assign requested address"
              Trying other mirror.
              http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2a01:240:ab08:2::2: Cannot assign requested address"
              Trying other mirror.
              http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2a01:240:ab08:2::2: Cannot assign requested address"
              Trying other mirror.
              http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2a01:240:ab08:2::2: Cannot assign requested address"
              Trying other mirror.
              http://mirrors.xcp-ng.org/8/8.3/base/x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2a01:240:ab08:2::2: Cannot assign requested address"
              Trying other mirror.
              
              
               One of the configured repositories failed (XCP-ng Base Repository),
               and yum doesn't have enough cached data to continue. At this point the only
               safe thing yum can do is fail. There are a few ways to work "fix" this:
              
                   1. Contact the upstream for the repository and get them to fix the problem.
              
                   2. Reconfigure the baseurl/etc. for the repository, to point to a working
                      upstream. This is most often useful if you are using a newer
                      distribution release than is supported by the repository (and the
                      packages for the previous distribution release still work).
              
                   3. Run the command with the repository temporarily disabled
                          yum --disablerepo=xcp-ng-base ...
              
                   4. Disable the repository permanently, so yum won't use it by default. Yum
                      will then just ignore the repository until you permanently enable it
                      again or use --enablerepo for temporary usage:
              
                          yum-config-manager --disable xcp-ng-base
                      or
                          subscription-manager repos --disable=xcp-ng-base
              
                   5. Configure the failing repository to be skipped, if it is unavailable.
                      Note that yum will try to contact the repo. when it runs most commands,
                      so will have to try and fail each time (and thus. yum will be be much
                      slower). If it is a very temporary problem though, this is often a nice
                      compromise:
              
                          yum-config-manager --save --setopt=xcp-ng-base.skip_if_unavailable=true
              stormiS 1 Reply Last reply Reply Quote 0
              • stormiS Offline
                stormi Vates 🪐 XCP-ng Team @TheFrisianClause
                last edited by

                @TheFrisianClause This is not the right thread for your issue. I know it's tempting to think so because of the IPv6 address you see, but your host is not setup to use IPv6 for the management interface, right?

                T 1 Reply Last reply Reply Quote 0
                • T Offline
                  TheFrisianClause @stormi
                  last edited by

                  @stormi I have made a different thread, but the reply you posted. Made me feel like I could put my reply here.

                  stormiS 1 Reply Last reply Reply Quote 0
                  • stormiS Offline
                    stormi Vates 🪐 XCP-ng Team @TheFrisianClause
                    last edited by

                    @TheFrisianClause What's the other thread?

                    T 1 Reply Last reply Reply Quote 0
                    • T Offline
                      TheFrisianClause @stormi
                      last edited by

                      @stormi This is the link to it: https://xcp-ng.org/forum/topic/8459/yum-update-ipv6-issue

                      1 Reply Last reply Reply Quote 0
                      • jivanpalJ Offline
                        jivanpal @BenjiReis
                        last edited by

                        @BenjiReis I've finally taken the time to review this again now that I've updated to 8.3-rc1 via yum update, so here's some follow-up on the points I brought up previously:

                        There is no way to configure IPv6 on the management interface via xsconsole, such as if one wants to switch between static configuration, autoconf via RAs, or DHCPv6.

                        True but we'll soon release an new version of xsconsole adapted for IPV6 allowing to configure IPv6 for management interface 👍

                        There is apparently no support for IPv6 DNS servers, only IPv4. For example, if I try to add an IPv6 address like fd00::1 or [fd00::1] as a DNS server via xsconsole, there is apparently no change to the configuration. Editing /etc/resolv.conf works to achieve this (e.g. adding the line nameserver fd00::1), but this is known not to persist across reboots.

                        Should be solved by the future xsconsole release as well 🙂

                        Still not seeing any enhancements/changes in behaviour as of xsconsole 11.0.6-1.1.xcpng8.3.

                        There is apparently no support for RDNSS (advertisement of DNS servers in RAs rather than via DHCPv6).

                        DHCPv6 is one of the major blindspot for now indeed, I'm working on it but I don't have much knowledge on this so any hints are welcome if you spot if something is missing somewhere.

                        Just to clarify, this isn't related to DHCPv6, but RAs (Router Advertisement packets). I personally don't have a DHCPv6 server on my network at all. RDNSS is described in RFC8106.

                        Others may want to advertise DNS servers using DHCPv6, though, so that should still be tested as well.

                        The "autoconf" option (available during installation, after choosing IPv6-only or dual-stack, and then being asked which mode to use to configure IPv6 addresses) appears to only be used at installation time to determine values such as the gateway's link-local address, the available address prefixes, and perform SLAAC and DAD, but then the resulting values are hard-coded and don't change according to changes in the environment, such as an upstream change in network prefix. (I will need to do some more testing to really confirm this, but this seems to be the case in my experience.) Compare this to when IPv4 is configured to use DHCP(v4), in which the management interface may have a different IPv4 address at different times, namely if it's assigned a different address by the DHCP server when it attempts to get or renew a lease.

                        I'm not aware of this issue, i'll try to reproduce in our env.

                        I haven't been able to reproduce this either, and my prefix has changed a couple of times since I said this was an issue. Perhaps I just imagined it, hit a weird edge case, or didn't wait for the valid lifetime of the old prefix to expire; my router doesn't reliably advertise the fact that an old prefix is no longer valid.

                        Some repos are unreachable in IPv6-only environments, which I'm aware is already known, and I can get around this by using NAT64 (either with CLAT to perform 464XLAT; or with DNS64), but this fact is currently a blocker for me to move to being IPv6-only.

                        We contacted the mirrors many times, still trying to have'em all advertising IPv4 and 6 and also trying to find a solution that could "smartly" redirect towards a compatible mirror.

                        @stormi said in IPv6 support in XCP-ng for the management interface - feedback wanted:

                        FYI, I have finally reviewed all mirrors that provide updates for XCP-ng and disabled the remaining 6 which didn't support IPv6 (and notified their owners. I'll enable them again if they enable IPv6).

                        So, if you experience any issues installing updates via IPv6, tell us so that we investigate faulty mirrors.

                        I personally haven't had any issues reaching repos since then, but I haven't explicitly tested this or looked through the mirrorlist. I also don't think this is much of an issue in practice, since 464XLAT can be used; this is no longer a blocker from me, as I've reviewed the way I'm deploying IPv6-only. It's very nice to see you motivate / put pressure on mirror maintainers to make their sites accessible over IPv6 though, especially indirectly by simply removing such sites from the mirrorlist.

                        Speaking of NAT64, this is just a question, I haven't tested or looked into this myself: Does XCP-ng include a CLAT daemon and support for auto-configuring 464XLAT using either the "PREF64" RA option (RFC8781) or resolution of ipv4only.arpa via a DNS64 server (RFC7050)?

                        Haven't tested either for now, feel free to do and report if you get here before me.

                        I've got this working pretty easily by manually installing clatd from GitHub and its dependencies from EPEL and the other RHEL repos. It works, but isn't native. That being said, I don't know of any other Linux distros that natively support this yet. To my knowledge, there is ongoing work to implement this directly in Systemd. Clatd supports RFC7050, but doesn't support PREF64/RFC8781 as it's not particualrly feasible for it to do so, but hopefully Systemd is able to if/when it implements a CLAT.

                        This also isn't reliable across reboots / DHCP lease renewals because I have no simple way to disable IPv4 on the management interface. I haven't tried this with an installation where I've selected "IPv6-only" in the installer.

                        One practical issue I've experienced when using 464XLAT in this way is that XO Lite tries to contact the pool server in the frontend / client / web browser using JS fetch calls for URLs falling under https://localhost/, which would instead usually be under https://<pool server IPv4 address>/. These are the addresses that XO Lite will prompt the user to ensure that the browser trusts TLS certificates for if they are self-signed and no known CA has issued/signed them. As such, these don't work, since "localhost" from the XO Lite user's perspective isn't the same machine as the "localhost" that XO Lite is running on. If XO Lite supported making these calls using any of the pool servers' routable IPv6 addresses (e.g. ULAs or GUAs, but not LLAs), this would work just fine.

                        I may find some time to test these things on an "IPv6-only" installation, but I expect that will be after 8.3 has reached general release.

                        1 Reply Last reply Reply Quote 1
                        • First post
                          Last post