On Wed, Nov 28, 2018, 12:02 Milan Zamazal <[email protected] wrote:

> Nir Soffer <[email protected]> writes:
>
> > On Tue, Nov 27, 2018 at 4:44 PM Daniel Erez <[email protected]> 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 <[email protected]>
> wrote:
> >>
> >>> Nir Soffer <[email protected]> writes:
> >>>
> >>> > On Mon, Nov 26, 2018 at 10:15 PM Nir Soffer <[email protected]>
> 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.
>

Cool, we will wait for proper fix then.


> > 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
>
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/[email protected]/message/RQGQBXXNJVEGDFPOOYPWG5WTDVKLEALO/

Reply via email to