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

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

 



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

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 =)

Attachment: signature.asc
Description: Digital 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]