Re: [Xen-devel] [PATCH RFC 00/10] libxl: new hotplug calling convention

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-01-17 at 15:30 +0000, Roger Pau Monne wrote:
> On 17/01/13 14:56, Ian Campbell wrote:
> > On Fri, 2012-12-21 at 16:59 +0000, Roger Pau Monne wrote:
> >> This series implements a new hoplug calling convention for libxl.
> >>
> >> The aim of this new convention is to reduce the blackout phase of 
> >> migration when using complex hotplug scripts, like iSCSI or other kind 
> >> of storage backends that might have a non trivial setup time.
> >>
> >> There are some issues that I would like to discuss, the first one is 
> >> the fact that pdev_path field in libxl_device_disk is no longuer used 
> >> to store a physical path, since diskspec "target" can now contain 
> >> "random" information to connect a block device.
> >>
> >> To solve this I would like to introduce a new field in 
> >> libxl_device_disk called "target", that will be used to store the 
> >> diskspec target parameter. This can later be copied to pdev_path if 
> >> using the old hotplug calling convention.
> > 
> > Perhaps we could arrange either via a union or via LIBXL_API_VERSION
> > ifdefs that "pdev_path" and "target" are in the same place?
> 
> We still need pdev_path, I would say only internally because once the
> "target" has been attached to the Dom0, pdev_path has the path to the
> block device that will be used in blkback, but the caller doesn't need
> to know about this.

So in the new scheme both pdev_path are valid and contain different
information?

> Old callers can continue to pass pdev_path as currently doing, but
> callers wanting to use the new hotplug interface should instead use
> target, and set hotplug_version to 1.
> 
> What I'm doing in this series is overwriting pdev_path with the real
> device path once the hotplug script has been executed, but that's clumsy.
> 
> >> The second issue is related to iSCSI and iscsiadm, specifically the 
> >> way to set authentication parameters, which is done with command line 
> >> parameters or editing files (which each distro seems to place in 
> >> different locations). I will look into this to see if we can find a 
> >> suitable solution.
> >>
> >> Thanks for the comments, Roger.
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxx
> >> http://lists.xen.org/xen-devel
> > 
> > 
> 



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