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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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.

 -George



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