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....@citrix.com> >>>>> 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.dun...@eu.citrix.com> >>> >>> 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@lists.xen.org http://lists.xen.org/xen-devel
