Hosts in Unassigned state after upgrading libvirt to 4.9
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 Do we have a fix for this? Nir
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: $ git grep cpu_map.xml lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' tests/Makefile.am: cpu_map.xml \ tests/caps_test.py: 'cpu_map.xml') tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be found in /usr/share/libvirt/cpu_map.xml. [nsoffer@lean vdsm (master)]$ git grep cpu_map lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' lib/vdsm/machinetype.py: cpu_map = ET.fromstring(xml.read()) lib/vdsm/machinetype.py: arch_elements = cpu_map.findall('arch') tests/Makefile.am: cpu_map.xml \ tests/caps_test.py: 'cpu_map.xml') tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be found in /usr/share/libvirt/cpu_map.xml. And I cannot find any related patch on gerrit.
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. Adding Ryan.
$ git grep cpu_map.xml lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' tests/Makefile.am: cpu_map.xml \ tests/caps_test.py: 'cpu_map.xml') tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be found in /usr/share/libvirt/cpu_map.xml. [nsoffer@lean vdsm (master)]$ git grep cpu_map lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' lib/vdsm/machinetype.py: cpu_map = ET.fromstring(xml.read()) lib/vdsm/machinetype.py: arch_elements = cpu_map.findall('arch') tests/Makefile.am: cpu_map.xml \ tests/caps_test.py: 'cpu_map.xml') tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be found in /usr/share/libvirt/cpu_map.xml.
And I cannot find any related patch on gerrit.
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.
Adding Ryan.
$ git grep cpu_map.xml lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' tests/Makefile.am: cpu_map.xml \ tests/caps_test.py: 'cpu_map.xml') tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be found in /usr/share/libvirt/cpu_map.xml. [nsoffer@lean vdsm (master)]$ git grep cpu_map lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' lib/vdsm/machinetype.py: cpu_map = ET.fromstring(xml.read()) lib/vdsm/machinetype.py: arch_elements = cpu_map.findall('arch') tests/Makefile.am: cpu_map.xml \ tests/caps_test.py: 'cpu_map.xml') tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be found in /usr/share/libvirt/cpu_map.xml.
And I cannot find any related patch on gerrit.
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
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/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?
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
On Wed, Nov 28, 2018, 12:02 Milan Zamazal <mzamazal@redhat.com wrote:
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/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?
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
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 :)
This seems like the last version of the file in libvirt repo: https://raw.githubusercontent.com/libvirt/libvirt/18cab54c3a0bc72390f2930068... Is this the file you tested?
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.
Adding Ryan.
$ git grep cpu_map.xml lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' tests/Makefile.am: cpu_map.xml \ tests/caps_test.py: 'cpu_map.xml') tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be found in /usr/share/libvirt/cpu_map.xml. [nsoffer@lean vdsm (master)]$ git grep cpu_map lib/vdsm/machinetype.py:CPU_MAP_FILE = '/usr/share/libvirt/cpu_map.xml' lib/vdsm/machinetype.py: cpu_map = ET.fromstring(xml.read()) lib/vdsm/machinetype.py: arch_elements = cpu_map.findall('arch') tests/Makefile.am: cpu_map.xml \ tests/caps_test.py: 'cpu_map.xml') tests/cpu_map.xml:<!-- Taken from /usr/share/libvirt/cpu_map.xml vdsm.spec.in:%{_datadir}/%{vdsm_name}/tests/cpu_map.xml vdsm_hooks/cpuflags/before_vm_start.py:guest OS. Feature names can be found in /usr/share/libvirt/cpu_map.xml.
And I cannot find any related patch on gerrit.
participants (3)
-
Daniel Erez -
Milan Zamazal -
Nir Soffer