Quoting Richard Laager (<email address hidden>):
> Public bug reported:
Thanks for reporting and looking into this bug.
> On Ubuntu Trusty, with libvirt 1.2.2, libvirt cannot start guests on NUMA node 1 (probably any node other than 0):
> $ virsh start pen2.office.wiktel.com
> error: Failed to start domain pen2.office.wiktel.com
> error: internal error: process exited while connecting to monitor: kvm_init_vcpu failed: Cannot allocate memory
>
> This worked on Ubuntu Precise with libvirt 0.9.8. Rebuilding libvirt
> 1.2.8 from vivid on Trusty works. It boots, and I've verified it
> allocates the memory from the correct NUMA node. Bisecting using
> released libvirt versions narrows it down to broken on 1.2.6 and working
> on 1.2.7.
>
> There were a number of NUMA changes in 1.2.7, so it's not immediately
> clear which commit may be causing this. And it may take more than one
> commit being cherry-picked to address this.
>
> So before I spend any more time bisecting, I'd like to know how you'd
> like to proceed on this. For example, if you just want to SRU libvirt
> 1.2.8 into Trusty, I won't bother narrowing it down further.
Unfortunately we can't just SRU 1.2.8 into Trusty. Hopefully the
actual fix will come down to a few patches we can cherrypick.
Quoting Richard Laager (<email address hidden>):
> Public bug reported:
Thanks for reporting and looking into this bug.
> On Ubuntu Trusty, with libvirt 1.2.2, libvirt cannot start guests on NUMA node 1 (probably any node other than 0): wiktel. com wiktel. com
> $ virsh start pen2.office.
> error: Failed to start domain pen2.office.
> error: internal error: process exited while connecting to monitor: kvm_init_vcpu failed: Cannot allocate memory
>
> This worked on Ubuntu Precise with libvirt 0.9.8. Rebuilding libvirt
> 1.2.8 from vivid on Trusty works. It boots, and I've verified it
> allocates the memory from the correct NUMA node. Bisecting using
> released libvirt versions narrows it down to broken on 1.2.6 and working
> on 1.2.7.
>
> There were a number of NUMA changes in 1.2.7, so it's not immediately
> clear which commit may be causing this. And it may take more than one
> commit being cherry-picked to address this.
>
> So before I spend any more time bisecting, I'd like to know how you'd
> like to proceed on this. For example, if you just want to SRU libvirt
> 1.2.8 into Trusty, I won't bother narrowing it down further.
Unfortunately we can't just SRU 1.2.8 into Trusty. Hopefully the
actual fix will come down to a few patches we can cherrypick.