From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51334 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOsy8-0003q9-UQ for qemu-devel@nongnu.org; Wed, 16 Jun 2010 09:47:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOsy4-0001O0-C7 for qemu-devel@nongnu.org; Wed, 16 Jun 2010 09:47:52 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:38377) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOsy4-0001Nr-73 for qemu-devel@nongnu.org; Wed, 16 Jun 2010 09:47:48 -0400 Received: by iwn10 with SMTP id 10so6530624iwn.4 for ; Wed, 16 Jun 2010 06:47:47 -0700 (PDT) Message-ID: <4C18D5FF.1050703@codemonkey.ws> Date: Wed, 16 Jun 2010 08:47:43 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [CFR 6/10] cont command References: <1276619430-15871-1-git-send-email-aliguori@us.ibm.com> <1276619430-15871-7-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Markus Armbruster , Anthony Liguori , qemu-devel@nongnu.org, Stefan Hajnoczi , Luiz Capitulino On 06/16/2010 08:11 AM, Juan Quintela wrote: > Anthony Liguori 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. > >