[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.