From: Anthony Liguori <anthony@codemonkey.ws>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Lucas Meneghel Rodrigues <lmr@redhat.com>,
Juan Quintela <quintela@redhat.com>,
qemu-devel@nongnu.org,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH 3/4] qcow2: add a migration blocker
Date: Mon, 14 Nov 2011 10:49:07 -0600 [thread overview]
Message-ID: <4EC14683.1030800@codemonkey.ws> (raw)
In-Reply-To: <CAJSP0QWjf3z36Ht3C-RgvJOe7fo=EGrGjFHwtH0A5y6tgFCksg@mail.gmail.com>
On 11/14/2011 10:45 AM, Stefan Hajnoczi wrote:
> On Mon, Nov 14, 2011 at 4:25 PM, Anthony Liguori<anthony@codemonkey.ws> wrote:
>> On 11/14/2011 09:51 AM, Stefan Hajnoczi wrote:
>>>
>>> On Fri, Nov 11, 2011 at 8:29 PM, Anthony Liguori<aliguori@us.ibm.com>
>>> wrote:
>>>>
>>>> +#define QERR_BLOCK_FORMAT_FEATURE_NOT_SUPPORTED \
>>>> + "{ 'class': 'BlockFormatFeatureNotSupported', 'data': { 'format':
>>>> %s, 'name': %s, 'feature': %s } }"
>>>> +
>>>
>>> Isn't having a separate error going to make life harder for management
>>> tool writers? I would have expected one "migration not supported"
>>> error, regardless of whether the reason is ivshmem, qcow2, or anything
>>> else.
>>
>> Errors shouldn't be tied to verbs. IOW, if you have a migrate command, you
>> don't want to have a MigrationFailed error because that's tied to a specific
>> verb.
>>
>> Instead, you want the errors to provide additional information about the
>> verb failed. In this case, the verb is failing because you're requesting to
>> use a feature that is not supported by this particular block format.
>
> Okay, this error is semantically different from the earlier error in
> this series.
>
> We need QMP documentation updates in this series so management tool
> writers know to look out for. Otherwise libvirt and friends can only
> provide generic "This operation failed. Opaque QEMU error:<blob>"
> rather than responding with graceful error handling.
Current QMP documentation does not document errors.
The QAPI changes document the errors but it also changes the error paths such
that you can do this in a sane fashion.
So I agree with you 100% but it's a bigger thing than just this series.
Regards,
Anthony Liguori
>
> Stefan
>
next prev parent reply other threads:[~2011-11-14 16:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-11 20:29 [Qemu-devel] [PATCH 1/4] migrate: add migration blockers Anthony Liguori
2011-11-11 20:29 ` [Qemu-devel] [PATCH 2/4] ivshmem: use migration blockers to prevent live migration in peer mode Anthony Liguori
2011-11-12 20:24 ` Aneesh Kumar K.V
2011-11-11 20:29 ` [Qemu-devel] [PATCH 3/4] qcow2: add a migration blocker Anthony Liguori
2011-11-14 15:51 ` Stefan Hajnoczi
2011-11-14 16:25 ` Anthony Liguori
2011-11-14 16:37 ` Kevin Wolf
2011-11-14 16:45 ` Stefan Hajnoczi
2011-11-14 16:49 ` Anthony Liguori [this message]
2011-11-14 16:57 ` Stefan Hajnoczi
2011-11-11 20:29 ` [Qemu-devel] [PATCH 4/4] qed: add " Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EC14683.1030800@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=kwolf@redhat.com \
--cc=lmr@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@gmail.com \
--cc=stefanha@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).