9:49 p.m.
On Tue, Nov 27, 2018 at 4:44 PM Daniel Erez <derez(a)redhat.com> 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> wrote:
> Nir Soffer <nsoffer(a)redhat.com> writes:
>
> > On Mon, Nov 26, 2018 at 10:15 PM Nir Soffer <nsoffer(a)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