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

Martin Kletzander mkletzan at redhat.com
Fri Feb 20 11:01:58 UTC 2015


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 at redhat.com>
>> ---
>>  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 at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150220/768a35f7/attachment-0001.sig>


More information about the libvir-list mailing list