@mietek Hello, this is due to incompatibility between xo-cli and xo-server due a change introduced 6 months ago, you can resolve it by updating xo-server.

Another solution is to update xo-cli as the recent versions contains awork-around for old versions of xo-server.

@rauly94 @AtaxyaNetwork

@olivierlambert @pdonias is there any option to also add openSUSE MicroOS? It is also missing an icon...
Details are here:

xe vm-param-list uuid=c5b75080-0689-6e5b-820f-e66b77149aff | grep distro os-version (MRO): name: openSUSE MicroOS; uname: 6.2.6-1-default; distro: opensuse-microos; major: 20230319; minor: unknown

I used ./install.sh -d sles -m 15 to install tools...

Thank you!
regards
D

So we still don't have a list of which "modern" GPUs support vGPU?

Use case: jellyfin/plex transcoding, Simple Windows VM workstation, etc.

@olivierlambert

I'm happy to help test if that kind of help is needed.

Mike

@gskger Thank you. I tough it would be but wanted to be sure 🙂

@olivierlambert its custom config, not any bug. Ill point it out what i mean below.

I have standard ubuntu template -> I would like my vm to be already customize, when its created, because its faster and easier when everything is in one place -> So for that i have created cloud-init for eg.-> #cloud-config hostname: <hostname> package_update: true package_upgrade: true write_files: - path: /etc/ssl/certs/mydomain.crt content: | <certificate data> - path: /etc/ssl/private/mydomain.key content: | <private key data> runcmd: - apt-get update - DEBIAN_FRONTEND=noninteractive apt-get upgrade -y So my main problem is that this, particular cloud-init has fixed <certificate data> and <private key data>, that i would like to not be passed as a plain text, because it is a secret. To me its not done (for now) with best practices, but its very comfortable.

So finally, i am wondering what is the best solution, for not putting secrets as a plain text, but rather keep them as a secret. I could create templates and later delete cloud-config with those data, but it would be more flexible, if there would be any chance to connect it to Hashicorp Vault or something that will dynamically fetch secrets.

@julien-f I just wanted to update and let you know that whatever changes you made fixed the issue for me permanently! I have been able to routinely update since that time and have had no further issues.

Thanks for all of your hard work, Julien-f!

@olivierlambert Thank you. Hopefully someone can chip in

Hi,

A faulty SATA controller? Bad RAM? Use a Memtest to check that 🙂

\o/

Next release will have multi-VM import 🙂

So, we've had reports on xen-devel which look a little like this.

@BlueBadger are you able to switch back to your 7950x and try booting Xen with x2apic_phys=true ? It appears that the -X processors are missing a feature in their IOMMU and Xen was getting confused when setting up interrupt handling.

https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=0d2686f6b66b4b1b3c72c3525083b0ce02830054 is at least part of the fix, but so far feedback on the mailing lists suggests it's not a complete fix.

I think we fixed this bug in latest 🤔

@Pierre-Briec , @stormi

I had a look at getting the xe-guest-utilities working on Ipfire v2 now (core 173, the latest version).

Using a new /usr/sbin/xe-linux-distribution script, like suggested here, allows it to detect the ipfire.
I then manually copied the binaries and scripts from the linux tar file, into the folders in Ipfire, since the install script did not seem to handle Ipfire properly.

When starting the daemon using /etc/init.d/xe-linux-distribution, the next problem was that the "action" function does not exist in the /etc/init.d/functions file in Ipfire.
So I just edited the script, replacing the "else" with an "fi" in the if testing where the functions file is sources, so that the locally defined action method is used.
Then the agent started fine.

Then I also saw the issue of the IP address not being reported.
In my setup, there are two reasons for this. One is that Ipfire uses "red0", "green0", "blue0" etc as interface names, which the xe-guest-utilities will not consider.
The other reason is that I do PCI passthrough of 3 network cards to the Ipfire, and hence does not use the "vif" interface/network that XCP-ng makes available to the Ipfire. Althought the "green0" is really on the same network as the "vif" in my setup.

This was using the 7.30 tar file from the XCP ISO, I think.
I then cloned the 7.33 / master version of xe-guest-utilities from github, and used that thereafter.

I manually changed and built the xe-guest-utilities, adding "red", "green", "blue" to the list of interface prefixes that got considered, but it did not help.
I suspect the reason is that these interfaces does not have a /sys/class/net/eth0/device/nodename entry, which contains a reference to the "vif" that XCP-ng knows about, as I understand it.
So
/sys/class/net/eth0/device/nodename exists, but the eth0 is not assigned any IP address, since it is not used by IPfire.
While there is no /sys/class/net/green0/device/nodename entry.

I am not sure who is "creating" this "nodename" entry, but I suspect is it Xen.
And I suspect it is missing, since the green0 interface has no relationsship with the dom0 really.

But then I also got more questions around what is actually meant to be displayed of "network" info in the XOA web UI. Is it only the network between dom0 and domU ? Or ideally all networks defined on domU ? (i.e. red0 and blue0 and orange0 ) ?

And I also think I spotted a bug on the "Stats" page of XOA, since under "Disk throughput", it seems like always "xvda" and "xvdd" is displayed, even if the host only has one disk, "xvda". But that I should report as a bug, if I do not find it as already reported / known.

While playing with this, I also noticed that the management agent version was not properly displayed, i.e. not at all. And this seems to be caused by the the version constants not being replaced while building the daemon.
I am not a go build expert, so I'll investigate it a bit more. But it seems like I'm not the only one with that issue, because the same problem seems to exist with the xe-guest-utilities that are part of Alpine Linux 3.17 distribution.

I do not think that there are that many running Ipfire on XCP-ng/Xen. I've been briefly involved in some pull requests against Ipfire, so I might look at making one for getting the xe-guest-utilities into Ipfire itself, but since the use is not high, I have a doubt it makes much sense.

Thanks for a great tool in XCP-ng, I enjoy using it in my home setup.
Regards
Alf Høgemark

@wlp94114 I have the same bug with OPNsense.

This is an error in the Xen guest tools package, not XCP.

You can rename libxenstore.so.4.0 to libxenstore.so.4 or wait for them to fix the package (an upstream FreeBSD issue).

FWIW I just got bit by this same thing, spending half a day yesterday kicking the wall. I think I got about 2/3 of the way just by trial and error on the cert's.

Would love to see this doc'd with the proper method, using an in-house local CA (not a public CA).

@Andrew okay now I understand! Thanks a lot!!!

@olivierlambert The update has fixed it, thanks!