@hellst0rm I don't see why it wouldn't work as long as everything is set to trust your internal CA root. It's pretty trivial to create a CA. I did it years ago because I can't stand cert errors and as a learning exercise. The only annoying part is it's just one more thing to keep track of and update, but if you're running a homelab it just becomes another part of the exercise.

I run my own CA internally and ran into the same issue when I tried using XO Lite for the first time. The cert worked for connecting to the pool master, but I think the consoles wouldn't work and definitely connecting to VMs on different members of the pool didn't work without accepting the cert error my browser was reporting. I figured out that those calls seem to be happening by IP instead of name, so I just regenerated my certs with the hostname and ip as SANs on the certs of all my hosts and it resolved the issue for me too. The way to work around it would be for XO Lite to make those calls to other resources by hostname instead of IP from what I can tell without digging into it any further than I did.

@stormi any chance of adding Realtek r8156? I started working on it a while go but couldn't quite get it to work.

Ok, I was able to fix this. I migrated it to the pool master on the cli. I don't think this was necessary in hindsight but I just wanted to be sure I knew where it was running. I then brought up xo-lite in Chrome on the pool master. At that point I could view the VM in the embedded console. It turned out that the root partition had errors on it and was stuck in Initramfs waiting for fsck to be run. Once I repaired the errors with fsck, the VM booted and I'm back in business.

I have 3 NUCs in a pool, and a TrueNAS system serving NFS for a couple VMs. One of those VMs is my XOA server. I recently applied an available patch for TrueNAS but forgot to power down the XOA server beforehand. Afterwards I saw the filesystem on the Debian guest was read-only and realized what had happened.

I tried to resolve this by powering down the VM, but I was only able to do this by forcing the power off. I brought the VM back up and I can no longer ping it. I've tried everything I can think of, including restarting one of the hosts in the pool and restarting the XOA VM on that host in case the issue was the host NFS mount. None of this has worked. Any ideas on how to get this back up and running?

@Mcvills ah, cool. Well at least that fix is there in case anyone else stumbles upon what I was hitting.

if you do an 'apt-get update' are you getting a GPG error about the yarn repository signature being invalid? If so, maybe try this fix posted by boeboe on Feb 11th. I kept seeing the error every time I updated the system I have xo built on and that finally cleared it up for me. I can't tell you if that would have prevented me from doing the initial build though because mine has been up for some time now.

My particular setup may be a bit weird but here's a better description. I have my primary pool of servers running at home, and XOA runs there. I have a site-to-site VPN between home and the remote location so I can reach the remote host which is also managed through my XOA instance through the VPN tunnel. I don't need any proxies for this to work because I setup a VPN tunnel and XOA and the remote host have direct IP connectivity.

On the remote host, I have a VM that runs in an isolated network not reachable from home, so I cannot connect directly to the guest with VNC. If I'm connected to my home network I can see this guest through XOA. If however I connect to the VPN service at the remote end (different than the site-to-site tunnel) to get access to normal resources on the remote end and also want to use my test VM it becomes difficult to reach the VM because I can't reach my XOA instance back at home easily.

I'm not sure a proxy would solve this. I followed the instructions to test XO Lite and that looks like it is sort of what I am looking for. When I log into my remote host I can see the dashboard and the list of guests, but I don't see the console for the guests. Is the console supposed to be present or is the plan for it to be exposed in the future? If so, that would solve my problem.

Re: Is there something like VMRC (VMware Remote Console) for XCP-ng?

I found this old topic that sort of matches what I'm looking for but I don't know if its quite what I'm looking for.

I have several XCP-ng servers setup and they're being managed through XOA. All this is working properly. Nearly all of my VMs are just handling a workload of sorts that I either ssh into or connect to via the web just as you'd expect for any normal server.

I have an edge case that I also need to solve for. In a couple cases I have a VM running in an isolated network for testing purposes. The host is in a network that I can route to, but the guest is intentionally not and adding routing to allow direct connections is either not possible or would invalidate what I'm trying to test. Right now, the only way I can figure out how to manage these instances is through the XOA web console. This works, but with ESXi I could either do this or have a direct link to the VM through the VMRC client that I could use. It was a nice feature to have because I could put that URI into a wiki and click on it to launch the client and reach the VM.

Is there any way of replicating that functionality with XCP-ng through a VNC session? I'd assume my VNC client would have to point to the host where the VM is running on a certain port and the host would have to know to present the virtual console through to it.