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

[Ashijeet Acharya]

On Wed, Jan 25, 2017 at 4:46 PM, Juan Quintela <address@hidden> wrote:
> "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?

Yes, bitmap_new(0) aborts in this case. The only way I see to fix this
would be to error out rather than simply crashing?
Adding a migration blocker is one way too; although I am not aware of
the use cases of a "none" machine.

Ashijeet
>
> Later, Juan.