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? 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/NCETS25IMURIRP2HV3CE5UHIFAMOIR36/
