]> rtime.felk.cvut.cz Git - lisovros/qemu_apohw.git/commitdiff
exit if -drive specified is invalid instead of ignoring the "wrong" -drive
authorMichael Tokarev <mjt@tls.msk.ru>
Wed, 30 Mar 2011 12:31:05 +0000 (16:31 +0400)
committerJustin M. Forbes <jforbes@redhat.com>
Tue, 3 May 2011 13:30:49 +0000 (08:30 -0500)
This fixes the problem when qemu continues even if -drive specification
is somehow invalid, resulting in a mess.  Applicable for both current
master and for stable-0.14 (and the same issue exist 0.13 and 0.12 too).

The prob can actually be seriuos: when you start guest with two drives
and make an error in the specification of one of them, and the guest
has something like a raid array on the two drives, guest may start failing
that array or kick "missing" drives which may result in a mess - this is
what actually happened to me, I did't want a resync at all, and a resync
resulted in re-writing (and allocating) a 4TB virtual drive I used for
testing, which in turn resulted in my filesystem filling up and whole
thing failing badly.  Yes it was just testing VM, I experimented with
larger raid arrays, but the end result was quite, well, unexpected.

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Acked-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
vl.c

diff --git a/vl.c b/vl.c
index ed2cdfae421815d5fd238113a8d9143e1bd409f9..e392f9b80b330a7f6cc3fed5ba0b8d7bc1d6a781 100644 (file)
--- a/vl.c
+++ b/vl.c
@@ -2066,7 +2066,9 @@ int main(int argc, char **argv, char **envp)
                           HD_OPTS);
                 break;
             case QEMU_OPTION_drive:
-                drive_def(optarg);
+                if (drive_def(optarg) == NULL) {
+                    exit(1);
+                }
                break;
             case QEMU_OPTION_set:
                 if (qemu_set_option(optarg) != 0)