Posts made by mietek | XCP-ng and XO forum

mietek

@julien-f OK, server upgrade it is.
Thanks for a prompt reply. Appreciate it.

mietek

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

mietek

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]

mietek

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

Thanks for help.

mietek

@julien-f v14.21.3

mietek

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

mietek

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

mietek

@julien-f Hey, thanks for the info. Let me update the client and get back to you.

mietek

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)

mietek

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

mietek

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

mietek

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

mietek

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

mietek

@olivierlambert
Thanks for the info and get well soon!

mietek

@olivierlambert - any ideas as I ran out of options.

mietek

@olivierlambert - any ideas?

Thanks

mietek

@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

mietek

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

mietek

@olivierlambert I can see template having allowed-VIF-devices list:
allowed-VIF-devices (SRO): 2; 3; 4; 5; 6

but 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?

mietek

@olivierlambert Anything else I may provide to help to fix this issue?
Thanks