Solved the problem by explicitly specifying the data type

$resize = 'VDI.resize'; $xcpapi->$resize($vdi, ''.(int)$hdd2.'');

Doesn't work without brackets

''.(int)$hdd2.''

@andrew Yes indeed, those are known shortcomings:

The installer does not wipe previous RAID setups. It does not offer to create another RAID for data storage. There's an extensive guide about this at https://xcp-ng.org/docs/guides.html#software-raid-storage-repository

Your starting point will be https://xcp-ng.org/docs/develprocess.html#local-rpm-build

@stormi

I sent a PULL request to the fork source.
https://github.com/xapi-project/sm/pull/576

a573net created this issue in xapi-project/sm open QNAP product attribute is incorrect #576

It's related to the expiry of a root certificate and sub-optimal behaviour of the version of openssl we have in XCP-ng.

You can fix it by updating the ca-certificates RPM (it's been validated internally already and will be released to everyone with our next updates).

yum update ca-certificates --enablerepo=xcp-ng-testing

Yes, I told them we'd like to cooperate to release something faster.

Sure go ahead you should be able to do it in terms of permissions. If not, let me know 🙂

Sorry for grave digging here, but since this answer ranks pretty high in the Google results, I thought I might add a possible solution:

During the export wizard in XCP-ng Center, you're being asked for the network configuration of the Transfer VM. As for my observations, two things are pretty vital here:

The network you choose to place the Transfer VM's virtual interface in must be reachable from your computer/XCP-ng center. Enter a static IP configuration, DHCP has never worked for me, even though a DHCP server is running in the selected network.

Hope this helps some!

@noship Which issue are you talking about exactly?

You might ask Xen project upstream directly (on appropriate mailing list), see https://xenproject.org/help/mailing-list/

However, if there's nobody interesting to do this, it means no money. If your company is interesting in it, we can try to see the amount of work needed (IMHO: not trivial at all) and get a rough price estimate.

Actually, on any recent enough Linux system (ie not many years old) , the PV drivers are directly included in the kernel. Unless, maybe, a very specific distro decides that they don't want Xen support in their kernel.

So the tools you install on the VMs are merely an agent to make the VM more cooperative with the hypervisor, but they don't affect performance.

The situation is different on Windows systems where you need to install PV drivers to achieve better performance.

The drivers install fine on Windows 2022 21H2 (Build 20348.169).
Like previous versions, the system hangs as soon as the VIF state changes.

Updated xcp-ng-pv-tools on my one XCP 8.2 server. (We have mostly (citrix)7.1 and (xcp)7.6 because of hardware RAID limitations)
Found the ISO located at /opt/xensource/packages/iso. (verison 8.2.0-9)
Moved this to my local workstation, and then to my ISO-repo file server.
Went to my XCP 7.6 server, and then to the Rocky Linux 8.4 VM i just set up.
Removed the EPEL xe-guest-utilities-latest package. (7.21.0-1)
Mounted the XCP ISO from the ISO-repo and installed the guest tools from that. (7.20.0-9)

Agent detected! and the service seems to run without error.

Using this command to install from the old guest tools ISO worked fine

./install.sh -d rhel -m 8

the file version is xe-guest-utilities-latest-7.16.0-2.el8.x86_64, the distro logo is not showing though.

That's correct: NASA asked for a solution and Rackspace worked with them to create it 🙂 See https://www.rackspace.com/library/what-is-openstack

For the exertion start, I have run over sensible RDP stuff from the FreeRDP project just as OGON.

bestrdp (https://www.freerdp.com/)

The FreeRDP project has a worked on shadow worker that may be utilized as the reason for a RDP worker and the OGON project as a comparable, however further developed, type worker that likewise considers plugable modules in that it very well may be utilized for RDP and even SPICE later on, on the off chance that I recollect effectively while I feel that they have VNC previously coded up.

My musings are to discover where XCP-ng at present handles the entirety of the VNC stuff for the hypervisor which I imagine that @olivierlambert just sent the connection in order to check whether it very well may be feasible to work out likely the OGON worker from that point to permit supporting the VNC, RDP, and SPICE numerous conventions.

I will take some time, yet on the off chance that all works out in a good way, the client ought to have the option to associate with any of the VM consoles (Linux, Windows, and so on) with any of these conventions and not need to do it from inside the Guest VM.

At any rate that is objective

I see movement in the github repo again. Good sign!

Hi,

No, at least not yet, due to the lack of demand for that.

I'm happy to hear you are working on VirtIO since both FreeBSD and Linux guests supports it well these days.

Obviously this is a big commitment, but I thought I'd post about it anyway in the hopes that it could one day become possible 🙂

One more thing that would be needed for virtio is spice support. This would actually be pretty cool as it allows piping USB, Audio and VGA to users connecting to the VM's console 🙂