Managing a host using a proxy
-
Let me do a recap on what I have (because it actually works for our own prod):
10.27.50.4
is the IP address of your pool master, that's behind a NAT, right?10.27.50.159
is the NAT/fw address that you can reach from your XOA, right? In that case, I find it weird it's exactly the same range than the server behind the NAT (for example, in my case, I have a purely public IP as the NAT/fw address, and then a private IP in another range for the host and the proxy)- What's your XO Proxy IP? Can it reach the IP address of the pool master?
All in all I think it's an environment/configuration issue than anything else.
-
xcp-ng host
Private: 192.168.1.4
Public: 10.27.50.4XO Proxy
Private: 192.168.1.159
Public: 10.27.50.159XOA
Private: 192.168.1.199
Public: 10.27.0.199XOA can connect to the xcp-ng host
XOA can connect to the xo proxyMy problem appears to be similar to this post that appears to have been resolved with a proxy upgrade that was problematic.
https://xcp-ng.org/forum/topic/6626/xo-proxy-not-workingWhen I try to upgrade the proxy I receive the following error:
proxy.upgradeAppliance { "id": "5271ae70-d243-4722-bba5-e4e381d1703b" } { "code": -32000, "message": "unknown error from the peer" }
-
Is this kind of a test network?
-
No.
Edit: We are testing xcp-ng as an alternative to HyperV and would require the proxy functionality.
-
I don't get why you have similar ranges between different networks
@julien-f any idea why proxy doesn't work? Sounds like a topology or connectivity issue to me
-
We have multiple distinct networks at client sites all connected via VPN, some use the same range.
Each is contactable using a unique network range via NAT 10.27.X.X
Works well and has done for years.
-
Obviously there's something wrong otherwise it would work (as we have many users relying on the proxy). It's hard to tell more without having a support tunnel open and trying to poke around.
-
OK, so how do we do that?
-
Since we are all ultra mega busy right now (despite we hire like crazy), your best chance is to be seen as a valuable lead so we can spare some engineer time to take a look and see if there's an obvious issue: https://vates.tech/contact
Or wait for someone in the community to dig deeper in here, depends on how patient (or how in a hurry) you are
-
When deploying a proxy from the terminal what Xen Orchestra credentials are used?
https://xen-orchestra.com/blog/xo-proxy-a-concrete-guide/Is this my Vates account, the login creds for the XOA or the login creds for the xcp-ng server it is being installed on?
-
You deploy from this script directly from your XCP-ng host. Then, the proxy doesn't have credentials but a token.
-
Sorry, still unclear on what creds to use here:
-
Those are your Vates/Xen.orchestra.com creds
-
Hello @McHenry I wanted to share with you that we've just build a new images for XOA and the proxy. You might want to try it and keep us posted.
-
Got it. To assist in my understanding of the ecosystem can you advise the purpose of these creds.
Is it simply to allow Vates to monitor usage of proxies? As the install completes even if no creds are entered, are they optional?
-
IIRC, it's needed to attach a proxy support license to your appliance. If you don't do it here, you'll have to register afterward. That's because proxies are an extra product invoiced per product.
-
Adding @julien-f in the convo for confirmation.
-
No problem however I am confused.
If I use XO, which does not need registration, and the proxy does need registration however is the proxy registration tied to the unregistered XO?