@julien-f OK, server upgrade it is.
Thanks for a prompt reply. Appreciate it.
M
Posts
-
RE: xo-cli --register produces "invalid parameters" errors in xo logsposted in Xen Orchestra
-
RE: xo-cli --register produces "invalid parameters" errors in xo logsposted in Xen Orchestra
@julien-f Hey, I am back to the original issue now:
"message": "should not contains property ["description"]If there is anything I can do to not have it in logs then great, but if not
@olivierlambert might be right that it's time to finally upgrade the server version. -
RE: xo-cli --register produces "invalid parameters" errors in xo logsposted in Xen Orchestra
Hey @julien-f, I have to get back to the issue as I had to move witn node and xo-cli to other machine and even though I have node: v16.20.0 and xo-cli: v0.17.1
I see those errors again.
Is there any way to have it fixed without upgrading xo-server? [ver: 5.87.0] -
RE: xo-cli --register produces "invalid parameters" errors in xo logsposted in Xen Orchestra
@julien-f I have installed node LTS ver and the new xo-cli works fine:
nodejs: -> v16.20.0 (Latest LTS: Gallium) xo-cli: └── xo-cli@0.17.1Thanks for help.
-
RE: xo-cli --register produces "invalid parameters" errors in xo logsposted in Xen Orchestra
@julien-f xo-cli installation runs fine. Trying to run it fails.
I have rolled it back to 0.14.0 and it works fine. -
RE: xo-cli --register produces "invalid parameters" errors in xo logsposted in Xen Orchestra
@julien-f
upgrade or reinstall of xo-cli crashes now with an error:internal/process/esm_loader.js:74 internalBinding('errors').triggerUncaughtException( ^ Error [ERR_UNKNOWN_BUILTIN_MODULE]: No such built-in module: node:assert/strict at new NodeError (internal/errors.js:322:7) at Function.Module._load (internal/modules/cjs/loader.js:781:13) at Module.require (internal/modules/cjs/loader.js:1003:19) at require (internal/modules/cjs/helpers.js:107:18) at Object.<anonymous> (/usr/lib/node_modules/xo-cli/node_modules/http-request-plus/index.js:5:16) at Module._compile (internal/modules/cjs/loader.js:1114:14) at Object.Module._extensions..js (internal/modules/cjs/loader.js:1143:10) at Module.load (internal/modules/cjs/loader.js:979:32) at Function.Module._load (internal/modules/cjs/loader.js:819:12) at ModuleWrap.<anonymous> (internal/modules/esm/translators.js:203:29) { code: 'ERR_UNKNOWN_BUILTIN_MODULE'I am not really a Java guy. What am I missing here?
-
RE: xo-cli --register produces "invalid parameters" errors in xo logsposted in Xen Orchestra
@julien-f Hey, thanks for the info. Let me update the client and get back to you.
-
xo-cli --register produces "invalid parameters" errors in xo logsposted in Xen Orchestra
I have written a script downloading info about the whole cluster using xo-cli.
The simple command:
/usr/bin/xo-cli --register --allowUnauthorized https://<web\_address> <user> <pass>even though login is successful:
Successfully logged with <username>is producing these errors in xo logs:
token.create { "description": "xo-cli --register" } { "code": 10, "data": { "errors": [ { "code": null, "reason": "strict", "message": "should not contains property [\"description\"]", "property": "@" } ] }, "message": "invalid parameters", "name": "XoError", "stack": "XoError: invalid parameters at Module.invalidParameters (/opt/xen-orchestra/packages/xo-common/src/api-errors.js:21:32) at Object.call (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:73:18) at Api.callApiMethod (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:303:19)" }Any tips on what is the issue and how to eliminate it spamming the logs?
(script has to run periodically)
-
RE: XO spawned VM from template has wrong VIF network orderposted in Xen Orchestra
@Forza Hey - thanks for the input. It would be valid if I would reboot xcp host though. All this is happening on live xcp server which is problematic.
It's no the end of the world but there has to be a way to debug it.
Any tips on that? -
RE: XO spawned VM from template has wrong VIF network orderposted in Xen Orchestra
@tjkreidl This is what I am trying to figure it out. There has to be a reason and there has to be a solution to it. Any other tips or ideas?
-
RE: XO spawned VM from template has wrong VIF network orderposted in Xen Orchestra
@tjkreidl This is surprising then that VM spawned from the template would even be able to change NIC order. This make no sense.
On the other hand how does the template know what is the list on NICs attached to the VM created from it and what should be the order of them then? -
RE: XO spawned VM from template has wrong VIF network orderposted in Xen Orchestra
@tjkreidl Thanks for the article. Unfortunately this machine is full of running VMs and changing NICs order on the host might have a global impact on all of them so it seems like an overkill.
I have created this template on this machine and created VM based on that template right away and I experience this issue. It looks like there is a problem with the template creation or template based VM creation process.
Is there a way to change it NIC order in the template itself? -
RE: XO spawned VM from template has wrong VIF network orderposted in Xen Orchestra
@olivierlambert
Thanks for the info and get well soon! -
RE: XO spawned VM from template has wrong VIF network orderposted in Xen Orchestra
@olivierlambert - any ideas as I ran out of options.
-
RE: XO spawned VM from template has wrong VIF network orderposted in Xen Orchestra
@olivierlambert
I have recreated the base VM [debian11-template], convert it to template and generated net VM [zzz-nettest2] based on that template.
These are the differences in VIF config:original VM:
uuid ( RO) : 84c4bd3e-4f50-48dc-4050-19dd4e8a8a8a vm-name-label ( RO): Debian11-template **device ( RO): 0** MAC ( RO): 9e:82:ec:4e:53:4f network-uuid ( RO): 1f7bec14-2ff5-471d-ba9c-bd84882ede17 **network-name-label ( RO): Net1** uuid ( RO) : 1d0aca18-e4f2-8b08-9ae6-022846241ab1 vm-name-label ( RO): Debian11-template **device ( RO): 1** MAC ( RO): 02:76:1f:22:c0:be network-uuid ( RO): 79fd2cb6-762a-e433-129a-edbb32612735 **network-name-label ( RO): Net2**new VM
uuid ( RO) : f4e200d6-2ba4-d2a4-961e-a0431951d25a vm-name-label ( RO): zzz-nettest2 **device ( RO): 1** MAC ( RO): 6e:18:1e:93:38:e9 network-uuid ( RO): 1f7bec14-2ff5-471d-ba9c-bd84882ede17 **network-name-label ( RO): Net1** uuid ( RO) : 16fbbd49-bb80-d111-dc83-5c47447ac174 vm-name-label ( RO): zzz-nettest2 **device ( RO): 0** MAC ( RO): a2:fe:cd:37:58:9f network-uuid ( RO): 79fd2cb6-762a-e433-129a-edbb32612735 **network-name-label ( RO): Net2**It happens no matter if I convert the template from the VM or create it from snapshot.
Template details below:
uuid ( RO) : f5b33b1c-798c-7f01-3ad6-9f5a44d1a25e name-label ( RW): Debian11-template name-description ( RW): [<env>/<DC>] <application/infra>: <app name/infra role> user-version ( RW): 1 is-a-template ( RW): true is-default-template ( RW): false is-a-snapshot ( RO): false snapshot-of ( RO): <not in database> snapshots ( RO): snapshot-time ( RO): 19700101T00:00:00Z snapshot-info ( RO): parent ( RO): <not in database> children ( RO): is-control-domain ( RO): false power-state ( RO): halted memory-actual ( RO): <not in database> memory-target ( RO): 0 memory-overhead ( RO): 19922944 memory-static-max ( RW): 2147483648 memory-dynamic-max ( RW): 2147483648 memory-dynamic-min ( RW): 2147483648 memory-static-min ( RW): 268435456 suspend-VDI-uuid ( RW): <not in database> suspend-SR-uuid ( RW): <not in database> VCPUs-params (MRW): VCPUs-max ( RW): 1 VCPUs-at-startup ( RW): 1 actions-after-shutdown ( RW): Destroy actions-after-reboot ( RW): Restart actions-after-crash ( RW): Restart console-uuids (SRO): hvm ( RO): false platform (MRW): timeoffset: 1; secureboot: false; device-model: qemu-upstream-compat; videoram: 8; hpet: true; apic: true; device_id: 0001; vga: std; nx: true; pae: true; viridian: false; acpi: 1 allowed-operations (SRO): changing_NVRAM; changing_dynamic_range; changing_shadow_memory; changing_static_range; migrate_send; provision; destroy; export; clone; copy current-operations (SRO): blocked-operations (MRW): allowed-VBD-devices (SRO): 1; 2; 4; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; 16; 17; 18; 19; 20; 21; 22; 23; 24; 25; 26; 27; 28; 29; 30; 31; 32; 33; 34; 35; 36; 37; 38; 39; 40; 41; 42; 43; 44; 45; 46; 47; 48; 49; 50; 51; 52; 53; 54; 55; 56; 57; 58; 59; 60; 61; 62; 63; 64; 65; 66; 67; 68; 69; 70; 71; 72; 73; 74; 75; 76; 77; 78; 79; 80; 81; 82; 83; 84; 85; 86; 87; 88; 89; 90; 91; 92; 93; 94; 95; 96; 97; 98; 99; 100; 101; 102; 103; 104; 105; 106; 107; 108; 109; 110; 111; 112; 113; 114; 115; 116; 117; 118; 119; 120; 121; 122; 123; 124; 125; 126; 127; 128; 129; 130; 131; 132; 133; 134; 135; 136; 137; 138; 139; 140; 141; 142; 143; 144; 145; 146; 147; 148; 149; 150; 151; 152; 153; 154; 155; 156; 157; 158; 159; 160; 161; 162; 163; 164; 165; 166; 167; 168; 169; 170; 171; 172; 173; 174; 175; 176; 177; 178; 179; 180; 181; 182; 183; 184; 185; 186; 187; 188; 189; 190; 191; 192; 193; 194; 195; 196; 197; 198; 199; 200; 201; 202; 203; 204; 205; 206; 207; 208; 209; 210; 211; 212; 213; 214; 215; 216; 217; 218; 219; 220; 221; 222; 223; 224; 225; 226; 227; 228; 229; 230; 231; 232; 233; 234; 235; 236; 237; 238; 239; 240; 241; 242; 243; 244; 245; 246; 247; 248; 249; 250; 251; 252; 253; 254 allowed-VIF-devices (SRO): 2; 3; 4; 5; 6 possible-hosts ( RO): 9a33c146-c64d-4933-a54a-18941cb825f0 domain-type ( RW): hvm current-domain-type ( RO): <not in database> HVM-boot-policy ( RW): BIOS order HVM-boot-params (MRW): firmware: bios; order: cdn HVM-shadow-multiplier ( RW): 1.000 PV-kernel ( RW): PV-ramdisk ( RW): PV-args ( RW): PV-legacy-args ( RW): PV-bootloader ( RW): PV-bootloader-args ( RW): last-boot-CPU-flags ( RO): vendor: GenuineIntel; features: 1fcbfbff-f7fa3223-2d93fbff-00000523-0000000f-019c47ab-00000008-00000000-00001000-9c000400-00000000-00000000-00000000-00000000-00000000 last-boot-record ( RO): '' resident-on ( RO): <not in database> affinity ( RW): <not in database> other-config (MRW): import_task: OpaqueRef:eccf2505-7aaf-4592-b9b0-9887cfa77b33; mac_seed: 1c02ad94-8a62-f861-eabd-0baf9b7c32d4; base_template_name: Debian Stretch 9.0; install-methods: cdrom,nfs,http,ftp; linux_template: true dom-id ( RO): -1 recommendations ( RO): <restrictions><restriction field="memory-static-max" max="1649267441664"/><restriction field="vcpus-max" max="32"/><restriction field="has-vendor-device" value="false"/><restriction field="allow-gpu-passthrough" value="1"/><restriction field="allow-vgpu" value="1"/><restriction field="allow-network-sriov" value="1"/><restriction field="supports-bios" value="yes"/><restriction field="supports-uefi" value="no"/><restriction field="supports-secure-boot" value="no"/><restriction max="255" property="number-of-vbds"/><restriction max="7" property="number-of-vifs"/></restrictions> xenstore-data (MRW): vm-data: ; vm-data/mmio-hole-size: 268435456 ha-always-run ( RW) [DEPRECATED]: false ha-restart-priority ( RW): blobs ( RO): start-time ( RO): <unknown time> install-time ( RO): <unknown time> VCPUs-number ( RO): <not in database> VCPUs-utilisation (MRO): os-version (MRO): PV-drivers-version (MRO): PV-drivers-up-to-date ( RO) [DEPRECATED]: false memory (MRO): disks (MRO): VBDs (SRO): fd0f2074-c6e8-b505-b5dc-95ac02fc4e42; 0bc0c5cd-afb5-54f3-8a48-815539029c4c networks (MRO): PV-drivers-detected ( RO): false other (MRO): platform-feature-multiprocessor-suspend: 1; has-vendor-device: 0 live ( RO): true guest-metrics-last-updated ( RO): 20220711T14:23:59Z can-use-hotplug-vbd ( RO): unspecified can-use-hotplug-vif ( RO): unspecified cooperative ( RO) [DEPRECATED]: true tags (SRW): appliance ( RW): <not in database> snapshot-schedule ( RW): <not in database> is-vmss-snapshot ( RO): false start-delay ( RW): 0 shutdown-delay ( RW): 0 order ( RW): 0 version ( RO): 0 generation-id ( RO): hardware-platform-version ( RO): 0 has-vendor-device ( RW): false requires-reboot ( RO): false reference-label ( RO): debian-9 bios-strings (MRO): bios-vendor: Xen; bios-version: ; system-manufacturer: Xen; system-product-name: HVM domU; system-version: ; system-serial-number: ; enclosure-asset-tag: ; hp-rombios: ; oem-1: Xen; oem-2: MS_VM_CERT/SHA1/d43fa6d3fe8aaef04c2bad9d3e3daaef04c2bad9d3 -
RE: XO spawned VM from template has wrong VIF network orderposted in Xen Orchestra
@olivierlambert I am surprised as well, that is why I have raised this question.
Template is saved with the networks order Net1 Net2.
VM spawned from it is having networks order Net2, Net1.Is there a way to check which order the template was created with?
Maybe the networks were renamed in the mean time or something?
I am shooting in the dark here ... -
RE: XO spawned VM from template has wrong VIF network orderposted in Xen Orchestra
@olivierlambert I can see template having allowed-VIF-devices list:
allowed-VIF-devices (SRO): 2; 3; 4; 5; 6but I do not see any list of preferred order of them.
Is there a way to force template to to use it in specific order?
And why would VM created based on the template have that order reversed? -
RE: XO spawned VM from template has wrong VIF network orderposted in Xen Orchestra
@olivierlambert Anything else I may provide to help to fix this issue?
Thanks