[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/18] Add qemu-storage-daemon
From: |
Max Reitz |
Subject: |
Re: [RFC PATCH 00/18] Add qemu-storage-daemon |
Date: |
Wed, 6 Nov 2019 16:35:38 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 |
On 06.11.19 15:58, Kevin Wolf wrote:
> Am 06.11.2019 um 15:37 hat Max Reitz geschrieben:
>> On 17.10.19 15:01, Kevin Wolf wrote:
>>> This series adds a new tool 'qemu-storage-daemon', which can be used to
>>> export and perform operations on block devices.
>>
>> Looks good to me.
>>
>> I remember a discussion at some KVM Forum a couple of years ago where
>> someone (Berto?) was asking about adding QMP to qemu-nbd. I found it a
>> pragmatic solution, but I remember that Markus was against it, based on
>> the fact that we wanted qemu -M none.
>
> Yes, but it turned out that qemu -M none is a bit too heavyweight in
> practice and fixing that would involve a lot of work. As I understand it
> (mostly what I took from discussions on the list), even if someone were
> interested in doing that and started now, it's the kind of thing that
> would take multiple years.
I didn’t want to give the impression I wouldn’t agree. O:-)
(I agree completely, and basically that was my
understanding/opinion/feeling back when we discussed it, too.)
> As long as we keep the code simple and the interesting parts are just
> reused and shared with the system emulator and other tools, it shouldn't
> be hard to maintain.
>
>> Well, but anyway. Just as I didn’t have anything against adding QMP to
>> qemu-nbd, I don’t have anything against adding a new application that
>> kind of fulfills the same purpose. And I think introducing a new
>> application instead of reusing qemu-nbd that focuses on all-around QAPI
>> compatibility (which qemu-nbd decidedly does not have) makes sense.
>
> Yes, QAPI is one big reason for creating a new tool that doesn't need to
> support the old qemu-nbd command line. Another is that we can add other
> types of exports that are not NBD.
Sure.
>> The only thing I don’t like is the name, but that’s what <Tab> is for.
>> :-)
>
> I'm open for suggestions, but I thought 'qsd' was a bit too terse. :-)
>
> (Actually, maybe we could even pick something that doesn't mention
> storage or block? After all, it can do all kinds of QEMU backends in
> theory. Not sure if there's any standalone use for them, but who
> knows...)
Be careful, if we stuff too much into it, we’ll end up with just qemu
again. :-)
Max
signature.asc
Description: OpenPGP digital signature