All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH RFC 00/10] libxl: new hotplug calling convention
Date: Thu, 17 Jan 2013 16:30:02 +0100	[thread overview]
Message-ID: <50F818FA.4010001@citrix.com> (raw)
In-Reply-To: <1358431019.13856.69.camel@zakaz.uk.xensource.com>

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.

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

  reply	other threads:[~2013-01-17 15:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21 16:59 [PATCH RFC 00/10] libxl: new hotplug calling convention Roger Pau Monne
2012-12-21 16:59 ` [PATCH RFC 01/10] libxl: libxl__prepare_ao_device should reset num_exec Roger Pau Monne
2013-01-17 13:57   ` Ian Campbell
2012-12-21 17:00 ` [PATCH RFC 02/10] libxl: add new hotplug interface support to hotplug script callers Roger Pau Monne
2013-01-18 13:29   ` Ian Campbell
2013-01-18 16:24     ` Roger Pau Monné
2013-01-21 10:07       ` Ian Campbell
2013-01-21 12:11         ` Roger Pau Monné
2013-01-21 12:18           ` Ian Campbell
2013-01-22  9:30     ` Roger Pau Monné
2012-12-21 17:00 ` [PATCH RFC 03/10] libxl: add new "method" parameter to xl disk config Roger Pau Monne
2013-01-17 15:49   ` Ian Campbell
2012-12-21 17:00 ` [PATCH RFC 04/10] libxl: add prepare/unprepare operations to the libxl public interface Roger Pau Monne
2012-12-21 17:00 ` [PATCH RFC 05/10] libxl: add disk specific remove functions Roger Pau Monne
2012-12-21 17:00 ` [PATCH RFC 06/10] xl: add support for new hotplug interface to block-attach/detach Roger Pau Monne
2012-12-21 17:00 ` [PATCH RFC 07/10] libxl: add local attach support for new hotplug scripts Roger Pau Monne
2012-12-21 17:00 ` [PATCH RFC 08/10] libxl: add new hotplug interface support for HVM guests Roger Pau Monne
2012-12-21 17:00 ` [PATCH RFC 09/10] hotplug: document new hotplug interface Roger Pau Monne
2012-12-21 17:00 ` [PATCH RFC 10/10] hotplug/Linux: add iscsi block hotplug script Roger Pau Monne
2013-01-15 16:56 ` [PATCH RFC 00/10] libxl: new hotplug calling convention Roger Pau Monné
2013-01-17 13:56 ` Ian Campbell
2013-01-17 15:30   ` Roger Pau Monné [this message]
2013-01-17 15:40     ` Ian Campbell
2013-01-17 15:47       ` Roger Pau Monné
2013-01-17 15:57         ` Ian Campbell
2013-01-17 16:10           ` Roger Pau Monné
2013-01-17 16:15             ` Ian Campbell
2013-01-17 16:45               ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50F818FA.4010001@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.