From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH 3/4] docs: add pvscsi.txt Date: Mon, 02 Mar 2015 16:35:28 +0100 Message-ID: <54F48340.1070506@suse.com> References: <1425291362-30228-1-git-send-email-olaf@aepfle.de> <1425291362-30228-4-git-send-email-olaf@aepfle.de> <54F443A3.9070806@suse.com> <20150302151416.GB20719@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150302151416.GB20719@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Olaf Hering Cc: Keir Fraser , Ian Campbell , Tim Deegan , Ian Jackson , xen-devel@lists.xen.org, Jan Beulich List-Id: xen-devel@lists.xenproject.org On 03/02/2015 04:14 PM, Olaf Hering wrote: > On Mon, Mar 02, Juergen Gross wrote: > >> On 03/02/2015 11:16 AM, Olaf Hering wrote: >>> +How to do live migration? >>> + - pdev will likely be evaluated again on the target host if it came from >>> + domU.cfg. But what about pdev from 'xl scsi-attach pdev vdev'? Its required >>> + to adjust h:c:t:l on the target host. >> Use WWN notation? :-) >> >> This was one of the reason the backend should support it. > > How does it handle WWN internally, given that > scsiback_add_translation_entry does not seem to understand it? It does understand it. WWN:l is okay. A pscsi device can have multiple LUNs. The WWN is per target, not per LUN. The target infrastructure allows far more complex configurations (e.g. specific LUN mappings, access control for each LUN). > >>> +Implement checks for duplicate pdev assignments? >>> + - Not sure if SCSI devices can be shared. Will the state be consistent during >>> + concurrent access? Should the host admin assume cooperative access from >>> + multiple domUs? >> SCSI does support device sharing. That's the reason for the existence of >> SCSI commands like "reserve" and "release". > > In this case the code which checks pdev usage in > libxl_device_vscsi_get_host can just be removed. Hmm, maybe issuing a warning would be a sensible thing to do? Juergen