@olivierlambert New thread is here

It is difficult to know the source of the problem without more details from your logs. Can you run the following commands on your XCP-ng host and then attach the generated files here?

grep -A 15 -B 15 -i error /var/log/xensource.log/xensource > xensource.txt
grep -A 15 -B 15 -i exception /var/log/SMlog > smlog.txt
dmesg -T|grep -Eiv 'guest|capacity|promiscuous' > dmesg.txt

Hi @Tristis-Oris Have you tried this option on the secondary menu?

What OS are you running on the VMs? Do you have the guest tools installed on them?

@markxc I don't think this is possible yet with the REST API. However, you should be able to do it using xo-cli:

xo-cli vm.setBootOrder vm=<string> order=<string>

Hi,

There weren't any other errors / warnings just prior to the Feb 3 00:22:24 entries?

Have you tried using vhd-cli check to verify the VDI's integrity?

Dan

You have to remove some entries from the pool parameters. The first step is to pull the pool's other_config parameter --

[17:31 xcp-slnqfzrh ~]# xe pool-param-get uuid=63b7154a-1a6c-8642-525e-c6abb0acxxx  param-name=other-config
xo:clientInfo:579c9820-a9fc-5ff0-0065-6eca7813677f: {"lastConnected":1770075085319,"networkInterfaces":{"enX0":[{"address":"192.168.1.123","netmask":"255.255.255.0","family":"IPv4","mac":"66:04:08:97:5e:e8","internal":false,"cidr":"192.168.1.123/24"},{"address":"fe80::6404:8ff:fe97:5ee8","netmask":"ffff:ffff:ffff:ffff::","family":"IPv6","mac":"66:04:08:97:5e:e8","internal":false,"cidr":"fe80::6404:8ff:fe97:5ee8/64","scopeid":2}]}}; auto_poweron: true; memory-ratio-hvm: 0.25; memory-ratio-pv: 0.25

Then you need to remove this entry using this syntax --

xe pool-param-remove uuid=<pool_uuid> param-name=other-config param-key=xo:clientInfo:<vm_uuid>

This filter works in XOA --

other:XenCenter.CustomFields.export_vga:"true"

You can try this with curl --

curl -k -b authenticationToken=$tk "https://xoa.pc.scharp.org/rest/v0/vms?fields=name_label%2Cpower_state%2Cuuid&filter=other%3AXenCenter.CustomFields.export_vga%3A%22true%22"

@acebmxer said in ️ XO 6: dedicated thread for all your feedback!:

When creating new vm in XOv6 it does not set the correct number of cpu's....

I set 4 cpu's and after creation there is only 1. Also the ISO image is not mounted after creation.

Confirmed in my lab. I also noticed that I had to explicitly add a network adapter, which is a change from XO5.

@henri9813 said in VM metadata import fail & stuck:

I'm evacuating an host for update to another pool.

I'm unsure what you mean by this. Please provide additional details so that we can better understand the end goal.

• Are you trying to move the XCP-ng host to a different pool?
• Have all hosts been rebooted following after patching was performed?
• etc

@robertblissitt You can check /var/log/yum.log on the XCP-ng hosts to see when the updates were actually applied, but there isn't anything in a standard installation of XO / XCP-ng that would trigger an "automated" update of missing patches.

@tsukraw Your best option is to open a support ticket so that we can assist you on updating the XOA registration.

@Pilow said in xen-orchestra.com outages ?:

something in the way between me and them ?

This would be my suspicion.

@nikade I believe that you can still find the entries in the journalctl output.

The REST API supports exporting a VM in OVA format.

It sounds like you tried to switch the pool master to a host at a lower xapi level. Had the host that you designated as the new pool master already been patched?

It isn't clear why you are trying to change the master at this time. Can you explain? What is the status of the two hosts that have been patched and rebooted?

@randyrue Was the current master rebooted after being patched?

@MarcVdS The new ISO is already available. See this post for more details.

@DaleDibbadel said in Lost VMs disk after using new SR:

Brought in trunas, set a SR device: /dev/sda, rebooted Dell, now VMs wont start.

Please elaborate on the exact commands that you ran here. Also, you may want to provide the output from lsblk to provide some additional context.

Do you have a backup of your pool metadata?