On Tue, Nov 27, 2018 at 4:44 PM Daniel Erez <derez@redhat.com> wrote:
It has been changed as part of moving the data files into src/cpu_map:
https://github.com/libvirt/libvirt/commit/3ecbac95cd2a02ba5e2f98c625386ec12c...
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@redhat.com> wrote:
Nir Soffer <nsoffer@redhat.com> writes:
On Mon, Nov 26, 2018 at 10:15 PM Nir Soffer <nsoffer@redhat.com> 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? 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