aboutsummaryrefslogtreecommitdiff
path: root/vl.c
diff options
context:
space:
mode:
authorMichael Tokarev <mjt@tls.msk.ru>2011-03-30 16:31:05 +0400
committerKevin Wolf <kwolf@redhat.com>2011-04-07 13:51:48 +0200
commite2982c3a27ab4c0879e61de3c9c57b838f7d0966 (patch)
tree6d01634e3bf1c3e6b3eabe838f90d5e31173071e /vl.c
parenteb863add0204210480d018a3298ca22e4eadf3ce (diff)
downloadqemu-e2982c3a27ab4c0879e61de3c9c57b838f7d0966.zip
qemu-e2982c3a27ab4c0879e61de3c9c57b838f7d0966.tar.gz
qemu-e2982c3a27ab4c0879e61de3c9c57b838f7d0966.tar.bz2
exit if -drive specified is invalid instead of ignoring the "wrong" -drive
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>
Diffstat (limited to 'vl.c')
-rw-r--r--vl.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/vl.c b/vl.c
index de232b7..68c3b53 100644
--- a/vl.c
+++ b/vl.c
@@ -2102,7 +2102,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)