Re: cpuset / numa and qemu in TCG mode

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

 



On Tue, May 12, 2015 at 05:27:34PM +1000, Tony Breeds wrote:
On Mon, May 11, 2015 at 01:14:58PM +0200, Martin Kletzander wrote:

Determining this by version might not be reliable, but more
importantly working around bug in underlying software is something
that shouldn't be done at all IMHO.  Let the maintainers backport
whatever needs to be done.

I agree with you in an ideal world but there are times when we do need
to add work arounds in $project_x to work around issues in $project_y.

>Ther nova side will be pretty easy regardless.
>
>I'd say the best solution would be to back port the 'fix' but that seems like a
>lot of effort given the number of distros and libvirt versions potentiall
>involved.
>

If you want the fix to be distro-agnostic, there's nothing easier than
back-porting the fix into our upstream maintenance branches.  Those
should make the life of distro maintainers easy (although it looks
like not many distros use it).

And this is part of the problem.  If I understand correctly Ubuntu cloud-archive
is using libvirt 1.2.12 which is *NOT* a maintenance release so that leaves us
with doing an additional backport to 1.2.12 and getting the cloud-archive team
to take it[1]  or Adding a hack to nova.  And that's just Ubuntu It's hard to
say for sure that some vendor isn't running libvirt 1.2.12 also.

Having said that I'm not sure which commit(s) are those that need to
be back-ported.  Having known your libvirt version, it shouldn't be
too hard looking for the differences and finding the right commit.
When back-porting request is made on the list, it is usually acted
upon.  If you can't find the exact commit, let me know and I'll do my
best to help.

So a git bisect points at:
---
commit a103bb105c0c189c3973311ff1826972b5bc6ad6
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Tue Feb 10 15:59:57 2015 +0000

   qemu: fix setting of VM CPU affinity with TCG
---

A small amount of reading implies to me that we'd be looking at backporting
a103bb105c0c189c3973311ff1826972b5bc6ad6 to any maintenance branch that contains
b07f3d821dfb11a118ee75ea275fd6ab737d9500.  Which I think is 1.2.13 only, but I
could be wrong.


1.2.13 has the commit already in the release and 1.2.12-maint has it
as a first back-port right after release.  The problem is that there
was no maintenance release of 1.2.12 yet.  Maybe they would use
1.2.12.1 if it existed.

I Cc'd Guido as an upstream debian maintainer, maybe he'll have some
insights.  @Guido: would it help if we created a maintenance release
from the v1.2.12-maint branch?  Or is the only thing missing the fact
that the launchpad bug is not moved to libvirt?

If you don't beat me to it I'll request that backport to 1.2.13 *and* ask the
Ubuntu guys to take it as well.

I have to admit I'm still in 2 minds on the nova side.  Adding a wart to the
libvirt driver for this specific bug for distros/vendors that are using 1.2.12
seems a bit gross but ....

Daniel what do you think?

Yours Tony.

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