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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
---
 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?

Regards,
Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

Attachment: pgp5N9qxfT1s0.pgp
Description: PGP signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]