Also please note that's not a guarantee to boot the VM on this host. In fact, there's no way to be 100% sure it will. It's just than now XCP-ng will do its best to honor this. But eg, if there's not enough RAM on the host, then it will boot on another host of the pool.

I think, solution you are looking for is direct disk access. It's possible. I use it for my file server VM (FreeNAS) with five 4TB wd red drives (zfs). Passthrough entire PCI storage card is better, but even cheap server motherboards have 6 sata channels (one for dom0 ssd, and five for file server storage). 😉
This is my example (and my UUIDs)

mkdir /srv/direct-sata_sr
xe sr-create name-label=”Direct SATA SR” name-description=”SATA links to passthrough direct to VMs” type=udev content-type=disk device-config:location=/srv/direct-sata_sr

New UUID generated on sr creation
ba9b124c-c5ac-2c0b-7b1f-014d9cezzzzz

ln -s /dev/disk/by-id/<disk id> /srv/direct-sata_sr/<disk id>

ln -s /dev/disk/by-id/ata-WDC_WD5000BEVT-26A0RT0_WD-WXE1A10V7603 /srv/direct-sata_sr/ata-WDC_WD5000BEVT-26A0RT0_WD-WXE1A10V7603

xe sr-scan uuid=ba9b124c-c5ac-2c0b-7b1f-014d9cezzzzz
xe vdi-list sr-uuid=ba9b124c-c5ac-2c0b-7b1f-014d9cezzzzz

Good luck.

@olivierlambert I have assigned 1.9TiB to a VM and XOA is saying the VM is using 1.07TiB, but df -h on the VM is saying that I'm using 418GB.
So according to XOA I should have about 800GiB left but according to my VM I should have 1.4TB left, there's a pretty big 600GB difference here.

I actually like the current implementation. I am currently using this setup to allow an admin user to have 2 accounts managed by one authentication back-end.

One account is a typical self-service user to consume resources according to ACL/Self-service rule sets
The other account is used to manage Admin features like backups and XO settings (environment with multiple admins who also consume resources from a shared pool with other departments/teams)

I use separate accounts so when admin users create VMs it can go to the appropriate self-service container. I hope any fixes to address the above concern doesn't completely remote this capability or at least adds another method of achieving this. 🙂

easy as that 🙂

Thanks for you help.

guys, it is solved, but thats something i will file again under technological harrassment.

it was a DNS Problem. the dns-servers at my hosting provider woudnt resolve properly, only when I forced googles DNS servers onto it did it work.

thanks for the push 👍

Indeed, it's using our cloudinit ready templates hosted on xen-orchestra.com, so you need a XOA.

VSS agent will disappear, so yes, quiesce snapshots will disappear too. But fear not, we have plans to introduce a new feature, called "RAM backups".

Hi

I had exatly the same problem when I upgrade one of my four server from xenserver 7.1 to xcp-ng 8.0, one backup failed with error: job already running and the other finish normaly later!

I upgrade Xo from 5.51 to 5.54 and it's Ok for this problem BUT I have a new problem, the cold backup to NFS and the Continuous replication to a Xcp-ng 8 server are REALLY slow !! One exemple:

Start time: Thursday, December 19th 2019, 7:20:00 am

End time: Thursday, December 19th 2019, 7:58:54 am

Duration: 39 minutes

Snapshot ✔

SRs

I try to upgrade debian OS, upgrade VM (4cpus 3Go ram) but same problem for the moment

Thanks in advance

Edit: I do a manual test by copy an iso of 2G locally on the virtual machine Xen orchestra, to the same connected NFS for backup, and the performance is normal, 10 seconds for 2Go, it seems to be a problem with Xen orchestra system backup?

It's supported in XOA since 5.40 and all more recent releases. Just tick the checkbox and that's it 🙂

@ruskofd said in Build from source question:

Why not using a systemd unit instead of forever ?

This is exactly what I did. Created a service file in etc/systemd/system that points back to the xo-server bin file.

I'm not sure, I have not used cloud-init in centos. I'd imagine it's similar, you need to find the cloud-init config file in your centos template install, and edit it to prefer the nocloud datasource

Ping @pdonias

Restoring the whole VM is OK, because XO doesn't "look" inside the disk.

I'm pretty fine that anyone build a WHMCS connector to XO API 🙂

Thank you. Yes, I have installed the xscontainer though it does nothing.

Next thing I tried was Exporting the affected VM, delete it and import it again. This fails because after deleting the VM both VDIs / VHDs are still there. Also I can not delete them. The error says:

f6ff6ad4-8a59-4424-9bb5-ff498f87989f-image.png