@MathieuRA user-id bg: when you call session.signIn you get the user-id and that id is used to fetch user specific vms. { "id": -9007199254740991, "jsonrpc": "2.0", "result": { "id": "f2858952-b02a-403a-98ca-d94e4cdaa57e", "email": "testirtaza1", "groups": [], "permission": "none", "preferences": {} } } [image: 1739959932713-f4b361d6-6944-4cf4-96c2-7f79c9735ebe-image.png] @olivierlambert yes, issue is resolved. Thanks to @MathieuRA and @Danp

@irtaza9 OK so you have VLANs per DC. That means VLAN5 in KPK-DC1 and VLAN5 in RWP-DC4 are unrelated and machines in those VLANs cannot communicate directly without going trough some router? This goes back to my original answer. You have to take into account network connectivity when deciding what DC/pool to select for VM provisioning. If you have a few VMs in VLAN5 in KPK-DC1 and you decide to provision some more VMs at latter time that require direct connectivity with existing VMs, you have no choice but to provision them in VLAN5 in KPK-DC1. Regarding VLANs in general, this is all fine except you can scale it up to a few thousand of VLANs per DC so it will impose a hard limit on the number of isolated network segments (i.e. users/customers). Some weapon of choice among most cloud providers is to use some kind of network overlay like VX-LANs, GRE tunnels and such but this has issues of it's own. For a start, these kinds of networks are software defined in nature (SDN), require an orchestrator and network nodes that run in software. You can leverage some hardware acceleration here and there but it will still be software oriented and have scaling and latency issues. There is no silver bullet and most providers hide their network implementation details. All in all, a good, scalable and fast networking i probably the toughest thing to implement in any large scale cloud provider... and I'm definitely not a network engineer so I can't say much about it .

@bufanda yes I have checked that feature too. Let me dig further to make it useable for my use case.

@benutop - We see that all the time, its purely cosmetic it seems. I think it has to do with XO recognizing your permissions as a user. We have other users constantly using our environment so we know XO is not actually disconnecting.

@olivierlambert My XO is deployed and when i go to console it gives me access. production XO wss://xenorchestra1.nayatel.com/api/consoles/vm-id test XO ws://xen.zeests.com:7778/api/consoles/vm-id I have tokens for both services. Now I want to access the console from a different web application who is running on different host and have a different domain mapped. How can I achieve this? One Error is: noVNC requires a secure context (TLS). Expect crashes!

@Danp Yup, that will do it. Thanks. No longer pulling out my hair.

Ping @julien-f

@Pix FYI, I was just doing some testing on this exact function and I was able to add a network to the pool when using the UUID for the host's matching PIF. The UUID you were using is from the pool's network, which won't work here. For example -- Networks [17:29 xenserver-slnqfzrh ~]# xe network-list uuid ( RO) : a379a6e7-f099-f838-6514-486de4d56e80 name-label ( RW): Pool-wide network associated with eth0 name-description ( RW): bridge ( RO): xenbr0 uuid ( RO) : b14a0bdd-2f77-25f7-3a76-b830ff971624 name-label ( RW): Pool-wide network associated with eth2 name-description ( RW): bridge ( RO): xenbr2 uuid ( RO) : 00b6604f-9098-023b-5880-0ef9f8e1b437 name-label ( RW): Pool-wide network associated with eth1 name-description ( RW): bridge ( RO): xenbr1 uuid ( RO) : e3be0e1a-9872-4b90-c851-35eb30a86920 name-label ( RW): Pool-wide network associated with eth3 name-description ( RW): bridge ( RO): xenbr3 uuid ( RO) : c54ecffe-9467-5d5f-cb73-ec10dedef2b9 name-label ( RW): Host internal management network name-description ( RW): Network on which guests will be assigned a private link-local IP address which can be used to talk XenAPI bridge ( RO): xenapi PIFs [17:49 xenserver-slnqfzrh ~]# xe pif-list network-uuid=00b6604f-9098-023b-5880-0ef9f8e1b437 uuid ( RO) : ea3edc31-9b23-402c-a65e-2316c88febb5 device ( RO): eth1 currently-attached ( RO): true VLAN ( RO): -1 network-uuid ( RO): 00b6604f-9098-023b-5880-0ef9f8e1b437 uuid ( RO) : 3a1ef416-787f-45b4-ace9-0147c2f3ca07 device ( RO): eth1 currently-attached ( RO): true VLAN ( RO): -1 network-uuid ( RO): 00b6604f-9098-023b-5880-0ef9f8e1b437 Adding a VLAN [18:27 21] xoa:xoa$ xo-cli network.create pool=63b7154a-1a6c-8642-525e-c6abb0acc941 name="VLAN20 - On Eth1" pif=ea3edc31-9b23-402c-a65e-2316c88febb5 vlan=json:20 52d18dc6-8078-a7ce-4bc5-d4337d2fb970 HTH, Dan

Hi, Can you describe the target/objective you want to achieve/expect?

@pxn said in Java SDK, XmlRpcClientException: Failed to parse server's response: Duplicate name: restrict_vtpm: If you still encounter this issue - I found the way to bypass it. You can create your own mapper by extending on RecursiveTypeParserImpl and just copy-paste logic from MapParser (package org.apache.xmlrpc.parser;), except that logic of checking duplication, then you can inject custom parser to your custom factory (Extend TypeFactoryImpl and override getParser method). And inject this Factory to your client new XmlRpcClient().setTypeFactory(new CustomFactory(client)); This works fine for me, I hope this could help you. Alex

Yes, you can have a list of all available calls by doing xo-cli list-commands

Yes, you can use JSON-RPC et REST APIs together for now We will try to add support for CPU settings soon. Also, expect things to accelerate in 2025 regarding the REST API.

@CodeMercenary Can't help you there. The only thing I use(d) is the cli on the xcp hosts themselves. reboot or shutdown

@samuelolavo Shell only handles string values, to pass other types to xo-cli you need to encode them in JSON and use the json: prefix: xo-cli resourceSet.create name=test-resource subjects=json:'["d301d9ea-9e22-4480-bf40-111111111111"]' objects=json:'["8fb06362-d8fe-598b-f819-11111111111111"]' shareByDefault=json:true

@samuelolavo No, users management and self service are not in the REST API yet.

@julien-f thanks! I have tested it and its working now! cheers Ringo

Yes, you can use Terraform directly

Hi @olivierlambert , Okay, I made some progress today and have worked out the steps to remove, delete or add drives to a VM. Removed drive from the server attached to and also deleted the disk itself xo-cli vdi.delete id=<the id of the VDI> Removed drive from the server attached to, but didn't delete the disk! xo-cli vdb.delete id=<the id of the VBD> Added a drive to the server xo-cli vm.attachDisk vdi=<the id of the VDI> vm=<the id of VM> If was the last one that I was missing. I'm still not sure of the difference between the 'uuid' and 'id' fields, but will use the 'id' as this seems to be what the commands are wanting. Thanks Kent.

Perfect, excellent news Enjoy XCP-ng!