@olivierlambert said in "global name 'commmand' is not defined" while installing patches:
Hi,
Are you on XOA or XO from the sources? If from the sources, there's no versions for XO or its components.
We might have an issue so you should probably try to rebuild on
pierre-fix-rpubranch, and then try again
Well, I report these versions:
Okay 
Hello,
xo-server 5.90.2
xo-web 5.95.0
Trying to install patches on a 8.2 host via VM -> Patches -> "Install all patches"
-1(global name 'commmand' is not defined, , Traceback (most recent call last):
File "/etc/xapi.d/plugins/xcpngutils/__init__.py", line 101, in wrapper
return func(*args, **kwds)
File "/etc/xapi.d/plugins/updater.py", line 96, in decorator
return func(*args, **kwargs)
File "/etc/xapi.d/plugins/updater.py", line 157, in update
raise error
NameError: global name 'commmand' is not defined
Sounds like a typo....
Thanks.
Hello,
xo-server 5.90.2
xo-web 5.95.0
Pool (choosing the desired one) -> Patches -> "Install pool patches".
Fails with:
Cannot read properties of undefined (reading 'sort')
The pending patches are:
Any idea why?
Thanks.
@olivierlambert said in Migrating from Intel -> AMD:
I don't know, but what I can tell is the fact I myself migration my own production from Intel to AMD without any issue, so I really wonder why your guest can't boot
Well it's weird... because happens with all Ubuntu 16 hosts too.
For this Debian in particular, even after upgrading to bullseye, still won't boot on any AMD host, only on Intel ones. Finally I just reinstalled from scratch on an AMD host and migrated the data.
@olivierlambert said in Migrating from Intel -> AMD:
So this is a guest issue then
Can you try to boot this VM with a live CD? (eg Ubuntu).
Well the guest boots perfectly from any other Intel host. I can certainly boot from a live CD though. Any action I should try once I'm there?
@olivierlambert said in Migrating from Intel -> AMD:
Are you fully up to date on 8.2 and rebooted after all updates?
Yes. And just in case, since there are no other servers there:
uptime:
12:52:12 up 21 min, 1 user, load average: 0.75, 0.22, 0.07
But still not booting.
Also when moving a pfsense VM, I had to do the procedure described here:
https://xcp-ng.org/forum/topic/5706/the-emulator-required-to-run-this-vm-failed-to-start/9
Hello,
We're moving from an Intel pool to an AMD one.
Turns out that even a pretty basic Debian won't boot under AMD. Kernel panics and happens so fast that even recording the screen doesn't show how it begins.
We've tried to copy a sample VM to the new host, also converting it to a template and then creating a new VM from it. Nothing works.
Is there any (known) procedure for doing this?
XCP-NG 8.2 in all the hosts (both Intel an AMD).
Thanks.
@Danp said in The emulator required to run this VM failed to start..?:
Restart the toolstack on each server.
This worked for me.
@olivierlambert Okey... it can be deleted from there directly, I don't know why I didn't try that in the first place. Thanks
More info:
[11:39 monitor ~]# xe template-param-list uuid=aa43730c-b242-7a11-c359-bc13fa509320
uuid ( RO) : aa43730c-b242-7a11-c359-bc13fa509320
name-label ( RW): ELIMINAR
name-description ( RW):
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): 0
memory-target ( RO): 0
memory-overhead ( RO): 73400320
memory-static-max ( RW): 8589934592
memory-dynamic-max ( RW): 8589934592
memory-dynamic-min ( RW): 8589934592
memory-static-min ( RW): 536870912
suspend-VDI-uuid ( RW): <not in database>
suspend-SR-uuid ( RW): <not in database>
VCPUs-params (MRW): weight: 256
VCPUs-max ( RW): 4
VCPUs-at-startup ( RW): 4
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; cores-per-socket: 2; videoram: 8; hpet: true; secureboot: false; device-model: qemu-upstream-compat; 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; export; clone; copy
current-operations (SRO):
blocked-operations (MRW): destroy: false; pause: false; clean_shutdown: false; clean_reboot: false; hard_reboot: false; (unknown operation): true
allowed-VBD-devices (SRO): 0; 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): 0; 1; 2; 3; 4; 5; 6
possible-hosts ( RO):
domain-type ( RW): hvm
current-domain-type ( RO): unspecified
HVM-boot-policy ( RW): BIOS order
HVM-boot-params (MRW): order: c; firmware: bios
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-00000001-001c07ab-00000000-00000000-00001000-9c000400-00000000-00000000-00000000-00000000-00000000
last-boot-record ( RO): ''
resident-on ( RO): <not in database>
affinity ( RW): c23b5106-7728-4548-ad0d-21d241c2d683
other-config (MRW):
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): 19700101T00:00:00Z
install-time ( RO): 19700101T00:00:00Z
VCPUs-number ( RO): 0
VCPUs-utilisation (MRO):
os-version (MRO): name: Ubuntu 20.04.1 LTS; uname: 5.4.0-58-generic; distro: ubuntu; major: 20; minor: 04
PV-drivers-version (MRO): major: 8; minor: 1; micro: 50; build: 1
PV-drivers-up-to-date ( RO) [DEPRECATED]: false
memory (MRO):
disks (MRO):
VBDs (SRO): 79767011-4c15-481d-0f39-e34ae8b2cb6f
networks (MRO): 1/ipv6/0: fe80::fc8c:caff:fe64:9c9c; 1/ip: 172.26.13.106; 1/ipv4/0: 172.26.13.106
PV-drivers-detected ( RO): false
other (MRO): platform-feature-multiprocessor-suspend: 1; has-vendor-device: 0; feature-suspend: 1; feature-poweroff: 1; feature-reboot: 1; feature-vcpu-hotplug: 1; feature-balloon: 1
live ( RO): true
guest-metrics-last-updated ( RO): 20201212T14:26:22Z
can-use-hotplug-vbd ( RO): unspecified
can-use-hotplug-vif ( RO): unspecified
cooperative ( RO) [DEPRECATED]: true
tags (SRW): ubuntu, linux, apmgestio
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): ubuntu-20.04
bios-strings (MRO): bios-vendor: Xen; bios-version: ; system-manufacturer: Xen; system-product-name: HVM domU; system-version: ; system-serial-number: ; baseboard-manufacturer: ; baseboard-product-name: ; baseboard-version: ; baseboard-serial-number: ; baseboard-asset-tag: ; baseboard-location-in-chassis: ; enclosure-asset-tag: ; hp-rombios: ; oem-1: Xen; oem-2: MS_VM_CERT/SHA1/bdbeb6e0a816d43fa6d3fe8aaef04c2bad9d3e3d
[11:40 monitor ~]#
and
[11:40 monitor ~]# xe vm-param-clear param-name=blocked-operations uuid=aa43730c-b242-7a11-c359-bc13fa509320
The value given is invalid
field: blocked_operation
value: (unknown operation)
Hello,
XCP-ng 8.2.0
I have this template:
[11:15 monitor ~]# xe template-list uuid=aa43730c-b242-7a11-c359-bc13fa509320
uuid ( RO) : aa43730c-b242-7a11-c359-bc13fa509320
name-label ( RW): ELIMINAR
name-description ( RW):
[11:16 monitor ~]# xe template-uninstall template-uuid=aa43730c-b242-7a11-c359-bc13fa509320 force=true
The following items are about to be destroyed
VM : aa43730c-b242-7a11-c359-bc13fa509320 (ELIMINAR)
You attempted an operation that was explicitly blocked (see the blocked_operations field of the given object).
ref: aa43730c-b242-7a11-c359-bc13fa509320 (ELIMINAR)
code: true
[11:16 monitor ~]#
How can I delete it? Can't be deleted from XenCenter either. Also:
[11:31 monitor ~]# xe template-param-get uuid=aa43730c-b242-7a11-c359-bc13fa509320 param-name=blocked-operations
pause: false; clean_shutdown: false; clean_reboot: false; hard_reboot: false; destroy: false; (unknown operation): true
Thanks.
@julien-f said in Task list enhancement:
We don't to do special cases for some operations in XO 5, we'll revisit this in XO 6 which will bring the notion of XO tasks in addition to XAPI tasks.
But we'll probably display the elapsed and estimated duration of the task though
Regarding previous tasks, why do you need to hide some of them? How do you use these previous tasks?
Hello Julien,
Well, it's not really that I use them. It's just that being so filled with information not useful most of the times, it's quite unusable (with all due respect for your great job). Example of what for? To see how much it lasted an already finished VM moving/copy operation.
Displaying elapsed (and estimated, and I know this won't be always 100% accurante, but will be under normal circumstandes tho) would be great. After all, knowing the size of the object that it's being copied/moved, you can always extrapolate how much is remaining knowing how much it's lasting at any given moment.
Thanks!
Hello,
It would be great adding 2 items to the "Task" part:
Size/Destination of the VDI when moving. As of now, the shown information is:
Pool Name
VDI Name - SR Size
VM Name (Host)
What I propose is:
Pool Name
VDI Name - VDI Size
Origin SR (Size) -> Destination SR (Size)
VM Name (Host)
I guess something similar could be applied to a VDI copy operation.
Elapsed time in the task. This is shown in XenCenter and XO should be able to show it also. Sometimes is really useful when you're performing migration tasks and need to extrapolate elapsed time in certain tasks.
Also, the "Previous tasks" part, it's quite clogged with unuseful (99.99% of the times) information like:
all of them items that only show the host where they are occurring (except "SR.scan" which shows which SR is being scanned) and nothing else. Maybe those can be useful to debug some situation, but not for a daily working mode. I don't know.. maybe with some filters where those tasks would be hidden by default?
To me, a definition of "Task" is something started on-demand, and not internal operations of Xen.
Thanks for the great job
Hello,
I've made a huge cleanup of useless default templates. But XO still list every single one of them. I've tried disconnect/connect the server, but the deleted templates are still there, and are shown as existing templates when creating a new VM.
The templates are not shown anymore in XenCenter.
How can I refresh the template list?
Thanks.