There's no root password. Use sudo -s

@olivierlambert FYI turned out to be a networking issue that had nothing to do with the server itself. I'm still getting to the bottom of what exactly the cause was, and will update here once I do just in case someone else runs into this. Thanks again. And thanks for the awesome software. ! -Rob

No, there's no need to upgrade VM tools when you upgrade the host. You can keep old tools, it will work fine.

@dan2462 Did you get a resolution to your VDI issue? I have a similar problem as it seems hosts are locking up the VDI's on my shared iscsi storage and if they are shutdown and I try to boot them on an alternate host, I get the VDI not available error.

@olivierlambert Thanks for the quick feedback!

Hi @xo-g , We don't use any specific order to pick the VMs to backup.

You can have one job with 2 remotes. Or a job with backup and DR at the same time.

@mrbaz Thanks for the detailed feedback! If XO had a way of pulling the user's group information and only allowing those in a certain group to have authorization to XO to have their accounts automatically generated, that would work too. That wouldn't be trivial to implement with our current plugin system. But as you said, a user that logs into XO isn't able to do anything without granting them permissions first. Also, if this is still a concern for you, you can disable user auto-generation in xo-server configuration by adding this line: createUserOnFirstSignin = false However, you'd then have to create the users manually before they can log in. the issue still stands that I can't put a user into a group or assign ACLs until after they have signed in for the first time. I agree but I'm not sure what a good solution to this would be. If we add an option to import all the users at once, it could mean importing a lot of users for some companies, even if many of those users would never actually log in later.

@nraynaud @olivierlambert Thanks guys!

@lawrencesystems said in S3 Remote: I was hoping to avoid this method as my pfsense is not connected at 10G. Thank you for the clarification. Happy I could help.

@olivierlambert said in un-zstd .xva files exported with XOA?: Hi! Again, before starting to talk about technical solution, can you explain the use case? If you have zstd installed on your machine, yes. It's a tar with compression (gzip or zstd). But then it won't be trivial to assemble VM data (but you can exctract metadata easily!) I didn't really mean disassemble the .xva, but rather create an uncompressed .xva that has broader support/portability. The zstd command line tool seems to be able to uncompress it just fine. Thanks.

Hey there! It's a good thing to start by reading our doc. If you enter "Password" in the search field, you would have find: https://xen-orchestra.com/docs/troubleshooting.html#recover-web-login-password As you are using Xen Orchestra into production, may I suggest to go for XOA with pro support at some point?

@newknowledge Thanks, I'll try it out later.

@olivierlambert Maybe. Ive created a support ticket for now. Hopefully you can see if the problem is a configuration mistake on our end or a problem in XO. Thanks.

@jfrelik Similar issue here - still trying to figure this out. https://xcp-ng.org/forum/topic/4209/xcp-ng-and-network-virtualisation-help

Nice

You are welcome Enjoy! (great thing about xo cli is that you can get alarms of all your hosts from a single endpoint)

You can't, indeed, live migrate a VM from Intel to AMD (or vice-versa), for obvious reason (the VM will try to call Intel specific instructions after migrating on an AMD CPU, the result would be… a crash!) We had a similar migration ourselves (in our own prod), from Intel to AMD. And we decided to use Continuous Replication to make a first "backup" on destination (the full) while the original VMs were running (no service interruption). Then, we shut down the VMs, make another round of replication (delta, very fast) and then we booted on destination.

@olivierlambert That socket issue was not what was causing the problem, I went through setting by setting and if I choose 2GB of memory for a VM I get constant reboots when using XOA. I was able to repeat the issue with a number of OSs not just RHEL 8 (and variants). I havent went through and compared the differences between XOA and XenCenter yet.