| Message ID | 1301488265-22028-1-git-send-email-mjt@msgid.tls.msk.ru |
|---|---|
| State | New |
| Headers | show |
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
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
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>
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
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)
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(-)