Re: [libvirt] [PATCH 3/3] qemuCaps: Disable memdev for rhel6.5.0 machine type

On Fri, Feb 13, 2015 at 02:29:49PM +0000, Daniel P. Berrange wrote: >On Thu, Feb 12, 2015 at 04:09:40PM +0100, Michal Privoznik wrote: >>Well, after [1] qemu doesn't understand '-object memory-backend-ram' >>nor '-object memory-backend-file'. Make sure we remove that >>capabilities from our internal list temporarily, so the qemu command >>line is constructed in correct way. >> >>1: https://bugzilla.redhat.com/show_bug.cgi?id=1170093 >> >>Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; >>--- >> src/qemu/qemu_capabilities.c | 10 ++++--- >> .../qemuxml2argv-numatune-memnode-rhel650.args | 7 +++++ >> .../qemuxml2argv-numatune-memnode-rhel650.xml | 31 ++++++++++++++++++++++ >> tests/qemuxml2argvtest.c | 4 +++ >> 4 files changed, 49 insertions(+), 3 deletions(-) >> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnode-rhel650.args >> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnode-rhel650.xml >> >>diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c >>index 233449b..940f070 100644 >>--- a/src/qemu/qemu_capabilities.c >>+++ b/src/qemu/qemu_capabilities.c >>@@ -3510,6 +3510,11 @@ bool virQEMUCapsIsValid(virQEMUCapsPtr qemuCaps) >> return sb.st_ctime == qemuCaps->ctime; >> } >> >>+static virQEMUCapsFlags virQEMUCapsMachineRHEL650Filter[] = { >>+ /* For some reason, rhel6.5.0 machine type doesn't understand memdev. */ >>+ QEMU_CAPS_OBJECT_MEMORY_RAM, >>+ QEMU_CAPS_OBJECT_MEMORY_FILE, >>+}; >> >> struct virQEMUCapsMachineTypeFilter { >> const char *machineType; >>@@ -3518,9 +3523,8 @@ struct virQEMUCapsMachineTypeFilter { >> }; >> >> static const struct virQEMUCapsMachineTypeFilter virQEMUCapsMachineFilter[] = { >>- /* { "blah", virQEMUCapsMachineBLAHFilter, >>- ARRAY_CARDINALITY(virQEMUCapsMachineBLAHFilter) }, */ >>- { "", NULL, 0 }, >>+ { "rhel6.5.0", virQEMUCapsMachineRHEL650Filter, >>+ ARRAY_CARDINALITY(virQEMUCapsMachineRHEL650Filter)}, >> }; > >FWIW, I'd consider this to be something that RHEL downstream RPMs should >carry, not for upstream. > I'm a bit hesitating on this one. Both have pros and cons. I'd vote for upstream libvirt working everywhere it can and since the difference here is not a feature difference, but a bug and the machine type says clearly "RHEL", it seems like a better option to have it upstream as well. Any concerns as to why this should be downstream only?