@stormi said in AMD Radeon Vega M GH Passthrough:
I'd say prerequisite in that case. You can add that you think that it's probably already enabled in enterprise equipment.
OK, I've added a prerequisite section. I tried to keep the edit as concise as possible whilst still conveying the necessary information.
Hi. I've been using XCP-ng Center to manage my homelab for a while, but recently decided to give Xen Orchestra a go (mostly due to the fantastic backup options which are provided with the Premium package or built from source option). I'm enjoying using it so far (apart from an issue with some mouse and keyboard input lag, which I'm going to look more into myself to see if I can improve), but when I exported the Xen Orchestra configuration (from Settings -> Config -> Export/Download Current Config), I noticed that the resulting .json file contains the passwords for the two hosts in my homelab in plaintext.
Is this an intentional decision or an oversight? Shouldn't the password hashes be stored in the .json file (as they appear to be for the users)? Does Xen Orchestra need to store plaintext versions to connect to the hosts? Maybe I'm missing something, but would appreciate some clarification, thanks.
@julien-f said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:
@amp88 said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:
Shouldn't the password hashes be stored in the .json file (as they appear to be for the users)? Does Xen Orchestra need to store plaintext versions to connect to the hosts?
No, server passwords cannot be saved as hashes like we do for users, the use cases are completely different:
- for users, the password cannot be retrieved from the hashes. However that's not an issue because, when a user logs in, its password is hashed and compared to the stored hash
- for servers, we need to send the password itself, not a derived hash to the XCP-ng/XenServer host
There is no way to securely hide these password except from encrypting them with a password provided by an external source, like a passphrase from the user, which may not be bad idea
OK, thanks for the explanation. Allowing the user the option to secure the exported configuration with a password would be a welcome addition 