[Top][All Lists]

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

Re: [Qemu-devel] migration: QEMU aborts migration of "none" machine

From: Juan Quintela
Subject: Re: [Qemu-devel] migration: QEMU aborts migration of "none" machine
Date: Wed, 25 Jan 2017 12:16:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

"Daniel P. Berrange" <address@hidden> wrote:
> On Wed, Jan 25, 2017 at 11:53:06AM +0100, Thomas Huth wrote:
>> On 25.01.2017 11:01, Ashijeet Acharya wrote:
>> > Hi Thomas,
>> > 
>> > I was able to reproduce the bug you encountered while trying to migrate
>> > a "none" machine.
>> > 
>> > After digging deep and debugging the problem with gdb, I found that
>> > bitmap_new() is the function that crashes qemu as it always has
>> > zero bits being passed to it.
>> > 
>> > I had a discussion with Dave on the IRC yesterday and he suggested the
>> > reason of crash being the absence of RAM ( since machine is "none")
>> > while attempting the migration.
>> > 
>> > I am not sure what the ideal solution will be in this case; Do any of
>> > the maintainers have any suggestions or even a starting point which I
>> > can ponder upon?
>> I'm not that familiar with the migration code either, but maybe you
>> could simply check for last_ram_offset() == 0 at the beginning of
>> ram_save_setup() and return with an error in that case?
> Do we actually need/want migration to succeed when RAM is 0 or vCPU
> count is 0 ?  If not, then we could just register a migration blocker
> during machine init

Only use that I can see for that is to test that we have setup things
correctly, but for that we could also use an stopped machine.  So, I
don't know if it really makes sense.

If the only problem is that bitmap_new(0) returns 0, we can try to fix
that, no?

Later, Juan.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]