I updated 2 Fedora 28 hosts today, getting new ovirt-master-release.rpm, which exposes new virt-preview repo providing libvirt 4.9 and qemu 3.1. After the update, connecting with engine master (built few week ago) fail with: 2018-11-26 22:07:51,702+02 WARN [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-94) [] Unexpected return value: Status [code=-32603, message=Internal JSON-RPC error: {'reason': "[Errno 2] No such file or directory: '/usr/share/libvirt/cpu_map.xml'"}] Looks like contents of /usr/share/libvirt/ is different now: $ ls -1 /usr/share/libvirt/cpu_map/*.xml | head /usr/share/libvirt/cpu_map/index.xml /usr/share/libvirt/cpu_map/ppc64_POWER6.xml /usr/share/libvirt/cpu_map/ppc64_POWER7.xml /usr/share/libvirt/cpu_map/ppc64_POWER8.xml /usr/share/libvirt/cpu_map/ppc64_POWER9.xml /usr/share/libvirt/cpu_map/ppc64_POWERPC_e5500.xml /usr/share/libvirt/cpu_map/ppc64_POWERPC_e6500.xml /usr/share/libvirt/cpu_map/ppc64_vendors.xml /usr/share/libvirt/cpu_map/x86_486.xml /usr/share/libvirt/cpu_map/x86_athlon.xml

Nir Soffer <nsoffer(a)redhat.com&gt; writes: > On Mon, Nov 26, 2018 at 10:15 PM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: > >> I updated 2 Fedora 28 hosts today, getting new ovirt-master-release.rpm, >> which exposes new virt-preview repo providing libvirt 4.9 and qemu 3.1. >> >> After the update, connecting with engine master (built few week ago) fail >> with: >> >> 2018-11-26 22:07:51,702+02 WARN >> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] >> (EE-ManagedThreadFactory-engineScheduled-Thread-94) [] Unexpected return >> value: Status [code=-32603, message=Internal JSON-RPC error: {'reason': >> "[Errno 2] No such file or directory: '/usr/share/libvirt/cpu_map.xml'"}] >> >> Looks like contents of /usr/share/libvirt/ is different now: >> >> $ ls -1 /usr/share/libvirt/cpu_map/*.xml | head >> /usr/share/libvirt/cpu_map/index.xml >> /usr/share/libvirt/cpu_map/ppc64_POWER6.xml >> /usr/share/libvirt/cpu_map/ppc64_POWER7.xml >> /usr/share/libvirt/cpu_map/ppc64_POWER8.xml >> /usr/share/libvirt/cpu_map/ppc64_POWER9.xml >> /usr/share/libvirt/cpu_map/ppc64_POWERPC_e5500.xml >> /usr/share/libvirt/cpu_map/ppc64_POWERPC_e6500.xml >> /usr/share/libvirt/cpu_map/ppc64_vendors.xml >> /usr/share/libvirt/cpu_map/x86_486.xml >> /usr/share/libvirt/cpu_map/x86_athlon.xml >> > > Looks like vdsm is not ready for this change: Hm, so libvirt changed from a file to a directory structure. The corresponding Vdsm code is apparently virt, so it would be on me or Tomasz. In order to fix it, it must be scheduled to some sprint. Adding Ryan. > $ git grep cpu_map.xml > lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' > tests/Makefile.am: cpu_map.xml \ > tests/caps_test.py: 'cpu_map.xml') > tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml > vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml > vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be found > in /usr/share/libvirt/cpu_map.xml. > [nsoffer@lean vdsm (master)]$ git grep cpu_map > lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' > lib/vdsm/machinetype.py: cpu_map = ET.fromstring(xml.read()) > lib/vdsm/machinetype.py: arch_elements = cpu_map.findall('arch') > tests/Makefile.am: cpu_map.xml \ > tests/caps_test.py: 'cpu_map.xml') > tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml > vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml > vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be found > in /usr/share/libvirt/cpu_map.xml. > > And I cannot find any related patch on gerrit.

It has been changed as part of moving the data files into src/cpu_map: https://github.com/libvirt/libvirt/commit/3ecbac95cd2a02ba5e2f98c625386ec... So as a quick workaround, copying the old 'cpu_map.xml' file into '/usr/share/libvirt' does the trick :)

On Tue, Nov 27, 2018 at 3:01 PM Milan Zamazal <mzamazal(a)redhat.com&gt; wrote: > Nir Soffer <nsoffer(a)redhat.com&gt; writes: > > > On Mon, Nov 26, 2018 at 10:15 PM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: > > > >> I updated 2 Fedora 28 hosts today, getting new > ovirt-master-release.rpm, > >> which exposes new virt-preview repo providing libvirt 4.9 and qemu 3.1. > >> > >> After the update, connecting with engine master (built few week ago) > fail > >> with: > >> > >> 2018-11-26 22:07:51,702+02 WARN > >> > [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] > >> (EE-ManagedThreadFactory-engineScheduled-Thread-94) [] Unexpected > return > >> value: Status [code=-32603, message=Internal JSON-RPC error: {'reason': > >> "[Errno 2] No such file or directory: > '/usr/share/libvirt/cpu_map.xml'"}] > >> > >> Looks like contents of /usr/share/libvirt/ is different now: > >> > >> $ ls -1 /usr/share/libvirt/cpu_map/*.xml | head > >> /usr/share/libvirt/cpu_map/index.xml > >> /usr/share/libvirt/cpu_map/ppc64_POWER6.xml > >> /usr/share/libvirt/cpu_map/ppc64_POWER7.xml > >> /usr/share/libvirt/cpu_map/ppc64_POWER8.xml > >> /usr/share/libvirt/cpu_map/ppc64_POWER9.xml > >> /usr/share/libvirt/cpu_map/ppc64_POWERPC_e5500.xml > >> /usr/share/libvirt/cpu_map/ppc64_POWERPC_e6500.xml > >> /usr/share/libvirt/cpu_map/ppc64_vendors.xml > >> /usr/share/libvirt/cpu_map/x86_486.xml > >> /usr/share/libvirt/cpu_map/x86_athlon.xml > >> > > > > Looks like vdsm is not ready for this change: > > Hm, so libvirt changed from a file to a directory structure. The > corresponding Vdsm code is apparently virt, so it would be on me or > Tomasz. In order to fix it, it must be scheduled to some sprint. > > Adding Ryan. > > > $ git grep cpu_map.xml > > lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' > > tests/Makefile.am: cpu_map.xml \ > > tests/caps_test.py: 'cpu_map.xml') > > tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml > > vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml > > vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be > found > > in /usr/share/libvirt/cpu_map.xml. > > [nsoffer@lean vdsm (master)]$ git grep cpu_map > > lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' > > lib/vdsm/machinetype.py: cpu_map = ET.fromstring(xml.read()) > > lib/vdsm/machinetype.py: arch_elements = cpu_map.findall('arch') > > tests/Makefile.am: cpu_map.xml \ > > tests/caps_test.py: 'cpu_map.xml') > > tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml > > vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml > > vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be > found > > in /usr/share/libvirt/cpu_map.xml. > > > > And I cannot find any related patch on gerrit. >

Nir Soffer <nsoffer(a)redhat.com&gt; writes: > On Tue, Nov 27, 2018 at 4:44 PM Daniel Erez <derez(a)redhat.com&gt; wrote: > >> It has been changed as part of moving the data files into src/cpu_map: >> >> https://github.com/libvirt/libvirt/commit/3ecbac95cd2a02ba5e2f98c625386ec... >> >> So as a quick workaround, copying the old 'cpu_map.xml' file into >> '/usr/share/libvirt' does the trick :) >> >> On Tue, Nov 27, 2018 at 3:01 PM Milan Zamazal <mzamazal(a)redhat.com&gt; wrote: >> >>> Nir Soffer <nsoffer(a)redhat.com&gt; writes: >>> >>> > On Mon, Nov 26, 2018 at 10:15 PM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: >>> > >>> >> I updated 2 Fedora 28 hosts today, getting new >>> ovirt-master-release.rpm, >>> >> which exposes new virt-preview repo providing libvirt 4.9 and qemu 3.1. >>> >> >>> >> After the update, connecting with engine master (built few week ago) >>> fail >>> >> with: >>> >> >>> >> 2018-11-26 22:07:51,702+02 WARN >>> >> >>> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-94) [] Unexpected >>> return >>> >> value: Status [code=-32603, message=Internal JSON-RPC error: {'reason': >>> >> "[Errno 2] No such file or directory: >>> '/usr/share/libvirt/cpu_map.xml'"}] >>> >> >>> >> Looks like contents of /usr/share/libvirt/ is different now: >>> >> >>> >> $ ls -1 /usr/share/libvirt/cpu_map/*.xml | head >>> >> /usr/share/libvirt/cpu_map/index.xml >>> >> /usr/share/libvirt/cpu_map/ppc64_POWER6.xml >>> >> /usr/share/libvirt/cpu_map/ppc64_POWER7.xml >>> >> /usr/share/libvirt/cpu_map/ppc64_POWER8.xml >>> >> /usr/share/libvirt/cpu_map/ppc64_POWER9.xml >>> >> /usr/share/libvirt/cpu_map/ppc64_POWERPC_e5500.xml >>> >> /usr/share/libvirt/cpu_map/ppc64_POWERPC_e6500.xml >>> >> /usr/share/libvirt/cpu_map/ppc64_vendors.xml >>> >> /usr/share/libvirt/cpu_map/x86_486.xml >>> >> /usr/share/libvirt/cpu_map/x86_athlon.xml >>> >> >>> > >>> > Looks like vdsm is not ready for this change: >>> >>> Hm, so libvirt changed from a file to a directory structure. The >>> corresponding Vdsm code is apparently virt, so it would be on me or >>> Tomasz. In order to fix it, it must be scheduled to some sprint. >>> >> > The issue is we need Fedora 28 *now* to develop incremental backup > using libvirt upstream code + patches from libvirt developers. > > According to Daniel, installing manually the old cpu_map.mxl works - this > can be good enough for us for the next few weeks. > > But we need to ship this soon to users, so we need actual support in Fedora > 28 > soon. > > Dan suggested a quick hack, to include the latest version of cpu_map.xml in > vdsm, e.g. in /usr/share/vdsm/cpu_map.xml. We can use this file if the > libvirt > file does not exist. This can be a temporary solution that will allow > installing > vdsm on Fedora 28 without any manual steps. Would you accept a patch > doing this? I don't have problem with that if you need it right now and it is limited to Fedora. Depending on other circumstances, I may be able to make a fix this week.

> Real support for the new format seems to require: > - if /usr/share/libvirt/cpu_map.xml exists, use it > - else read /usr/share/libvirt/cpu_map/index.xml > - for each <include filename=.../>, read the filename and replace the > <include /> with the element in the file. > - finally, process the combined file with the existing code. > > Maybe there are existing tools that can process the <includes> in an easier > way. > > Nir