Yes, you can use JSON-RPC et REST APIs together for now 🙂

We will try to add support for CPU settings soon.

Also, expect things to accelerate in 2025 regarding the REST API.

Great news 🙂

@dinhngtu Great. Let me know if you need anything else. Hope you find the issue. Never worked reliably here.... Sometimes does.

@DustinB Yes, I completely agree and understand everything you're saying. All of my compute is used elsewhere and I have no spares. In my situation where I lack the budget (and time) for something more robust, USB HDD manual backups will work perfectly well for me (atleast temporarily in these early stages) to preserve my investment of months of work on my datacenter. I appreciate your insights though.

@stormi thanks for the feedback. no rush here. just let me know if I can help.

@ph7 This is being investigated by the XOA team. We will update this thread when more information is available.

@cairoti

I think this may be like my benchmarks, the benchmarks show decent speed to disk, but migration from server to server to local to server are just SLOW.

@pdonias As requested, I added the log filter to the XO config file, restarted the xo-server service, and then ran the LDAP tester from the UI twice. Afterwards, I then ran journalctl -u xo-server, and this is all I see in the logs:

ON XOA:

Dec 16 17:15:59 xoa xo-server[418777]: 2024-12-16T22:15:59.962Z xo:api WARN user | plugin.test(...) [165ms] =!> Error: could not authenticate user Dec 16 17:17:46 xoa xo-server[418777]: 2024-12-16T22:17:46.904Z xo:api WARN user | plugin.test(...) [13ms] =!> Error: could not authenticate user

ON XOCE:

Dec 16 17:22:34 XO1 xo-server[85750]: 2024-12-16T22:22:34.618Z xo:api WARN user | plugin.test(...) [62ms] =!> Error: could not authenticate user Dec 16 17:23:04 XO1 xo-server[85750]: 2024-12-16T22:23:04.792Z xo:api WARN user | plugin.test(...) [11ms] =!> Error: could not authenticate user

I am still able to login, if I reduce the security groups I'm member of to 2 or less. 3 or more, results in failure.

The workaround I have found at this point is to rebuild grub after migrating to XCP-NG. Adds a few minutes to each VM but I don't have that many.

Boot to live iso in UEFI mode (I used Debian12 given it was a Debian12 vm)

sudo su - mount /dev/mapper/????? /mnt mount /dev/xvda2 /mnt/boot mount /dev/xvda1 /mnt/boot/efi for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars chroot /mnt grub-install /dev/xvda update-grub exit shutdown now

I'm using LVM so adjust the first mount to match your root partition.
I shutdown so that I can remove iso and boot when I'm ready.

Hope this saves somebody a bunch of frustration in the future.

If you are that much confident, then feel free to purchase one and use it: XCP-ng supports SRIOV but for NICs, I don't know how different it could be for a GPU, but without any hardware to test it's impossible to answer. How difficult it was to work on a more simpler hypervisor (KVM) doesn't send encouraging messages though.

@Danp Restarted whole server.

Hi Guys,

Just to report back. Got it working. Two ways to do this.

1.) Create 2 schedules for one backup job, forcing one to run as full.
2.) Run backup until the next backup interval is going to do a full. Disable backup, and wait until a time that when enabled will hit the time you want the full to run. In my case after 5pm. I appreciate this way is not practical, but does work.

12291419-456e-4cd7-8a67-5cc6430a9c4f-image.png

Appreciate you help guys !!

@dinhngtu It happened again to me.... Windows 10 22H2 on XCP 8.2.1...

Same issue as others. Windows reports a USB driver issue. Disabling/re-enabling the windows driver makes it work again.

To answer your question, Yes, reverting to a snapshot with memory keeps the problem of a failed USB/mouse.

It has been added to the backlog, thanks!

@MathieuRA ok, thanks

@DustinB Drives from a secondary NAS

@flakpyro said in How to migrate XOA itself?:

@DustinB Are the any downsides to having two XOA instances pointing at the same pool? Since the config itself is stored at the pool level im guessing theres no downside?

IE: Priimary XOA running in core DC and secondary XOA running at your DR site. Is it just a matter of adding the pool on the secondary XOA and it downloads the existing config or did you need to do a full export / import?

If you import your configuration, each XO instance will think they should be running the backups as far as I've noticed. If I have two instances running with the same configuration, I simply disable the backup jobs on one of them.

The config file is just an XML that contains your existing instance. You can import it to any new XO instance and have the same exact configuration.

Great news, nice catch 🙂

@thomas-dkmt said in "Block migraton" option on the VM´s Advanced tab:

@olivierlambert @DustinB Thanks! It's always helpful to have a native speaker's perspective.

Happy to help, worth noting that if a setting like this is enabled on a given VM, there should also be some sort of visual indication on the home screen of XO to annotate that these VMs won't move unless this is disabled.