[libvirt] [PATCH] qemu: Only use memory-backend-file with NUMA if needed

[Martin Kletzander]

On Wed, Sep 28, 2016 at 12:00:22PM +1000, Sam Bobroff wrote:
>On Fri, Sep 23, 2016 at 03:20:56PM +0200, Martin Kletzander wrote:
>> If this reminds you of a commit message from around a year ago, it's
>> 41c2aa729f0af084ede95ee9a06219a2dd5fb5df and yes, we're dealing with
>> "the same thing" again.  Or f309db1f4d51009bad0d32e12efc75530b66836b and
>> it's similar.
>>
>> There is a logic in place that if there is no real need for
>> memory-backend-file, qemuBuildMemoryBackendStr() returns 0.  However
>> that wasn't the case with hugepage backing.  The reason for that was
>> that we abused the 'pagesize' variable for storing that information, but
>> we should rather have a separate one that specifies whether we really
>> need the new object for hugepage backing.  And that variable should be
>> set only if this particular NUMA cell needs special treatment WRT
>> hugepages.
>>
>> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372153
>>
>> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>
>Hi Martin,
>
>I tested your patch and it works but it seems to make the snapshot/migration
>information incompatible with the current master code. e.g. after applying the
>patch I can't load a snapshot that was created before applying the patch
>(obviously only for a guest configuration that is affected by the patch). The
>error I get is this:
>
>$ virsh snapshot-revert tmp --snapshotname 1475026515
>error: operation failed: Unknown ramblock "/objects/ram-node0", cannot accept migration
>error while loading state for instance 0x0 of device 'ram'
>Error -22 while loading VM state
>
>Presumably this is caused by the same change that fixes some other migrations,
>but is this case a problem?
>

Yes, that's the problem.  But since we cannot know which was the
previous notation used, we need to pick one.  And previously we picked
the one that works with most QEMUs, even the old ones, unless we need
the new notation for some setting.  That is mostly for the migration (or
save/restore, which is basically the same thing) to work, even though it
looks like we're breaking it due to that.  That's why I will back-port
this to older maintenance branches so that we have it working across all
versions.  Some saves will still not be working, but there is no way how
to make everything work (due to the reason described in 2nd sentence),
so I'm making it work for everything from now on (no matter which
version), plus everything before the patch that "broke" it.

>Cheers,
>Sam.
>> ---
>>
>> Notes:
>>     This fixes migration from older libvirts.  By "older", I mean
>>     pre-(circa-)1.2.7, also in some cases pre-1.2.11, in some other cases
>>     pre-v1.2.20.  It's pretty messy.  It could be back-ported as far as it's
>>     easy to do.
>>

Using just a few words I tried to describe that here ^^.  Any of those
explanations might be hard to follow due to -ENOCOFFEE, sorry if that's
the case =)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160929/3604ecc1/attachment-0001.sig>