XCP-ng 8.2.0 RC now available!
-
Yes, you can using the installation ISO.
-
Reconnection via iSCSI is failing. Upgrade pool from 8.0 to 8.2 (Starting with the Master host).
Nov 2 10:36:59 CLI219 SM: [10134] Warning: vdi_[de]activate present for dummy Nov 2 10:37:00 CLI219 SM: [10200] Setting LVM_DEVICE to /dev/disk/by-scsid/36005076d0281000108000000000000d7 Nov 2 10:37:00 CLI219 SM: [10200] Setting LVM_DEVICE to /dev/disk/by-scsid/36005076d0281000108000000000000d7 Nov 2 10:37:00 CLI219 SM: [10200] Raising exception [97, Unable to retrieve the host configuration ISCSI IQN parameter] Nov 2 10:37:00 CLI219 SM: [10200] ***** LVHD over iSCSI: EXCEPTION <class 'SR.SROSError'>, Unable to retrieve the host configuration ISCSI IQN parameter Nov 2 10:37:00 CLI219 SM: [10200] File "/opt/xensource/sm/SRCommand.py", line 376, in run Nov 2 10:37:00 CLI219 SM: [10200] sr = driver(cmd, cmd.sr_uuid) Nov 2 10:37:00 CLI219 SM: [10200] File "/opt/xensource/sm/SR.py", line 147, in __init__ Nov 2 10:37:00 CLI219 SM: [10200] self.load(sr_uuid) Nov 2 10:37:00 CLI219 SM: [10200] File "/opt/xensource/sm/LVMoISCSISR", line 86, in load Nov 2 10:37:00 CLI219 SM: [10200] iscsi = BaseISCSI.BaseISCSISR(self.original_srcmd, sr_uuid) Nov 2 10:37:00 CLI219 SM: [10200] File "/opt/xensource/sm/SR.py", line 147, in __init__ Nov 2 10:37:00 CLI219 SM: [10200] self.load(sr_uuid) Nov 2 10:37:00 CLI219 SM: [10200] File "/opt/xensource/sm/BaseISCSI.py", line 150, in load Nov 2 10:37:00 CLI219 SM: [10200] raise xs_errors.XenError('ConfigISCSIIQNMissing') Nov 2 10:37:00 CLI219 SM: [10200]
-
Upgrade via
yum
or via ISO? -
@olivierlambert ISO. Our Storage is IBM v7000.
-
xe host-list uuid=<host uuid> params=other-config
Let's see if a host lost its IQN.
-
Still testing here since beta, runs very smooth on my single host system
- Window 10 UEFI is still fine
- NAS Remote Backup works awesome
- Backup Notifications via Mail and Slack works as expected
- Xen Orchestra works awesome
-
@olivierlambert said in XCP-ng 8.2.0 RC now available!:
xe host-list uuid=<host uuid> params=other-config
[13:01 CLI220 ~]# xe host-list uuid=e1d9e417-961b-43f4-8750-39300e197692 params=other-config other-config (MRW) : agent_start_time: 1604332891.; boot_time: 1604323953.; iscsi_iqn: iqn.2020-11.com.svm:cli219; rpm_patch_installation_time: 1604320091.898; last_blob_sync_time: 1570986114.22; multipathing: true; MAINTENANCE_MODE_EVACUATED_VMS_SUSPENDED: ; MAINTENANCE_MODE_EVACUATED_VMS_HALTED: ; MAINTENANCE_MODE_EVACUATED_VMS_MIGRATED: ; multipathhandle: dmp
[13:02 CLI219 ~]# cat /etc/iscsi/initiatorname.iscsi InitiatorName=iqn.2020-11.com.svm:cli219 InitiatorAlias=CLI219
-
@_danielgurgel said in XCP-ng 8.2.0 RC now available!:
@olivierlambert said in XCP-ng 8.2.0 RC now available!:
xe host-list uuid=<host uuid> params=other-config
[13:01 CLI220 ~]# xe host-list uuid=e1d9e417-961b-43f4-8750-39300e197692 params=other-config other-config (MRW) : agent_start_time: 1604332891.; boot_time: 1604323953.; iscsi_iqn: iqn.2020-11.com.svm:cli219; rpm_patch_installation_time: 1604320091.898; last_blob_sync_time: 1570986114.22; multipathing: true; MAINTENANCE_MODE_EVACUATED_VMS_SUSPENDED: ; MAINTENANCE_MODE_EVACUATED_VMS_HALTED: ; MAINTENANCE_MODE_EVACUATED_VMS_MIGRATED: ; multipathhandle: dmp
[13:02 CLI219 ~]# cat /etc/iscsi/initiatorname.iscsi InitiatorName=iqn.2020-11.com.svm:cli219 InitiatorAlias=CLI219
So the IQN was correctly "saved" during the upgrade, it sounds correct to me. Is that host in a pool? Can you check for the other hosts?
-
@olivierlambert said in XCP-ng 8.2.0 RC now available!:
So the IQN was correctly "saved" during the upgrade, it sounds correct to me. Is that host in a pool? Can you check for the other hosts?
All others are correct and with other guests running.
I'll do some testing by removing the iSCSI connections altogether and replugging the host that has been updated.If you have any tips on how to solve it, i appreciate your help.
-
Frankly, I never saw that error before.
It's in there:
https://github.com/xapi-project/sm/blob/master/drivers/BaseISCSI.py#L143-L155
You have the field in XAPI, so I don't get why it fails with an error.
-
@Rocky said in XCP-ng 8.2.0 RC now available!:
- on first boot of the install ISO I got a nominal error of
Installer mode (UEFI) is mismatched with target boot mode (legacy)
I would expect this if you're booting the USB stick in UEFI mode but have your existing system configured to boot in legacy mode (though I don't know exactly how that is detected).
Maybe @beshleman would know.
Update: I think that's a message from the installer itself, actually. It detected that the existing XenServer system was installed in BIOS mode, not UEFI, so it refuses to go on.
-
Upgraded a three host homelab:
- ISO upgrade from XCP-ng 8.1 fully patched to XCP-ng 8.2.0 RC
- ISO upgrade from XCP-ng 8.2.0 beta fully patched to XCP-ng 8.2.0 RC
- ISO fresh install of XCP-ng 8.2.0 RC
My quick-and-dirty setup of Let's Encrypt on one of the hosts survived the ISO upgrade - nice
Did a
yum update
on all hosts and tested:- Add/remove hosts to XO from source
- Join/remove hosts to a pool.
- Copy/Move of VMs (within and across pools)
- Move VDI between local/shared SR
- Create/Change VMs (Linux, Windows (but not UEFI))
- Add, Remove, Re-add NFS shares (ISO and storage)
-
@stormi yea, I wasn't concerned about it was just documenting how it's normal I guess. Actually it's a helpful error even because then I knew to boot the USB the legacy (non-uefi) way.
-
Shared nothing windows 10 Live migrations working well in my 2 hosts 8.2RC pool. both uefi VM and BIOS vm.
-
So one error I got was on a XO backup job from a VM I moved from an 8.1 pool to a my test 8.2RC pool.
Error: INTERNAL_ERROR((Failure "Expected string, got '{}'"))
Update: I get this error on a new backup job also. This is on XO from the sources, I'll test with XOA also.
Update: this is working from XOA, not sure why I got the error in XO (from sources)... and I got 86.73 MiB/s. Which I think is faster than 8.1.
Update: this is now working for XO (from the sources) after I updated to 5.70.0 / 5.74.0 thanks for the great products.
-
Thanks for the feedback! It's very helpful
-
@stormi The installer just checks for the existence of "/sys/firmware/efi/", which is created when the kernel EFI driver reads that EFI is enabled from the boot_params passed to it from GRUB2. This is how it detects the "Installer mode"
The "target boot mode" is UEFI if an EFI (ESP) partition is discovered on the target disk, otherwise it's determined to be legacy.
A mismatch between the two will cause this error. This system is a UEFI system, but doesn't appear to have a ESP on the target disk.
-
Important update about XCP-ng 8.2
There were several updates pushed to the repositories for XCP-ng 8.2 RC. More than planned, because we chose to sync with the latest Citrix Hypervisor 8.2 hotfixes before the final release.
So please update (
yum update
, see https://xcp-ng.org/docs/updates.html if needed), reboot the hosts, and give us your feedback.You're not supposed to notice anything changed. These changes are under the hood.
This is the last sprint. If all goes well, XCP-ng 8.2 final will be released real soon.
-
@stormi did
yum update
on my three host homelab. So far everything is running as usual, but I did no real test others then starting/stopping/restoring some VMs and moving them around. -
This post is deleted!