@olivierlambert Classic blunder It's working since rebooting, thanks
Best posts made by jivanpal
-
RE: Cannot see VM stats in XO on XCP-ng 8.3-beta2
-
RE: XCP-ng 8.3 beta 🚀
Feedback/comments relating to IPv6 after some usage of beta1 and beta2:
-
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. -
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 viaxsconsole
, there is apparently no change to the configuration. Editing/etc/resolv.conf
works to achieve this (e.g. adding the linenameserver fd00::1
), but this is known not to persist across reboots. -
There is apparently no support for RDNSS (advertisement of DNS servers in RAs rather than via DHCPv6).
-
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.
-
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.
-
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)?
-
-
RE: IPv6 support in XCP-ng for the management interface - feedback wanted
@stormi @BenjiReis I thought I'd document my upgrade process here, as I did a bunch of testing this week on a spare laptop before finally doing it for real last night, and it all went very smoothly in the end. Perhaps all of this can be done by the installer as a user-friendly means of upgrading to add IPv6 support without needing any changes in XAPI:
- Make note of the current partition table, because it will be wiped and the SR partition will not be recreated during the installation process. Mine was as follows:
# lsblk /dev/sda NAME MAJ:MIN RM SIZE sda 8:0 0 21.8T 0 disk ├─sda4 8:4 0 512M 0 part /boot/efi ├─sda2 8:2 0 18G 0 part ├─sda5 8:5 0 4G 0 part /var/log ├─sda3 8:3 0 21.8T 0 part │ └─XSLocalEXT--d62dbe0a--b8b8--143f--6f29--3829124d35d4-d62dbe0a--b8b8--143f--6f29--3829124d35d4 253:0 0 21.8T 0 lvm /run/sr-mount/d62dbe0a-b8b8-143f-6f29-3829124d35d4 ├─sda1 8:1 0 18G 0 part / └─sda6 8:6 0 1G 0
# gdisk -l /dev/sda [...] First usable sector is 34, last usable sector is 46875541470 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 46139392 83888127 18.0 GiB 0700 2 8390656 46139391 18.0 GiB 0700 3 87033856 46875541470 21.8 TiB 8E00 4 83888128 84936703 512.0 MiB EF00 5 2048 8390655 4.0 GiB 0700 6 84936704 87033855 1024.0 MiB 8200
-
Ensure that you have an instance of XO (XenOrchestra) running on a different machine. Use that instance to create a backup of the pool metadata of the machine you'll be adding IPv6 support to.
-
Install XCP-ng 8.3 from scratch on the machine, overwriting the existing installation. Ensure that no disks are selected for use as an SR. This will wipe the partition table and create new partitions for the OS, but leave unpartitioned space where the SR partition would otherwise be. Since versions 8.2 and 8.3 use the same partition layout, you should get the same partition sizes, thereby leaving the SR filesystem intact on the disk, but inaccessible. Since you opted not to create an SR partition, the partition numbers will differ slightly. Immediately after installation, mine was as follows:
# lsblk /dev/sda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 21.8T 0 disk ├─sda2 8:2 0 18G 0 part ├─sda5 8:5 0 4G 0 part /var/log ├─sda3 8:3 0 512M 0 part /boot/efi ├─sda1 8:1 0 18G 0 part / └─sda6 8:6 0 1G 0 part [SWAP]
# gdisk -l /dev/sda [...] First usable sector is 34, last usable sector is 46875541470 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 46139392 83888127 18.0 GiB 0700 2 8390656 46139391 18.0 GiB 0700 3 83888128 84936703 512.0 MiB EF00 5 2048 8390655 4.0 GiB 0700 6 84936704 87033855 1024.0 MiB 8200
-
Reboot into the new installation, and then recreate the SR partition using
gdisk
:- Run
gdisk /dev/sda
(or other device node name as appropriate). - Create a new partition by entering
n
, then use the default values for the start and end sector (these should automatically match those of the SR partition as it appeared in the original partition table prior to reinstallation), and use8e00
for the partition type. - Remove the partition label by entering
c
, then the partition number (should be4
), then enter nothing for the name. - Check the new partition table by entering
p
; the start and end sector values should match those of the original partition table, but the partition numbers may differ. - Write the changes with
w
, or quit without writing changes withq
.
- Run
-
Connect to the new installation using the remote XO instance, then create a new backup of this fresh installation's pool metadata.
-
Alter the first backup's file
data
(which is an XML file) as follows:-
In the section
<table name="PBD">
, replace the occurrence of the device node path for the SR with the correct path as it would be for the new installation. In particular, the disk's SCSI or other ID may have changed, and the SR partition's number in the partition table has probably changed from 3 to 4. In my case, I had to change it from/dev/disk/by-id/scsi-36...fa-part3
to/dev/disk/by-id/scsi-36...a9-part4
. -
In the second backup's file
data
, find the section<table name="PIF">
. Within it, find the<row>
pertaining to the management interface. Copy the values of the following<row>
attributes, overwriting the corresponding attributes in the first backup's filedata
with their values, so that the new installation's values for the IPv4- and IPv6-related configuration parameters are used:DNS
IP
IPv6
gateway
ip_cofiguration_mode
ipv6_configuration_mode
ipv6_gateway
netmask
primary_address_type
-
-
Use XO to restore the now-altered first backup to the new installation. It will automatically reboot, and all storage backends, virtual disk metadata, VMs, and VM metadata should be restored and working, along with IPv6 on the management interface.
Latest posts made by jivanpal
-
RE: Cannot see VM stats in XO on XCP-ng 8.3-beta2
@olivierlambert Classic blunder It's working since rebooting, thanks
-
RE: Cannot see VM stats in XO on XCP-ng 8.3-beta2
@olivierlambert No change in behaviour; just updated XO from
25982ca
todcdf288
, and checked that dom0 is up to date also:[16:12 harmonium ~]# yum clean expire-cache Loaded plugins: fastestmirror Cleaning repos: xcp-ng-base xcp-ng-updates 2 metadata files removed [16:12 harmonium ~]# yum update 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 xcp-ng-base/signature | 473 B 00:00:00 xcp-ng-base/signature | 3.0 kB 00:00:00 !!! xcp-ng-updates/signature | 473 B 00:00:00 xcp-ng-updates/signature | 3.0 kB 00:00:00 !!! xcp-ng-base/primary_db | 3.1 MB 00:00:15 No packages marked for update
-
Cannot see VM stats in XO on XCP-ng 8.3-beta2
As mentioned here: https://xcp-ng.org/forum/post/72590
I was able to get the new version of xo-lite via
yum update
(and it's looking good!), so I have everything up to date, though I'm still running Xen 4.13, not Xen 4.17. However, stats in XO (not XO Lite) still aren't working for me for some reason; I'm running XO v5.92.0 (commit25982ca
, from today [29 Feb 2024]), built from source. All VMs are running xe-guest-utilities / management agent 7.30.0-2, as that is the version provided by my installation of XCP-ng.I have several different VM types (Debian 11, Debian 12, Debian 12 from cloud images initialised using cloud-init, Ubuntu 22.04), all of which stats were working for under XCP-ng 8.2, I believe with the same version of xe-guest-utilities, which I installed from the ISO available under the "XCP-ng Tools" iso-repo. All VMs show "Management agent 7.30.0-2 detected" and I can see other data, such as IP addresses assigned to VIFs, but the Stats subpage just shows "No stats."
-
RE: XCP-ng 8.3 beta 🚀
@stormi I was able to get the new version of xo-lite via
yum update
(and it's looking good!), so I have everything up to date, though I'm still running Xen 4.13, not Xen 4.17. However, stats in XO (not XO Lite) still aren't working for me for some reason; I'm running XO v5.92.0 (commit25982ca
, from today), built from source. All VMs are running xe-guest-utilities / management agent 7.30.0-2, as that is the version provided by my installation of XCP-ng. -
RE: XCP-ng 8.3 beta 🚀
@TheFrisianClause No, my remark is about wanting to resolve any and all DNS queries using a DNS server that is accessible over IPv6 (such as wanting to use Google's 2001:4860:4860::8888 rather than Google's 8.8.8.8, or in my case wanting to use my LAN's DNS server at fd00::1 rather than 10.0.0.1), whereas yours is about your host attempting to connect to IPv6 addresses that it obtained by resolving AAAA queries, despite the host only having IPv4 connectivity.
The behaviour you're observing is definitely odd. Are you sure that no IPv6 addresses are configured? What is the output of
ip a
andip -6 route
? If you share the output here, you may want to redact any geographically identifying info in it. -
RE: XCP-ng 8.3 beta 🚀
Feedback/comments relating to IPv6 after some usage of beta1 and beta2:
-
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. -
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 viaxsconsole
, there is apparently no change to the configuration. Editing/etc/resolv.conf
works to achieve this (e.g. adding the linenameserver fd00::1
), but this is known not to persist across reboots. -
There is apparently no support for RDNSS (advertisement of DNS servers in RAs rather than via DHCPv6).
-
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.
-
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.
-
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)?
-
-
RE: IPv6 support in XCP-ng for the management interface - feedback wanted
@stormi @BenjiReis I thought I'd document my upgrade process here, as I did a bunch of testing this week on a spare laptop before finally doing it for real last night, and it all went very smoothly in the end. Perhaps all of this can be done by the installer as a user-friendly means of upgrading to add IPv6 support without needing any changes in XAPI:
- Make note of the current partition table, because it will be wiped and the SR partition will not be recreated during the installation process. Mine was as follows:
# lsblk /dev/sda NAME MAJ:MIN RM SIZE sda 8:0 0 21.8T 0 disk ├─sda4 8:4 0 512M 0 part /boot/efi ├─sda2 8:2 0 18G 0 part ├─sda5 8:5 0 4G 0 part /var/log ├─sda3 8:3 0 21.8T 0 part │ └─XSLocalEXT--d62dbe0a--b8b8--143f--6f29--3829124d35d4-d62dbe0a--b8b8--143f--6f29--3829124d35d4 253:0 0 21.8T 0 lvm /run/sr-mount/d62dbe0a-b8b8-143f-6f29-3829124d35d4 ├─sda1 8:1 0 18G 0 part / └─sda6 8:6 0 1G 0
# gdisk -l /dev/sda [...] First usable sector is 34, last usable sector is 46875541470 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 46139392 83888127 18.0 GiB 0700 2 8390656 46139391 18.0 GiB 0700 3 87033856 46875541470 21.8 TiB 8E00 4 83888128 84936703 512.0 MiB EF00 5 2048 8390655 4.0 GiB 0700 6 84936704 87033855 1024.0 MiB 8200
-
Ensure that you have an instance of XO (XenOrchestra) running on a different machine. Use that instance to create a backup of the pool metadata of the machine you'll be adding IPv6 support to.
-
Install XCP-ng 8.3 from scratch on the machine, overwriting the existing installation. Ensure that no disks are selected for use as an SR. This will wipe the partition table and create new partitions for the OS, but leave unpartitioned space where the SR partition would otherwise be. Since versions 8.2 and 8.3 use the same partition layout, you should get the same partition sizes, thereby leaving the SR filesystem intact on the disk, but inaccessible. Since you opted not to create an SR partition, the partition numbers will differ slightly. Immediately after installation, mine was as follows:
# lsblk /dev/sda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 21.8T 0 disk ├─sda2 8:2 0 18G 0 part ├─sda5 8:5 0 4G 0 part /var/log ├─sda3 8:3 0 512M 0 part /boot/efi ├─sda1 8:1 0 18G 0 part / └─sda6 8:6 0 1G 0 part [SWAP]
# gdisk -l /dev/sda [...] First usable sector is 34, last usable sector is 46875541470 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 46139392 83888127 18.0 GiB 0700 2 8390656 46139391 18.0 GiB 0700 3 83888128 84936703 512.0 MiB EF00 5 2048 8390655 4.0 GiB 0700 6 84936704 87033855 1024.0 MiB 8200
-
Reboot into the new installation, and then recreate the SR partition using
gdisk
:- Run
gdisk /dev/sda
(or other device node name as appropriate). - Create a new partition by entering
n
, then use the default values for the start and end sector (these should automatically match those of the SR partition as it appeared in the original partition table prior to reinstallation), and use8e00
for the partition type. - Remove the partition label by entering
c
, then the partition number (should be4
), then enter nothing for the name. - Check the new partition table by entering
p
; the start and end sector values should match those of the original partition table, but the partition numbers may differ. - Write the changes with
w
, or quit without writing changes withq
.
- Run
-
Connect to the new installation using the remote XO instance, then create a new backup of this fresh installation's pool metadata.
-
Alter the first backup's file
data
(which is an XML file) as follows:-
In the section
<table name="PBD">
, replace the occurrence of the device node path for the SR with the correct path as it would be for the new installation. In particular, the disk's SCSI or other ID may have changed, and the SR partition's number in the partition table has probably changed from 3 to 4. In my case, I had to change it from/dev/disk/by-id/scsi-36...fa-part3
to/dev/disk/by-id/scsi-36...a9-part4
. -
In the second backup's file
data
, find the section<table name="PIF">
. Within it, find the<row>
pertaining to the management interface. Copy the values of the following<row>
attributes, overwriting the corresponding attributes in the first backup's filedata
with their values, so that the new installation's values for the IPv4- and IPv6-related configuration parameters are used:DNS
IP
IPv6
gateway
ip_cofiguration_mode
ipv6_configuration_mode
ipv6_gateway
netmask
primary_address_type
-
-
Use XO to restore the now-altered first backup to the new installation. It will automatically reboot, and all storage backends, virtual disk metadata, VMs, and VM metadata should be restored and working, along with IPv6 on the management interface.
-
RE: IPv6 support in XCP-ng for the management interface - feedback wanted
@stormi Thanks, my testing in a VM should reveal how to make sure I do this properly.
-
RE: IPv6 support in XCP-ng for the management interface - feedback wanted
@stormi Thanks for the thorough explanation. I will test whether SR partition on system disk is overwritten by installing and reinstalling XCP-ng on a VM on my laptop.
Loss of VM metadata doesn't concern me as I have relatively few VMs and am happy to just recreate these and attach the retained VDIs to them. The only question that remains is whether those VDIs (and some raw/non-sparse VHDs I have that were created by cloning old disks for data recovery tasks) will show up under the Local Storage repo with a simple click of the refresh button in XO, or whether metadata for those also needs to recreated manually.
Rest assured that I have backups I'd obviously just prefer to avoid needing to restore from them as it's time-consuming.
-
RE: IPv6 support in XCP-ng for the management interface - feedback wanted
@stormi Am I required to install version 8.3-beta1 from scratch, rather than upgrading, in order to get the new IPv6 functionality? I just ran the upgrade from 8.2.1, but am not seeing any change, nor was I prompted to choose which IP versions to enable during the upgrade process.
If I'm required to upgrade from scratch, is there a recommended way to do this without losing my VM data, given that my pool consists of a single host running all VMs using local storage?