Hello everyone,
I'm also a new contributer to XCP-ng!
For now I'll be working with @ronan-a on the SMAPIv3 plugins.
After that probably on open vSwitch.
Benjamin
Hello everyone,
I'm also a new contributer to XCP-ng!
For now I'll be working with @ronan-a on the SMAPIv3 plugins.
After that probably on open vSwitch.
Benjamin
Hi all!
After 4 months of effort we are very happy to provide a 1st test ISO with IPv6 support in XCP-ng dom0.
Read our devblog here: https://xcp-ng.org/blog/2021/02/09/ipv6-in-xcp-ng/
The ISO is available here and the corresponding SHA is: 177eade2efa8b6c989847c970e5cab3e6eb24de5a2eef153a0fc422071f9234b
.
Keep in mind this is a test ISO so do NOT use it in production and please report in this thread if you encounter any issue or if your tests are going well.
The devblog contains the known limitation of the ISO, updates will be provided in this thread when fixes and features are available.
I hope you'll have fun with it!
Hi!
In your Pool view there's a network tab where you can rename your networks by clicking on their name and enter a new one.
Regards.
@gb-123 Hi!
All the info are available on the host by running
ovs-vsctl show
and look a the lines relevant to your bridge.
Also the following fields are available in your private network other_config
:
- `other_config`:
- `xo:sdn-controller:encapsulation` : encapsulation protocol used for tunneling (either `gre` or `vxlan`)
- `xo:sdn-controller:encrypted` : `true` if the network is encrypted
- `xo:sdn-controller:pif-device` : PIF device on which the tunnels are created, must be physical or VLAN or bond master and have an IP configuration
- `xo:sdn-controller:preferred-center` : The host UUID to prioritize as network center (or not defined)
- `xo:sdn-controller:private-network-uuid`: UUID of the private network, same across pools
- `xo:sdn-controller:vlan` : VLAN of the PIFs on which the network is created
- `xo:sdn-controller:vni` : VxLAN Network Identifier,
and the MTU
is a field of the network as well.
So xe network-param-get uuid=<your network uuid> param-name=MTU
and xe network-param-get uuid=<your network uuid> param-name=other-config param-key=xo:sdn-controller:encrypted
Or should give everything you need!
Regards
@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!
In order to upgrade an XCP-ng host and put in IPv6 what could be done also:
xe host-management-disable && xe pif-set-primary-address-type uuid=<udid> primary_address_type=IPv6 ; xe host-management-reconfigure pif-uuid=<uuid>
@Fungusware Hi!
Yes this feature is supported at XAPI level, the VM.snapshot
method now has a ignore_vdis
field which is a list of VDI ref to not include in the snapshot.
This also available through xe
:
xe vm-snapshot vm=... ignore-vdi-uuids=uuid1,uuid2...
Regards
Hi all!
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
.
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.
New update candidate are available for testing and due to be released as official updates.
Original topic:
yum clean metadata --enablerepo=xcp-ng-testing
yum update xsconsole --enablerepo=xcp-ng-testing
systemctl restart xsconsole.service
Changing the DNS settings from the XSConsole and the change is retain after a reboot.
Good news, ISCSI shared storage already works in IPv6 with no package update!
An update will be released in the coming weeks for NFS support in the IPv6 case!
Has anyone play with the ISO? Any kind of feedback is very welcomed!
@olivierlambert Pretty easy since everything is stored in the network other_config
field.
@gb-123 AFAIK the host doesn't call XO, if you shut XO off, the private network would continue to work but its state wouldn't change.
It means if you restart an host etc the connection to this host would be lost.
The logs depends on how your installed XO or XOA etc so you might want to go through our doc!
Cheers
@gb-123 The tunnel are numbered by order of creation by XAPI, you can't change them.
I don't XCP-ng 8.3 has an issue since we use it internally and the SDN is working fine on our side.
I think some events are triggering the SDN controller to add the host over and over and during the adding of the host the connection might be perturbated. You should take a look a look at XO's logs to see if you can find something that might trigger the SDN controller.
Does the host added frequently has another weird behavior?
@gb-123 That's weird
is there another SDN controller connected to your pools? (not necessarily an XO SDN controller) that would override the certificates of XO?
Are there any XAPI error (in /var/log/xensource.log
) when you restart your VM?
@gb-123 Hi!
All the info are available on the host by running
ovs-vsctl show
and look a the lines relevant to your bridge.
Also the following fields are available in your private network other_config
:
- `other_config`:
- `xo:sdn-controller:encapsulation` : encapsulation protocol used for tunneling (either `gre` or `vxlan`)
- `xo:sdn-controller:encrypted` : `true` if the network is encrypted
- `xo:sdn-controller:pif-device` : PIF device on which the tunnels are created, must be physical or VLAN or bond master and have an IP configuration
- `xo:sdn-controller:preferred-center` : The host UUID to prioritize as network center (or not defined)
- `xo:sdn-controller:private-network-uuid`: UUID of the private network, same across pools
- `xo:sdn-controller:vlan` : VLAN of the PIFs on which the network is created
- `xo:sdn-controller:vni` : VxLAN Network Identifier,
and the MTU
is a field of the network as well.
So xe network-param-get uuid=<your network uuid> param-name=MTU
and xe network-param-get uuid=<your network uuid> param-name=other-config param-key=xo:sdn-controller:encrypted
Or should give everything you need!
Regards
It's in the backlog indeed but I don't know when the ETA to start this.
I guess an issue in the xen-api repo would be a good first step to see what the XAPI team think of the feature.
@lethedata Can you share the command you're running and the corresponding SMlog?
Thanks
@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!
In order to upgrade an XCP-ng host and put in IPv6 what could be done also:
xe host-management-disable && xe pif-set-primary-address-type uuid=<udid> primary_address_type=IPv6 ; xe host-management-reconfigure pif-uuid=<uuid>