specific case, changing the QEMU
command line from "-mem-prealloc -mem-path=..." (which cannot
specify NUMA policy) to "-object memory-backend-file ..." (which can).
Note: This is not visible to the guest and does not appear to create
a migration incompatibility.
Signed
On Tue, Oct 25, 2016 at 02:13:07PM +0200, Martin Kletzander wrote:
> On Tue, Oct 25, 2016 at 01:10:23PM +1100, Sam Bobroff wrote:
> >On Tue, Oct 18, 2016 at 10:43:31PM +0200, Martin Kletzander wrote:
> >>On Mon, Oct 17, 2016 at 03:45:09PM +1100, Sam Bobroff wrote:
> >>
On Tue, Oct 18, 2016 at 10:43:31PM +0200, Martin Kletzander wrote:
> On Mon, Oct 17, 2016 at 03:45:09PM +1100, Sam Bobroff wrote:
> >On Fri, Oct 14, 2016 at 10:19:42AM +0200, Martin Kletzander wrote:
> >>On Fri, Oct 14, 2016 at 11:52:22AM +1100, Sam Bobroff wrote:
> >>
On Fri, Oct 14, 2016 at 10:19:42AM +0200, Martin Kletzander wrote:
> On Fri, Oct 14, 2016 at 11:52:22AM +1100, Sam Bobroff wrote:
> >On Thu, Oct 13, 2016 at 11:34:43AM +0200, Martin Kletzander wrote:
> >>On Thu, Oct 13, 2016 at 11:34:16AM +1100, Sam Bobroff wrote:
> >>
On Thu, Oct 13, 2016 at 11:34:43AM +0200, Martin Kletzander wrote:
> On Thu, Oct 13, 2016 at 11:34:16AM +1100, Sam Bobroff wrote:
> >On Wed, Oct 12, 2016 at 10:27:50AM +0200, Martin Kletzander wrote:
> >>On Wed, Oct 12, 2016 at 03:04:53PM +1100, Sam Bobroff wrote:
> >>
On Wed, Oct 12, 2016 at 09:48:07AM +0200, Peter Krempa wrote:
> On Wed, Oct 12, 2016 at 15:04:53 +1100, Sam Bobroff wrote:
> > At the moment, guests that are backed by hugepages in the host are
> > only able to use policy to control the placement of those hugepages
> > on a
On Wed, Oct 12, 2016 at 10:27:50AM +0200, Martin Kletzander wrote:
> On Wed, Oct 12, 2016 at 03:04:53PM +1100, Sam Bobroff wrote:
> >At the moment, guests that are backed by hugepages in the host are
> >only able to use policy to control the placement of those hugepages
> >
specific case, changing the QEMU
command line from "-mem-prealloc -mem-path=..." (which cannot
specify NUMA policy) to "-object memory-backend-file ..." (which can).
Note: This is not visible to the guest and does not appear to create
a migration incompatibility.
Signed
On Tue, Oct 04, 2016 at 11:28:15AM +0200, Martin Kletzander wrote:
> On Tue, Oct 04, 2016 at 02:34:57PM +1100, Sam Bobroff wrote:
> >On Mon, Oct 03, 2016 at 04:27:25PM +0200, Martin Kletzander wrote:
> >>On Mon, Aug 01, 2016 at 02:01:22PM +1000, Sam Bobroff wrote:
>
On Mon, Oct 03, 2016 at 04:27:25PM +0200, Martin Kletzander wrote:
> On Mon, Aug 01, 2016 at 02:01:22PM +1000, Sam Bobroff wrote:
> >Hi libvirt people,
> >
> >I've been looking at a (probable) bug and I'm not sure how to progress. The
> >situation is a bit c
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.
Hi all,
I've found that if I create a QEMU guest that:
(a) is backed by host hugepages and
(b) specifies a host NUMA memory placement policy
... then the NUMA policy (b) is ignored. It's even possible to start the guest
if the policy specifies that memory must come from non-existant host nodes.
Hi libvirt people,
I've been looking at a (probable) bug and I'm not sure how to progress. The
situation is a bit complicated and involves both QEMU and libvirt (and I think
it may have been looked at already) so I would really appreciate some advice on
how to approach it. I'm using a pretty recen
On 14/08/14 20:14, Ján Tomko wrote:
> On 08/14/2014 11:52 AM, Michal Privoznik wrote:
>> On 14.08.2014 10:41, Ján Tomko wrote:
>>> Also add qemuDomainChangeGraphicsPasswords,
>>> qemuProcessVerifyGuestCPU and qemuProcessInitPCIAddresses.
>>>
>>> Replace tabs by spaces.
>>> ---
>>> I'll do some test
values in several places that are incorrect.
This patch passes the required asyncJob value around and prevents
the warnings as well as any issues that the warnings may be referring
to.
Signed-off-by: Sam Bobroff
---
v2:
* Handle failures from qemuDomainObjEnterMonitorAsync() rather than
ign
On 02/08/14 00:04, Ján Tomko wrote:
> On 08/01/2014 03:12 AM, Sam Bobroff wrote:
>> On 30/07/14 01:52, Ján Tomko wrote:
>>> On 07/29/2014 02:41 AM, Sam Bobroff wrote:
>>>> During a QEMU live migration several warning messages about job
>>>> handling cou
On 30/07/14 01:52, Ján Tomko wrote:
> On 07/29/2014 02:41 AM, Sam Bobroff wrote:
>> During a QEMU live migration several warning messages about job
>> handling could be written to syslog on the destination host:
>>
>> "entering monitor without asking for a ne
values in several places that are incorrect.
This patch passes the required asyncJob value around and prevents
the warnings as well as any issues that the warnings may be referring
to.
Signed-off-by: Sam Bobroff
---
src/qemu/qemu_domain.c| 5 +++--
src/qemu/qemu_domain.h| 2 +-
On 17/07/14 17:54, Ján Tomko wrote:
> On 07/17/2014 08:51 AM, Jiri Denemark wrote:
>> On Thu, Jul 17, 2014 at 13:29:52 +1000, Sam Bobroff wrote:
>>> On 17/07/14 12:50, Eric Blake wrote:
>>>> On 07/16/2014 07:52 PM, Sam Bobroff wrote:
>>>>> Hello every
On 17/07/14 12:50, Eric Blake wrote:
> On 07/16/2014 07:52 PM, Sam Bobroff wrote:
>> Hello everyone,
>
> [Can you configure your mailer to wrap long lines?]
[No problem, done.]
>> After performing a migration, the syslog often contains several
>> messages like this:
&
Hello everyone,
After performing a migration, the syslog often contains several messages like
this:
"This thread seems to be the async job owner; entering monitor without asking
for a nested job is dangerous"
The message makes it sound as if the user has done something dangerous but,
after lo
21 matches
Mail list logo