From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: [PATCH RFC 00/10] libxl: new hotplug calling convention Date: Tue, 15 Jan 2013 17:56:50 +0100 Message-ID: <50F58A52.5000302@citrix.com> References: <1356109208-6830-1-git-send-email-roger.pau@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1356109208-6830-1-git-send-email-roger.pau@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "xen-devel@lists.xen.org" Cc: Ian Jackson , Ian Campbell List-Id: xen-devel@lists.xenproject.org Ping! On 21/12/12 17:59, 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 longer used > to store a physical path, since diskspec "target" can now contain > "random" information to connect a block device. Does someone has any feedback about this proposed change? Will it be OK to insert this new field? I guess I will have to use some kind of backward-compatible mechanism, like: if (disk->pdev_path) disk->target = disk->pdev_path; So old clients that use pdev_path still work as expected. > > 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. > > 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 >