Re: [PATCH 2/3] libxl: add domain config parameter to force start of qemu

[Juergen Gross <jgross@suse.com>]

On 21/03/16 15:28, George Dunlap wrote:
> On 18/03/16 08:11, Juergen Gross wrote:
>> On 17/03/16 17:06, George Dunlap wrote:
>>> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross <jgross@suse.com> wrote:
>>>> Today the device model (qemu) is started for a pv domain only in case
>>>> a device requiring qemu is specified in the domain configuration
>>>> (qdisk, vfb, channel). If there is no such device the device model
>>>> isn't started and hence it is possible to add such a device to the
>>>> domain later.
>>>>
>>>> Add a domain configuration parameter to specify the device model is
>>>> to be started in any case. This will enable adding devices with a
>>>> qemu based backend later.
>>>>
>>>> While the optimal solution would be to start the device model
>>>> automatically when needed this would require some major rework of
>>>> libxl at multiple places.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>
>>> So wait -- what happens now if you try to attach a disk with a qdisk
>>> backend to a PV guest that didn't start with qemu running?
>>
>> It won't work (that was my test case for the patch).
>>
>>> I'd really like to see patch 3 get in, but I'm not really in favor of
>>> this sort of a user-visible hack, particularly as we have to support
>>> it in libxl more or less indefinitely.
>>
>> Hmm, really? We can add a smarter variant later which will start the
>> device model in case it isn't started yet. Then the new config parameter
>> could be just ignored.
> 
> Sure; but it will (probably) only actually be useful for one release
> cycle (now 6 months), and then it will sit around cluttering up the
> interface for years to come.  The situation wrt hotplug has been this
> way for years now, and nobody has complained; I don't think an extra 6
> months will be a big deal.
> 
> Ultimately it's the tools maintainers' call; I wouldn't argue against it
> if one of them think it's a good idea.
> 
>> I didn't do the smart variant as I'm not sure I could set it up in time
>> for 4.7. I'd be happy to do it with some assistance regarding the async
>> framework of libxl I'm not at all familiar with.
> 
> I'm sure help could be arranged; but it might be difficult to do by 4.7.

Okay, let's see what can be arranged.

BTW: This patch is not strictly required for patch 3. Patch 3 is just
adding another case where no device model is available when needed.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel