qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [CFR 6/10] cont command
Date: Wed, 16 Jun 2010 08:47:43 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4

On 06/16/2010 08:11 AM, Juan Quintela wrote:
Anthony Liguori<address@hidden>  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.





reply via email to

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