how to assign resources exclusive to a single domU

how to assign resources exclusive to a single domU

[Olaf Hering]

While working on pvscsi support for libxl I noticed that assigning a
resource exclusivly to just a single domU via libxl will be a major
effort. Up to now libxl could rely on the fact that a resource can be
either shared or the backend deals with the attempt to share.

There are two cases in pvscsi:

 1) a single physical HST:CHN:TGT:LUN device must be assigned to just a
    single domU. While the (xenlinux) backend driver allows to assign
    the device to more than one domU the sharing can not work in
    practice.
 2) the xenlinux backend driver has two modes: emulation and raw. With
    raw mode the SCSI commands coming from domU will be passed directly
    to the physical device. I think its required to make sure that all
    devices connected to a physical scsi host must operate either
    entirely in raw mode or on emulation mode.

To handle both cases libxl could either assume that the admin is
responsible for proper configuration:
 - just one domU per physical device
 - if raw mode is enabled all devices on the physcial scsi host will be
   assigned to just one domU

Or libxl gets functionality to verify that two cases above are really
enforced. Doing that means that there has to be some global lock under
which the system state in xenstore is parsed and the to be assigned domU
configuration is compared:
 - are the physical devices already assigned
 - is the raw mode properly configured

In xend the case #1 was not handled. There is some code for case #2, I
have to check how complete the enforcement in xend was.

I wonder what should be done in my changes for libxl.

Olaf

Re: how to assign resources exclusive to a single domU

[Jürgen Groß]

On 02/26/2015 09:57 AM, Olaf Hering wrote:
> While working on pvscsi support for libxl I noticed that assigning a
> resource exclusivly to just a single domU via libxl will be a major
> effort. Up to now libxl could rely on the fact that a resource can be
> either shared or the backend deals with the attempt to share.
>
> There are two cases in pvscsi:
>
>   1) a single physical HST:CHN:TGT:LUN device must be assigned to just a
>      single domU. While the (xenlinux) backend driver allows to assign
>      the device to more than one domU the sharing can not work in
>      practice.

You should keep in mind that *some* cases might be absolutely okay.
Please don't assume all sharing configurations are nonsense!

>   2) the xenlinux backend driver has two modes: emulation and raw. With
>      raw mode the SCSI commands coming from domU will be passed directly
>      to the physical device. I think its required to make sure that all
>      devices connected to a physical scsi host must operate either
>      entirely in raw mode or on emulation mode.

This can be mapped to case #1: the raw mode is selected by assigning
all LUNs of a target to a guest via "feature-host". If case #1 is
verified it wouldn't be possible to assign some LUNs multiple times
which would be required to have a mixture of raw and emulation for
a target.

I wouldn't do more than xend in this case. The pvops upstream pvscsi
backend doesn't need the emulation mode any more, this is handled by
the generic target infrastructure .

> To handle both cases libxl could either assume that the admin is
> responsible for proper configuration:
>   - just one domU per physical device
>   - if raw mode is enabled all devices on the physcial scsi host will be
>     assigned to just one domU

Like in the non-virtualized world: the admin has to ensure that devices
in the SAN are either used by only one system, or that the systems
using it coordinate the shared usage.

> Or libxl gets functionality to verify that two cases above are really
> enforced. Doing that means that there has to be some global lock under
> which the system state in xenstore is parsed and the to be assigned domU
> configuration is compared:
>   - are the physical devices already assigned
>   - is the raw mode properly configured
>
> In xend the case #1 was not handled. There is some code for case #2, I
> have to check how complete the enforcement in xend was.
>
> I wonder what should be done in my changes for libxl.

If you are doing something, please add a flag to be able to disable
the additional security checks regarding multiple assignment.


Juergen

Re: how to assign resources exclusive to a single domU

[Olaf Hering]

On Fri, Feb 27, Jürgen Groß wrote:

> On 02/26/2015 09:57 AM, Olaf Hering wrote:
> >I wonder what should be done in my changes for libxl.
> If you are doing something, please add a flag to be able to disable
> the additional security checks regarding multiple assignment.

I think libxl should just allow multiple assignments of physical
devices. Its up to the admin to make sure the overall config is sane.

Olaf

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

Re: how to assign resources exclusive to a single domU

[Ian Campbell]

On Fri, 2015-02-27 at 09:19 +0100, Olaf Hering wrote:
> On Fri, Feb 27, Jürgen Groß wrote:
> 
> > On 02/26/2015 09:57 AM, Olaf Hering wrote:
> > >I wonder what should be done in my changes for libxl.
> > If you are doing something, please add a flag to be able to disable
> > the additional security checks regarding multiple assignment.
> 
> I think libxl should just allow multiple assignments of physical
> devices. Its up to the admin to make sure the overall config is sane.

I can't remember what libxl does today but WRT disks (with the phy
backend at least) xend used to have sharing checks and refuse to allow
sharing (for writeable disks) unless overridden (by "w+" in the mode
string, IIRC).

I don't think libxl implements those checks, so the override isn't
supported, but maybe it would be good to do so, and maybe it would be a
good idea for pvscsi to at least be consistent with what we might
eventually do for disks?

(FWIW I think most of the checks were actually in the block-* scripts,
I'm not sure why they are active under libxl)

Ian.


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