[Qemu-devel] [PATCH] exit if -drive specified is invalid instead of ignoring the "wrong" -drive

[Qemu-devel] [PATCH] exit if -drive specified is invalid instead of ignoring the "wrong" -drive

[Michael Tokarev]

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>
---
 vl.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 8bcf2ae..3792afb 100644
--- a/vl.c
+++ b/vl.c
@@ -2098,7 +2098,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)
-- 
1.7.2.5

Re: [Qemu-devel] [PATCH] exit if -drive specified is invalid instead of ignoring the "wrong" -drive

[Jes Sorensen]

On 03/30/11 14:31, Michael Tokarev wrote:
> 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>
> ---
>  vl.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/vl.c b/vl.c
> index 8bcf2ae..3792afb 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2098,7 +2098,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);
> +                }

Looks good, however it would be nice if you added an error message here.

Cheers,
Jes

Re: [Qemu-devel] [PATCH] exit if -drive specified is invalid instead of ignoring the "wrong" -drive

[Michael Tokarev]

30.03.2011 17:08, Jes Sorensen wrote:
> On 03/30/11 14:31, Michael Tokarev wrote:
>> 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>
>> ---
>>  vl.c |    4 +++-
>>  1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/vl.c b/vl.c
>> index 8bcf2ae..3792afb 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -2098,7 +2098,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);
>> +                }
> 
> Looks good, however it would be nice if you added an error message here.

It's already printed by drive_def():

 $ kvm -drive foo=bar
 kvm: -drive foo=bar: Invalid parameter 'foo'

I can add something like "unable to initialize -drive, exiting"
but to mee it looks sorta redundrand, no?

Thanks!

/mjt

Re: [Qemu-devel] [PATCH] exit if -drive specified is invalid instead of ignoring the "wrong" -drive

[Jes Sorensen]

On 03/30/11 15:22, Michael Tokarev wrote:
> 30.03.2011 17:08, Jes Sorensen wrote:
>> > On 03/30/11 14:31, Michael Tokarev wrote:
>>> >> 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>
>>> >> ---
>>> >>  vl.c |    4 +++-
>>> >>  1 files changed, 3 insertions(+), 1 deletions(-)
>>> >>
>>> >> diff --git a/vl.c b/vl.c
>>> >> index 8bcf2ae..3792afb 100644
>>> >> --- a/vl.c
>>> >> +++ b/vl.c
>>> >> @@ -2098,7 +2098,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);
>>> >> +                }
>> > 
>> > Looks good, however it would be nice if you added an error message here.
> It's already printed by drive_def():
> 
>  $ kvm -drive foo=bar
>  kvm: -drive foo=bar: Invalid parameter 'foo'
> 
> I can add something like "unable to initialize -drive, exiting"
> but to mee it looks sorta redundrand, no?

Ah in that case I agree - I didn't look deep enough in the code.

Acked-by: Jes Sorensen <Jes.Sorensen@redhat.com>

[Qemu-devel] Re: [PATCH] exit if -drive specified is invalid instead of ignoring the "wrong" -drive

[Kevin Wolf]

Am 30.03.2011 14:31, schrieb Michael Tokarev:
> 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>

Thanks, applied to the block branch. CCed Justin for stable.

Kevin