Re: [Qemu-devel] Re: [CFR 6/10] cont command

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/16/2010 08:11 AM, Juan Quintela wrote:
> Anthony Liguori<aliguori@us.ibm.com>  wrote:
>    
>> cont
>> ----
>>
>> Resume emulation.
>>
>> Arguments: None.
>>
>> Example:
>>
>> ->  { "execute": "cont" }
>> <- { "return": {} }
>>      
> This is related to the commands, not QMP per se:
>
> Once that we are talking about "cont" command.  There are two cases that
> we need to think of:
>
> - incoming migration:
>
> If you start with -incoming foo, and then run "cont" on the monitor
> without having started the migration .... corruption is ensured.
>    

It's only ensured if you've got the same disk image running on another 
machine.  Considering that we support migrating from a file and we 
support migrating block devices, I don't think it's practical.

> - outgoing migration
>
> After sucessful migration, we can issue "cont" command in source, and
> having source and target running at the same time ->  disk corruption
> again.
>
> My suggestion:
> - add a third state "incoming", and cont/stop don't work on that state
> - add a fourth state "migrated", and "cont" gives an explicit error, and you
>    have to run "cont --force" or "cont" twice (whatever) to get it to continue.
>    

Very few users are going to do manual migration like this and those that 
do have no good reason to execute cont in either of these scenarios.  A 
--force command like this is equivalent to popping up a message box 
saying "are you sure you really want to do this" which most users find 
to be extremely annoying.

We should try to inform users when it's likely that they'll stumble upon 
a dangerous action.  cache=volatile is a good example of this because a 
user could have used it pretty easily and it's a reasonable expectation 
that we wouldn't expose a feature that could lead to corruption in 
obscure cases.

If a user executes cont in either of these scenarios and has two copies 
of a virtual machine running accessing the same resources, then they 
surely ought to expect bad behavior.

Regards,

Anthony LIguori

> Later, Juan.
>
>