Cannot use cloudConfig while creating VM with RPC call
-
await this.putResource(cancelToken, stream, '/import_raw_vdi/', { query: { format, vdi: ref, }, task: await this.task_create(`Importing content into VDI ${await this.getField('VDI', ref, 'name_label')}`), })
This returns 404. I'm trying to understand what does /import_raw_vdi/ do? Also, this task gets created on the master host instead of the slave, even for the VMs that are scheduled on the slave host. Is that why it returns a 404? If it does, then how does the filesystem for the cloudconfigdrive get created on the slave? Maybe that needs to be moved over to the master as well? I don't know if I'm understanding currently or not so feel free to correct me if this is not how it works and my assumptions are wrong
-
The problem is already detected by @julien-f
Expect a fix in the next days or in our next XOA patch release next week
-
@olivierlambert Awesome! I use XO built from git source so will monitor the commits then. Thanks!
-
@olivierlambert Just tried the latest changes from xen-orchestra and the problem persists. I get the exact same error produced in XO when importing CloudConfigDrive on a slave:
2023-05-13T09:03:41.719Z xo:xapi WARN importVdiContent: { error: Error: 404 Not Found at Object.assertSuccess (/home/node/xen-orchestra/packages/xen-api/node_modules/http-request-plus/index.js:140:19) at httpRequestPlus (/home/node/xen-orchestra/packages/xen-api/node_modules/http-request-plus/index.js:207:22) at Xapi.putResource (/home/node/xen-orchestra/packages/xen-api/src/index.js:508:22) at Xapi.importContent (/home/node/xen-orchestra/@xen-orchestra/xapi/vdi.js:138:7) at Xapi.createCloudInitConfigDrive (file:///home/node/xen-orchestra/packages/xo-server/src/xapi/index.mjs:1332:5) at Xo.<anonymous> (file:///home/node/xen-orchestra/packages/xo-server/src/api/vm.mjs:217:11) at Api.#callApiMethod (file:///home/node/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:417:20) { originalUrl: 'https://10.0.0.12/import_raw_vdi/?format=raw&vdi=OpaqueRef%3Aa4c7cb1a-8e78-4da2-b35a-f3b113ebbb6c&session_id=OpaqueRef%3A828e4212-69aa-2987-bbc4-4e52365ce42a&task_id=OpaqueRef%3A1c14118b-d2e4-f178-3484-4b9c13c50bc7', url: 'https://10.0.0.13/import_raw_vdi/?format=raw&vdi=OpaqueRef:a4c7cb1a-8e78-4da2-b35a-f3b113ebbb6c&session_id=OpaqueRef:828e4212-69aa-2987-bbc4-4e52365ce42a&task_id=OpaqueRef:1c14118b-d2e4-f178-3484-4b9c13c50bc7', pool_master: host { uuid: 'd1e916dc-8f8a-4aec-98c1-206c4c8144b0', name_label: 'minisforum-hm80-01.servers.illenium.gg', name_description: 'Default install', memory_overhead: 1161101312, allowed_operations: [Array], current_operations: [Object], API_version_major: 2, API_version_minor: 20, API_version_vendor: 'XenSource', API_version_vendor_implementation: {}, enabled: true, software_version: [Object], other_config: [Object], capabilities: [Array], cpu_configuration: {}, sched_policy: 'credit', supported_bootloaders: [Array], resident_VMs: [Array], logging: {}, PIFs: [Array], suspend_image_sr: 'OpaqueRef:b90d54ba-44e7-8181-a4a2-6593276e73cd', crash_dump_sr: 'OpaqueRef:b90d54ba-44e7-8181-a4a2-6593276e73cd', crashdumps: [], patches: [], updates: [], PBDs: [Array], host_CPUs: [Array], cpu_info: [Object], hostname: 'minisforum-hm80-01.servers.illenium.gg', address: '10.0.0.12', metrics: 'OpaqueRef:655a27bd-de06-75cb-d231-8460d949d70a', license_params: [Object], ha_statefiles: [], ha_network_peers: [], blobs: {}, tags: [], external_auth_type: '', external_auth_service_name: '', external_auth_configuration: {}, edition: 'xcp-ng', license_server: [Object], bios_strings: [Object], power_on_mode: '', power_on_config: {}, local_cache_sr: 'OpaqueRef:b90d54ba-44e7-8181-a4a2-6593276e73cd', chipset_info: [Object], PCIs: [Array], PGPUs: [Array], PUSBs: [Array], ssl_legacy: false, guest_VCPUs_params: {}, display: 'enabled', virtual_hardware_platform_versions: [Array], control_domain: 'OpaqueRef:58fb5c9b-18c4-6578-803a-d9b8db989ec9', updates_requiring_reboot: [], features: [], iscsi_iqn: 'iqn.2023-03.gg.illenium.servers:6e94cf19', multipathing: false, uefi_certificates: '', certificates: [Array], editions: [Array], pending_guidances: [], tls_verification_enabled: true, last_software_update: '19700101T00:00:00Z', https_only: false }, SR: SR { uuid: '8c7e88d7-25b4-02e2-5a4b-6e1e3ead70cf', name_label: 'minisforum-hm80-02 SSD', name_description: '', allowed_operations: [Array], current_operations: {}, VDIs: [Array], PBDs: [Array], virtual_allocation: 45583695872, physical_utilisation: 290037760, physical_size: 901115478016, type: 'ext', content_type: 'user', shared: false, other_config: [Object], tags: [], sm_config: [Object], blobs: {}, local_cache_enabled: true, introduced_by: 'OpaqueRef:NULL', clustered: false, is_tools_sr: false }, VDI: VDI { uuid: '24d348fa-a8db-45b9-a623-724e64883a55', name_label: 'XO CloudConfigDrive', name_description: '', allowed_operations: [Array], current_operations: {}, SR: 'OpaqueRef:13a829ed-3408-f42e-695e-f14adf469fb3', VBDs: [], crash_dumps: [], virtual_size: 10485760, physical_utilisation: 3584, type: 'user', sharable: false, read_only: false, other_config: {}, storage_lock: false, location: '24d348fa-a8db-45b9-a623-724e64883a55', managed: true, missing: false, parent: 'OpaqueRef:NULL', xenstore_data: {}, sm_config: {}, is_a_snapshot: false, snapshot_of: 'OpaqueRef:NULL', snapshots: [], snapshot_time: '19700101T00:00:00Z', tags: [], allow_caching: false, on_boot: 'persist', metadata_of_pool: '', metadata_latest: false, is_tools_iso: false, cbt_enabled: false } } }
It stills tries to use the master and results in a 404
I'm running XO with the following version:
-
Please provide the commit you are using, not the version
-
@olivierlambert sure. Using commit 17b275629109160ea3840de0fc70a1faf41bd392
-
Okay that's good. Are you sure you did rebuild everything?
-
@olivierlambert said in Cannot use cloudConfig while creating VM with RPC call:
Reply
yes I did rebuild everything properly. I even built a new container using dockerfiles from here using the commit above: https://github.com/Ezka77/xen-orchestra-ce
and then pushed and tested it and got the same result -
Pinging @julien-f
-
@julien-f what's weird is that the
url
points to the correct Host (Slave) but theoriginalUrl
points to the Master. I'm not sure which one receives the request since it is unclear from the warning. My suspicion is that it is 1 of the 2 (assuming that the affinity host is the Slave):- The VDI content i.e., Cloud Config gets built on the Master but when calling /import_raw_vdi it triggers the Slave endpoint i.e.,
url
- (Most likely) The Cloud Config gets built on the Slave but when calling /import_raw_vdi it triggers the Master endpoint i.e.,
originalUrl
I think #2 is most likely what's happening because I see an Import VDI hanging task on the Master host for every VM that was scheduled on the Slave. I saw it through XOA in the tasks section
- The VDI content i.e., Cloud Config gets built on the Master but when calling /import_raw_vdi it triggers the Slave endpoint i.e.,
-
@TheiLLeniumStudios I messed up my previous fix , a new one has been merged yesterday: https://github.com/vatesfr/xen-orchestra/commit/01ba10fedb3c47720391c0bcd15751ac557ac3c1
-
@julien-f awesome! Let me give it a try right now
-
-
@julien-f The problem seems to be fixed now! Thank you for the fix
-