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.
@McHenry on the host you want to join: check if /etc/stunnel/certs/sdn-controller-ca.pem
exists - if not create it: touch /etc/stunnel/certs/sdn-controller-ca.pem
and then
xe pool-certificate-uninstall name=sdn-controller-ca.pem
then retry the join.
@McHenry not sure what you mean.
You can easily join the host with no VMs to the other one by calling xe pool-join master-address=<ip of other host> master-username=... master-password=...
Then you should have a 2 hosts pool.
What make you think it's not possible?
@olivierlambert Pretty easy since everything is stored in the network other_config
field.
@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
@brezlord If it's not to much a bother that would be great yeah.
Comparing the xen-cmdline when doing the passthrough manually on 8.2 VS how it looks on 8.3 and when done via the XAPI.
@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>
@Ascar I assume TNS1-MIA
is running so XO shows it's running on the host xcp1-mia
in the pool xcp1-mia
whereas TNS2-MIA COBIA
is shutdown therefore running on no host at all and so XO only shows it belongs to the pool xcp1-mia
@Byte0 Hi the script is not provided by this repo but directly by the xapi rpm:
[10:47 r620-s2 ~]# rpm -qf /etc/xapi.d/plugins/firewall-port
xapi-core-1.249.36-1.2.xcpng8.2.x86_64
Anyway yes the check
method is weird because it answer the opposite of the reality - but... it's by design according to upstream: https://github.com/xapi-project/xen-api/blob/45d934eec88def324799e0c428df14e726eb8566/ocaml/xapi/dbsync_slave.ml#L129-L134
But the open/close
method works as expected and then you can see the rules are correctly added to iptables.
@maxxie XO / Settings / Servers is to show a list our your pool's masters so one per pool.
It's expected as only the master is connected to XO and then dispach the API calls to other hosts when relevant.
If the Pool view shows 2 hosts then you're good.
You can also ssh to any of your host and run xe host-list
you should see the 2 listed
@McHenry on the host you want to join: check if /etc/stunnel/certs/sdn-controller-ca.pem
exists - if not create it: touch /etc/stunnel/certs/sdn-controller-ca.pem
and then
xe pool-certificate-uninstall name=sdn-controller-ca.pem
then retry the join.
@Byte0 Hi!
/etc/xapi.d/plugins/firewall-port {open|close} port protocol
should do the trick. Beware we advised against modifying this config for obvious security consideration.
So know what you're doing
@McHenry not sure what you mean.
You can easily join the host with no VMs to the other one by calling xe pool-join master-address=<ip of other host> master-username=... master-password=...
Then you should have a 2 hosts pool.
What make you think it's not possible?
@McHenry The import should have given you an uuid once finished which si the uuid of the VM.
It should also appears when doing an xe vm-list
@McHenry hi
you need to call xe vm-import filename=/path/to/file.xva
@PimAarts hi!
"path": "2a10:3781:2ad:f5:92e2:baff:fe31:5b80:/mnt/Venus/ISO_Library"
Should be "path": "[2a10:3781:2ad:f5:92e2:baff:fe31:5b80]:/mnt/Venus/ISO_Library"
with brackets around the IPv6.
@PimAarts hi!
Thx for the report - I reproduced the issue and am investigating.
Meanwhile clicking on Cancel will give you access to XOLite