Re: [Xen-devel] [PATCH v2 0/7] libxl: add support for FreeBSD block hotplug scripts

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

El 29/2/16 a les 17:45, George Dunlap ha escrit:
> On 29/02/16 16:08, Roger Pau Monné wrote:
>> El 29/2/16 a les 15:26, George Dunlap ha escrit:
>>> On 29/02/16 12:18, Roger Pau Monné wrote:
>>>> El 29/2/16 a les 13:15, George Dunlap ha escrit:
>>>>> On Thu, Feb 25, 2016 at 7:25 PM, Roger Pau Monne <roger.pau@xxxxxxxxxx> 
>>>>> wrote:
>>>>>> This series enables using hotplug scripts with the FreeBSD blkback
>>>>>> implementation. Since FreeBSD blkback can use both block devices and 
>>>>>> regular
>>>>>> RAW files as disks, the physical-device xenstore backend node is now
>>>>>> OS-specific, Linux and NetBSD will encode the device major and minor 
>>>>>> numbers
>>>>>> there, while FreeBSD simply puts an absolute path to a disk image.
>>>>>
>>>>> Just to catch me up here -- is this an incompatible thing  that
>>>>> FreeBSD *already* does, or something you're adding with this series?
>>>>
>>>> I assume you mean the usage of the "physical-device" node, right? In
>>>> which case, this is something that I'm adding with this series (and some
>>>> FreeBSD kernel changes, of course). Current FreeBSD code doesn't use
>>>> physical-device at all.
>>>
>>> So there are cases where libxl could use the actual path to the
>>> resulting device (if available) as well.  Rather than overloading
>>> physical-device, what about making a new node, with a path, that can be
>>> used by all of them?
>>>
>>> I submitted such a patch here:
>>>
>>> <1439233885-22218-4-git-send-email-george.dunlap@xxxxxxxxxxxxx>
>>>
>>> As part of a series allowing HVM domains to use hotplug scripts.
>>>
>>> Thoughts?
>>
>> TBH, I thought we were planning to use local attach to deal with both
>> HVM guests with hotplug scripts and HVM guests using disks on driver
>> domains. The solution you propose only solves the first part (hotplug
>> scripts), but for disks coming from driver domains we would still need
>> to use local-attach, so I would be in favour of always using local attach.
> 
> So the bootloader path basically has a feature where it says, "If you
> can find a local path, just use it; otherwise do local attach".  This
> seems like a sensible path to take, as it avoids going through the whole
> process of doing a local attach / detach when the disk is already
> available.  It seems like doing the same thing for qemu, and for disks
> with hotplug scripts, makes a lot of sense.
> 
> Additionally, I doubt I'm going to have time to do anything wrt local
> attach before 4.7; this (with the appropriate libxl additions) could
> allow HVM guests for non-driver domains to have full parity with PV
> guests in a relatively simple way.

Right, I'm not opposed to this. I can
s/physical-device/physical-device-path/ in my series, but I would like
to have a confirmation that this is the way we are going to proceed forward.

In fact, there's a user on the FreeBSD-Xen ML that's interested in
working on hotplug script support for HVM guests, and I've told him that
the right way to solve this would be to perform a local-attach and use
the resulting device as the disk that's passed to QEMU.

Roger.


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