@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 
@julien-f said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:
FYI, this feature has been released
Great, and thanks for letting me know
@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
@Danp said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:
@amp88 FWIW, there's an open issue on GH dealing with this.
Ah, thanks for letting me know.
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.
@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.
@stormi said in AMD Radeon Vega M GH Passthrough:
By the way, could someone edit https://github.com/xcp-ng/xcp/wiki/PCI-Passtrough to add information about the VT-d requirement?
I was thinking about doing it, but I'm not sure whether it should be added to the guide as a "prerequisite" step at the beginning (e.g. check it's enabled before you begin the guide) or in a "troubleshooting" step at the end (e.g. if you experience this error, check it's enabled). Which approach is better probably depends on the ratio of systems where it's enabled by default, which I would believe/assume is relatively high with enterprise equipment and relatively low with consumer equipment.
@AmandaBeuno I had the same error as you're getting now ("Internal error: xenopsd internal error: Device.PCI.Cannot_add(_, _)" when attempting to perform PCI passthrough of an HBA card on a system which didn't have the required virtualisation feature (VT-d) enabled.
As r1 mentioned above, have you made sure that your system has virtualisation support enabled in the BIOS/UEFI? I've never used a Hades Canyon NUC before, but from this BIOS overview video it appears you want to enter the BIOS/UEFI at boot and then navigate to the Advanced -> Security tab. Then make sure under "Security Features" both "Intel Virtualization Technology" and "Intel VT for Directed I/O (VT-d)" are enabled.
Intel Hades Canyon NUC NUC8i7HVK BIOS Walkthrough (relevant section at 2:17, link is timestamped)