Nir Soffer <nsoffer@redhat.com> writes:

> 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/3ecbac95cd2a02ba5e2f98c625386ec12c8bbdac
>>
>> 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?

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