@Pilow tags can work and the path to them is much more succinct. Thanks!

@Pilow tags can work and the path to them is much more succinct. Thanks!

One more question!

How can I add the contents of that field to the output?

This

curl -k -b authenticationToken=$tk "https://xoa.pc.scharp.org/rest/v0/vms?filter=other:XenCenter.CustomFields.export_vga:"*"&fields=name_label,other:XenCenter.CustomFields.export_vga"

doesn't work. I did double check that multiple fields are comma delimited, I can set fields to fields=name_label,power_state

I'm assuming this is something weird about properly quoting and escaping different parts of the call. For example, thee above example is actually passing three chunks because of that quoted * within the quotes. But if I try to make it make more sense it stops working at all.

OK, this works:

curl -k -b authenticationToken=$tk "https://xoa.pc.scharp.org/rest/v0/vms?filter=other:XenCenter.CustomFields.export_vga:*&fields=name_label,other:XenCenter.CustomFields.export_vga,power_state"

and returns the name and power state but not the custom field

OK, I didn't expect different results but I get the same behavior in python using the requests module.

@Danp said in filter for custom field:

other:XenCenter.CustomFields.export_vga:"true"

I think I had something either very close to that or even exactly that except I didn't quote "true." Which makes sense as "true" is just a string, not a bool.

This works:

curl -k -b authenticationToken=$tk "https://xoa.pc.scharp.org/rest/v0/vms?filter=other:XenCenter.CustomFields.export_vga:"true"&fields=name_label"

Thank you!

I'm trying to get a list of VMs that have a "true" value for a custom field. The doc at https://docs.xen-orchestra.com/restapi even describes an example as "With custom fields:" but the example following (and all the other examples) make no mention of filters.

The custom field is called "export_vga" and I can see it if I query fields=* under "other" but can't filter on it using its short name, nor for XenCenter.CustomFields.export_vga or other.XenCenter.CustomFields.export_vga or other:XenCenter.CustomFields.export_vga (I'm pretty much trying to find a working curl command by trial and error at this point).

This returns every VM and every field:

curl -k -b authenticationToken=$tk "https://xoa.pc.scharp.org/rest/v0/vms?fields=*" | less

including the lines:

"other": {
      "XenCenter.CustomFields.export_vga": "true",

I can filter on other fields:

curl -k -b authenticationToken=$tk "https://xoa.pc.scharp.org/rest/v0/vms?filter=name_label:xoa&fields=name_label" 
[
  {
    "name_label": "xoa",
    "href": "/rest/v0/vms/73018610-8d50-4685-5617-f15e0d09fa5"
  }
]

grateful for any guidance

Resolved. Patched the rest of the hosts. Restarted all the toolstacks for good measure. I can move the master role now, and deploy new VMs.

@Danp To answer your earlier question about the state of the patched hosts, three hosts are currently fully patched with one of them as the current pool master. I've tried to promote both of the other two with the same "Cannot restore" error.

For the sake of completeness I just tried promoting one of the non-patched hosts. Same error.

And I'm still unable to deploy a new VM ("NOT_SUPPORTED_DURING_UPGRADE").

@Danp I believe so. I was not driving at the time.

@Danp I was attempting to change the host as we'll be retiring the current master. In any case if I can't promote another host this would suggest our production pool is otherwise wedged. The same for not being able to create a new VM.

@Danp rebooted it again to be sure. No change, I still get the first error

One of our engineers who should know better patched a host in our 8.3.0 pool before patching the master and then tried to promote it. Later they emptied, patched and rebooted the current master. I'm not sure exactly what else they did in their flailing before I stepped in a few hours ago.

Right now the current master is patched but I'm unable to change the master, I get an error "Cannot restore on this host because it was saved on an incompatible version." I tried restarting the toolstack on every host in the pool and the next attempt returned a different error "Cannot forward messages because the host cannot be contacted. The host may be switched off or there may be network connectivity problems" but that may be just because the dust hadn't settled from the toolstack restarts yet? I waited ten minutes and tried again and got the first error again.

I could continue emptying, patching, rebooting the rest of the hosts but I don't want to leave this pool in an unknown state and find out later on things are broken under the hood.

I'd be grateful for any guidance; this is our production pool and if I'm not confident it's healthy we'll start the painful process of creating a new pool and slow cross-pool VM migrations.

Update: I also can't create new VMs.