It's not that I'm not happy, I'm just explaining why it makes more sense to post issues on the GitHub repo that you used to install XO in the first place What if a 3rd party installed is installing XO in the incorrect way? We have already many messages to deal with, adding potential 3rd party installer would make it even harder for us regarding our community support

Solved by 583c728

And I confirm this, the problem has disappeared. Thank you

This can happen since using the sources means also experiment some bugs, while on XOA, you should be safer because we do QA before each release. If you want stability and a production grade solution, go for XOA Anyway, the bug is now fixed, get the latest commit on master and try again, it should work!

@paulorrockgit thanks paul for the bug report and exploration I propose this bugfix : https://github.com/vatesfr/xen-orchestra/pull/7504 and can deploy it on your XOA fbeauchamp opened this pull request in vatesfr/xen-orchestra closed fix(vwmare-explorer): handle raw cdrom #7504

@olivierlambert I was able to get the import working by importing into vmware workstation, exporting to ovf and then converting to ova with vmwares command line tool.

@Tristis-Oris said in SMB ISO share can't upload: @mohammadm looks like Truenas related issue. Check the account permissions. if it stop working after XO update, try to rollback previous commit. User – xcp-ng Read | Write | Execute For now I upload the ISO's through Windows SMB. Because it is accessible from XOA. Only uploading is not working.

I'm using ZeroTier and access works, except for the console view.

@ckargitest You need to run: fs0: cd \efi\boot and then run the program which is in this folder. It took me a while as well to figure it out.

I'm also getting the "self-signed certificate" error sinds the last update. I get it while trying to import/upload ISO. From source, commit e52b1 8.3 beta

I added a big warning in step 3 which should never be done outside a test host that you are ready to reinstall afterwards. @codycrypto's comment is another workaround which replaces it without any impact on the host, but weakens the security by accepting weaker key types.

@TodorPetkov thanks, and apologies for the (very basic) off-topic questions. Also first time using server-core.

@jasonnix said in A question for the creators of XO: Hi @john-c, Thank you for your great tips. As I said, I've heard that Java and JavaScript are insecure, but they also have some advantages that you and others have pointed out. For example, they have a large community of users and developers. Sorry, but I think that sometimes we don't choose the right path. For example, I'm sure that a professional PHP or Ruby developer can convince you that JavaScript is not the right choice for some projects. If PHP or Ruby were not good programming languages, then they would not have so many fans and everyone would use JavaScript. One of the reasons why JavaScript is so popular is that this language can be run by browsers. Something like a standard for the web. In my opinion, JavaScript like Windows operating system. It has capabilities and features, but the most important reasons for its popularity are its large number of users and ease of use. My other question is, why is there no program under the operating system to manage XCP-ng? If you are talking about directly on XCP-ng operating system there are. In this case there's two options:- XO Lite xe Though XO Lite is new and still being developed its designed to be hosted (embedded) on the currently beta XCP-ng version 8.3. It's aim is to provide a features consistent with a single host or single pool environment. It's aimed at home lab users mostly so they can perform basic tasks, without having to install any extra software on client computers. Though technically it's viewed and invoked remotely but the commands are done directly on the pool master XCP-ng host. The remote viewing and invoking is done on a client device through the web browser or if installed as PWA the browser engine. The other option is xe its command line based so everything you wish to do needs to be typed out in the right syntax. Even tasks as basic as creating a new VM require multiple commands, several of which are from xe to perform a part. To manage XCP-ng remotely you have the option of:- Xen Orchestra XCP-ng Center Xen Orchestra - XO CLI Xen Orchestra - REST API A bit off topic are you any good with PowerShell? If so how about reading up on the relevant documentation about XAPI and/or XO's API so that a PowerShell commandlet can be developed?

@Danp yes, I'm getting this error on the settings > remotes page. As you can imagine, I'm confused why NFS works on the main SR page, but not the settings > remotes page EDIT: never mind, discovered that I have to put the full share path, not just the share name. Example: \\10.69.50.31:Port:/mnt/user/UnraidBackup/XCPNGBackups

@jqueiroz said in SSL Inspection Certificates: Don't you love to find the answer by yourself just after asking in the community forum? Create directory '/usr/local/share/ca-certificates' Copy the needed certificates this place Run /usr/sbin/update-ca-certificates [seems not be on the path]. @john-c said in SSL Inspection Certificates: Also for future reference if you ever re-do a server note that XCP-ng's certificates can be done through the XO application. Thanks. But, just for clarification, it wasn't the XO/XOA server certificate, was the certificates that sign all the HTTPS pages we visit. I uncovered a much more effective and supported method that that one you done. Follow the steps in the documentation for the XCP-ng hosts, utilising a certificate chain to include you custom CA certificate. Not forgetting setting up a custom extra CA for xen orchestra via an additional configuration file documented in the documentation for XO VM. Also by the way the method you did in the post above will be lost on upgrade, as well as likely not included in the backup feature process of XO application. However the links below will get included in the backup feature and the backup of XO configuration. Plus your method will potentially interfere with software update package which comes from the official repository, that updates the certificate authority certificates and their trusts. https://xen-orchestra.com/docs/configuration.html#custom-certificate-authority https://xen-orchestra.com/docs/configuration.html#https-and-certificates https://docs.xenserver.com/en-us/citrix-hypervisor/hosts-pools.html#install-a-tls-certificate-on-your-server https://docs.xcp-ng.org/guides/TLS-certificates-xcpng/

@john-c well, me too. But since it gets neither at the moment. And being realistic in that they can't be excpected to keep up with every distro in existance. I'll take what I reasonably can get Update: Let me clarify. If there could be Distro specific logos, then that would be awesome. However, if we could get a generic Tux for Linux in general. Then that would cover a large part of the variants out there.