XCP-ng 8.2 with the latest XOCE

I have two pools on a TrueNAS machine, one is an NVME only pool while the other is all SSDs. I was migrating a stock Ubuntu vm from the nvme-pool to the ssd-pool so I could start running some tests.

I started the migration and everything looked normal but the process seems to have hung and I am not sure how to troubleshoot it.

The vm is a 60GB thin vm created in XO and was working fine on the nvme-pool.

Great to hear, looking forward to the updates.

@olivierlambert
Awesome, thanks for helping to troubleshoot. I'll go a head and disable that then do the update.

I've been having to switch between XO and XCP-ng Center to get certain features to work.

• The HA configuration in Center is super easy with good feedback on the heartbeat, will this type of info be incorporated into XO?
• The in trying to troubleshoot this I was looking at the VM memory options and the XO vs XCP-ng Center set fixed memory vs automatic is much easier in Memory.
• XO detects that all of my VMs properly have the management agent installed (with ip, os, and agent version being reported), XCP-ng Center only reports 1/4 of the VMs having the management agent installed.

@olivierlambert
https://paste.vates.fr/?f2f854418b6493c8#B1Wrjkb9wVQTY1BKvTvcz1r4WZmXHnTB2n52UjLx4Rof

I used: cat /var/log/xensource.log | grep -i ee6254af-44af-4bcf-8382-d9b7542d2b3c

The logs I sent are from host 1, not sure if I need to run that command on all of the hosts.

There are more debug messages but these seem like the most relevant.

Apr  3 20:02:18 localhost xapi: [debug||1864 ||vgpuops] vGPUs allocated to VM (OpaqueRef:ee6254af-44af-4bcf-8382-d9b7542d2b3c) are:
Apr  3 20:02:56 localhost xapi: [ warn||1864 ||rbac_audit] cannot marshall arguments for the action VM.migrate_send: name and value list lengths don't match. str_names=[session_id,vm,dest,live,vdi_map,vif_map,options,vgpu_map,], xml_values=[S(OpaqueRef:4489cc5b-fbe9-44d4-a60f-627b8960338f),S(OpaqueRef:ee6254af-44af-4bcf-8382-d9b7542d2b3c),{SM:S(http://10.100.10.31/services/SM?session_id=OpaqueRef:cd0a7342-5155-434d-a8ca-2e9f7dcf8460);host:S(OpaqueRef:ac2e50bc-1f80-417a-8eea-a7ce955d4c24);xenops:S(http://10.100.10.31/services/xenops?session_id=OpaqueRef:cd0a7342-5155-434d-a8ca-2e9f7dcf8460);session_id:S(OpaqueRef:cd0a7342-5155-434d-a8ca-2e9f7dcf8460);master:S(http://10.100.10.31/)},B(true),{OpaqueRef:a4398d4e-946c-4c83-ad5f-b4dc1c3ddeee:S(OpaqueRef:4c00dfd9-a30c-47a4-8367-e8a7d7c53cb6);OpaqueRef:188682c3-1b45-4ae4-98cf-0dfff1d90d56:S(OpaqueRef:4c00dfd9-a30c-47a4-8367-e8a7d7c53cb6)},{},{force:S(false)},]

I would echo these requests, Kali/Parrot/Docker with Portainer ready (Debian preferred but Ubuntu would also work).

Thanks!

@cyb3rw0lf said in XO Hub Template: what do you want next?:

Distributions:
Kali Linux
Parrot OS

Applications:
Gitlab
Netbox
ELK
Docker-ready machine with portainer
Unifi AC

@olivierlambert

1. Is there a way to look up OpaqueRef and does it point to a specific service/host/vm/etc?
2. I checked all running vms including XO and XCP-ng, 33GB assigned / being used. Each host has 64GB of RAM. I do have cores over-provisioned if all the VMs are forced onto one host but I can fix that. With a rolling update dividing VMs among the 2/3 hosts at a given time, there shouldn't be an over-provision of cores.

With the new updates that just came in, I wanted to use the new rolling update feature.

When I do it, I get the following error.

CANNOT_EVACUATE_HOST(HOST_NOT_ENOUGH_FREE_MEMORY,OpaqueRef:ee6254af-44af-4bcf-8382-d9b7542d2b3c)

I'm not sure what that UUID is and can't find it, it's not one of my hosts. Each of my host has enough ram to run all of the VMs that I have. All of the VMs are running on an NFS SR.

I'm happy to pull any other logs to help.

@carlosfrederico said in Bizarre Error during backup process (from the sources, 20.04):

@olivierlambert said in Bizarre Error during backup process (from the sources, 20.04):

https://github.com/vatesfr/xen-orchestra/issues/5588

Thanks @olivierlambert and @julien-f !

I use the script https://github.com/Jarli01/xenorchestra_updater , so executing sudo curl https://raw.githubusercontent.com/Jarli01/xenorchestra_updater/master/xo-update.sh | bash -s -- -b 350b0c1 solved the problem.

Thanks!

Thank you all too. I ran into this issue last night, found this, changed to the alternative branch and boom it's working now.

When a merge makes it's way into XO source, is there a way to highlight this issue so I can move back to mainline?

Thanks again!

@tuxen thanks for the info, I give that a try. I only ended up running the xe vm-cd-remove because my XO vm was failing to start due to having the guest-tools iso being mounted. I couldn't install the tools and I couldn't remove the tools mount from XO so I ended up tinkering with the xe command to see if I could get it.

I think this might be an issue with trying to install guest-tools on an XO vm that is running on the xcp-ng. I just tested it on 2 new builds and have the same issue. As soon as I shutdown the XO vm, then go into the xcp-ng host and using xe to start the XO vm things seems to be fine.

I thought I would be able to hotplug the guest-tools iso into the XO vm, install guest-tools, unmount, reboot the XO vm and all would be good.