@nathanael-h thanks for info i used https://github.com/ddelnano/packer-plugin-xenserver but because of lack of ssh key support i changed the code a bit. now i can use ssh keys. (not ready for a PR) my problem is that inside the auto iso i use a shell script doing a reboot within the install. the reason is that i use this iso also on bare metal installations, some software i cant install without doing a reboot. i will now focus on the ansible integratian an fire the commands after the reboot using ansible. this might work. br Mark

@jcharles said in How to Use xo-cli to Get network=<XCP_Network_UUID> and sr=<XCP_SR_UUID> for vm.importFromEsxi Command?: Thanks that worked. I give that a go thanks Your welcome.

Hi, No, there's only one console, which is the "virtual screen" of the VM. If you want multi user thing, check VDI solution, like UDS Enterprise https://docs.xcp-ng.org/project/ecosystem/#uds-enterprise

@MathieuRA @Danp Thank you so much

Hi @irtaza9. The REST API is only available for admin users. It is planned to handle other types of users in a few months

@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.

@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