XCP-ng 8.3 betas and RCs feedback 🚀

ThierryC01

@olivierlambert That is not true, a remote folder is still a remote folder and we should be able to backup any VM wherever we need/want. The issue here is when the login fails once, there is no way to edit the logon password and succeed. It was working very well until I upgraded from 8.2 to 8.3 and then had to restore a VM from backup. No grudge here, just a fact.

What I call a mumble jumble naming of folder is just that every VM is identified by a uuid in the same folder if all backups are stored in the same place which makes it difficult to sort should we need to either use a backup on another platform or delete to regain disk space.

I am just fighting to get a basic feature working: edit the password of a connection without having to delete the record and start over.

ThierryC01

@florent That is the theory yes, but in reality, editing the password fails.

ThierryC01

Okay... I have to apologize for the pollution of this topic, I was running a container version of XOA (Xen Orchestra, commit 422a2) which I use in emergency cases such as my actual up to date XOA VM which crashed due to an LVM issue and was trying to restore. I managed to get my actual XOA VM running and everything is fine, no problem whatsoever, all backups are here using the XOA VM, available to restore and all. I really feel bad for wasting everyone's time. I will update my emergency XOA container from now on, I thought that all information were stored on the Xcp-ng server, good to know.

laurentm

@ThierryC01

About your LVM crash, was it with NVMe U2 SSD ?
Running XenServer from more than ten years and XCP-NG from 7.5, the worst issue I encounted has been recently with a very brand new DELL R650 fitted with some excellent Kingston U2 NVMe DC1500M,
connected straight to the motherboard, without any hardware raid controller. It appears that NVMe can disappear randomly due to some stupid power save feature in Linux kernel. I have patched that and I'm using each ssd separetely, in order to reduce the risk, and without LVM at XCP-NG level, only in my Linux VMs.

olivierlambert

You mean APST?

https://docs.xcp-ng.org/troubleshooting/storage/disappearing-NVMe-drives/

ThierryC01

@laurentm No, for some stupid reason, the LVM volume was 100% full and I could not write any disk configuration nor expand the volume until I got rid of some logs.gz. All this happened during an update of XOA, I think there should be some safeguard in Linux to avoid such situation.

I will install a new XOA VM somewhere else as a backup since the container does not update to the latest commit. I hope they could sync the backup configuration.

florent

@ThierryC01 said in XCP-ng 8.3 beta :

@florent That is the theory yes, but in reality, editing the password fails.

Does it work with a newly created remote ? i.e. you create a new samba, it connects, you edit the password, it still works ?

bufanda

@ThierryC01 What Container Image do you use. I personally use this container

https://github.com/Ezka77/xen-orchestra-ce

It builds weekly and follows the master of xen-orchestra. So latest version is always most updated one.

stormi

@bufanda Let's try to stay on the topic of XCP-ng 8.3 beta

bufanda

@stormi Yeah sure, just thought it may help with the issue that was reported if the container used is outdated.

But anyways to the topic of XPC-NG 8.3beta. Are there any updates planned in the near future it has been a while since I recieved Updates on my test cluster. And while I don't run an AMD Processor on my test cluster there were security fixes for 8.2 but they didn't made to my 8.3 or did the repo config change and I missed that?

stormi

@bufanda So, yes, we have a big update in the pipe, but we still have bits to tweak before we can push it to all testers.

Regarding security updates, we don't offer any guarantee regarding the update delay on the beta, until the final release.

bufanda

@stormi Thx for the info. And I understand that there is no guarantee, was just curious if I had a problem on my cluster or if there was really nothing inbetween. It's a test cluster in the end so no mission critical things running on it anyways.

ThierryC01

@florent on the 8.3 beta1 with the latest XOA available I have tested the creation of a new NFS remote with success.

I tried to create a new SMB connection with a wrong password to test the edit and it worked perfectly, the only thing is that the alert that showed up during the wrong password connection does not disappear once the connection is established with a correct password even after multiple page refresh, disable, enable, refresh.

Xcp-ng 8.3 remote.png

archw

As part of the learning process, I've now upgraded three machines from 8.3 to 8.3 beta 1. In each case, it did not upgrade the host. Instead it overwrote what was there and I had to reinstall the VM's from backup. Not the end of the world, just thought y'all might want to know.

archw

I'm trying to migrate an esxi VM to XCP-ng.

The VM is turned off.
"Thin mode" is off
"Stop the source VM" is off
"Stop on error" is on.

I have tried doing this:
A. through vcenter
B. drive to the esxi host
C. using the IP address in lieu of the dns name.

In each case, as soon as I click "Import" I get the message below.

vm.importMultipleFromEsxi
{
  "concurrency": 2,
  "host": "vcenter.internal.local",
  "network": "ca618529-000b-0c6e-52ba-f6c985134163",
  "password": "* obfuscated *",
  "sr": "b3b03de1-f7d1-92ca-68a4-40370e7649d3",
  "sslVerify": false,
  "stopOnError": true,
  "stopSource": false,
  "thin": false,
  "user": "adminname@vspehere.locall",
  "vms": [
    "vm-2215"
  ]
}
{
  "succeeded": {},
  "message": "Cannot read properties of undefined (reading 'startsWith')",
  "name": "TypeError",
  "stack": "TypeError: Cannot read properties of undefined (reading 'startsWith')
    at Esxi.#inspectVmdk (file:///opt/xo/xo-builds/xen-orchestra-202312090402/@xen-orchestra/vmware-explorer/esxi.mjs:209:18)
    at Esxi.getTransferableVmMetadata (file:///opt/xo/xo-builds/xen-orchestra-202312090402/@xen-orchestra/vmware-explorer/esxi.mjs:293:40)
    at Task.runInside (/opt/xo/xo-builds/xen-orchestra-202312090402/@vates/task/index.js:158:22)
    at Task.run (/opt/xo/xo-builds/xen-orchestra-202312090402/@vates/task/index.js:141:20)
    at MigrateVm.migrationfromEsxi (file:///opt/xo/xo-builds/xen-orchestra-202312090402/packages/xo-server/src/xo-mixins/migrate-vm.mjs:177:28)
    at file:///opt/xo/xo-builds/xen-orchestra-202312090402/packages/xo-server/src/api/vm.mjs:1415:30
    at Task.runInside (/opt/xo/xo-builds/xen-orchestra-202312090402/@vates/task/index.js:158:22)
    at Task.run (/opt/xo/xo-builds/xen-orchestra-202312090402/@vates/task/index.js:141:20)
    at asyncEach.concurrency.concurrency (file:///opt/xo/xo-builds/xen-orchestra-202312090402/packages/xo-server/src/api/vm.mjs:1413:11)"
}

stormi

@archw As far as I can tell, this is related to Xen Orchestra (which handles the import from VMware), rather than to XCP-ng 8.3. Maybe you can open a dedicated thread for your issue?

Danp

@archw said in XCP-ng 8.3 beta :

As part of the learning process, I've now upgraded three machines from 8.3 to 8.3 beta 1. In each case, it did not upgrade the host. Instead it overwrote what was there and I had to reinstall the VM's from backup.

I assume that's a typo and you were upgrading from 8.2 to 8.3 beta. Your feedback would be more beneficial if you shared some additional details, such as --

Were these hosts in separate pools or a shared pool?
Explain the process you followed to perform each upgrade
etc

archw

@Danp

oops...yes...that's a typo and I was upgrading from 8.2 to 8.3 beta.

"Were these hosts in separate pools or a shared pool?"
They were on separate pools (I'm I understand you correctly). Its just one XCP-NG machine.

"Explain the process you followed to perform each upgrade"

I booted from the 8.3 DVD then just followed the instructions on the install screens accepting the defaults as I went along.

archw

@stormi

OK! I wasn't sure if it was ok to post that over there since this is on a beta machine.

Thanks!

john.c

When performing a reboot during the installation of XCP-ng 8.3 beta its currently not ejecting the installation media at the appropriate point.

This needs to occur so that the system will not attempt to do another boot from the installation media. This is especially important when the installation has completed, so that it can be ensured that the system will not boot from it again.