[libvirt] cpuset / numa and qemu in TCG mode

Thu May 14 07:01:06 UTC 2015

[Adding Cole to Cc as I forgot to do that before sending the mail]

On Thu, May 14, 2015 at 08:58:03AM +0200, Martin Kletzander wrote:
>On Wed, May 13, 2015 at 03:31:09PM +0000, Serge Hallyn wrote:
>>Quoting Guido Günther (agx at sigxcpu.org):
>>>On Tue, May 12, 2015 at 11:14:09AM +0200, Martin Kletzander wrote:
>>>> 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 at redhat.com>
>>>> >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?
>>
>>Thanks guys, I'm going to cherrypick that patch into vivid right now.  (It
>>should be in wily as that is 1.2.15).
>>
>>>Basically Ubuntu takes the version that is in Debian testing, unstable
>>>or experimental at time of their release and adds pathes. There's little
>>>to no sync unfortunately (except for the awesome efforts to sync the
>>>apparmor stuff)
>>>
>>>Debian itself is not using 1.2.12 anywhere. Current stable has 1.2.9 +
>>>maintenance patches (which I intend to switch over to the maintenance
>>>releases soonish and support hopefully Cole with these), oldstable has
>>>0.9.12.3 and unstable/sid has 1.2.15 (and will keep following the
>>>releases).
>>>
>>>I've added Serge since he might to jump onto 1.2.12.1 maintenance
>>>relasese.
>>
>>If you mean contributing by adding patches that we add to vivid, I'm
>>definately willing to do that.  Note that vivid has a pretty short
>>lifecycle so it wouldn't go on for very long.  If people are willing
>>to tag patches with '[1.2.12.1-maint]' on this list I'm willing to
>>support this longer.
>>
>
>Rather than tagging patches with -maint, we just back-port them
>straight into the maintenance branch.  If there are more distributions
>using the maintenance branch or would be if there was more review,
>etc., I'm sure we could come up with some solution to suit everyone
>(or majority at least).
>
>After patches are back-ported, Cole does a maintenance release which
>should make it even more easier (e.g. you don't want to follow up the
>list or the git repo) since the release announcement goes to
>libvirt-announce as with other releases.
>
>However, I'm not sure when Cole does those releases (if it's time-,
>commit- or random-based).  Anyway, as I said earlier, we should
>definitely come up with how to do this so it helps other maintainers
>out there.  I'm offering my help.
>
>>>I'm happy about any additional notifications for things that should go
>>>into distributions.
>>>
>>>Cheers,
>>> -- Guido
>>>
>>
>>Thanks!
>>
>>-serge


>--
>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: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150514/bd5dd714/attachment-0001.sig>