libvirt users - Jun 2010 - Multipath pools - practical for use?

Hi all,

Writing up some Fedora documentation, and looking to figure out the best 
way of mapping multipath network(!) LUNs to pools in libvirt.

   ie Infiniband SRP LUNs, but would probably apply to Fibre Channel
      equally as well.

There are two approaches I can think of easily:

  a) Large LUNs (ie TB+) that are mapped to a host server as disk, with
     each LUN being configured as an LVM pool.  This lets the host
     slice the pool up into volumes with the libvirt volume creation
     commands.

  b) Pre-purposed LUNs mapped to a host server as disk, but passed
     through directly to their respective guests.

     ie Something like Oracle, with 3 SAN LUNs mapped to guest FOO for
        its database data

In a non-libvirt world I'd look at configuring the LUNs on the host
with persistent name using multipath, then present them appropriately to 
whatever needs them from there.

However, libvirt has a pool type called "multipath".  Looking at the 
docs online, it doesn't appear to be all that fully featured at this 
point.  Seems more of a brief mention and footnote, so I'm wondering 
whether to use it or skip it for now in the Fedora docs.

Anyone have thoughts/suggestions/etc? :)

Regards and best wishes,

Justin Clift

-- 
Salasaga  -  Open Source eLearning IDE
               http://www.salasaga.org

On Thu, Jun 10, 2010 at 03:17:49AM +1000, Justin Clift
wrote:
> Hi all,
> 
> Writing up some Fedora documentation, and looking to figure out the
> best way of mapping multipath network(!) LUNs to pools in libvirt.
> 
>   ie Infiniband SRP LUNs, but would probably apply to Fibre Channel
>      equally as well.
I'm assuming you're talking about the device mapper multipath
implementation...

I've only used multipath with Fibre Channel and iSCSI, but I presume
the Infiniband SRP LUNs produce the same entries in /dev/mapper that
other transports do.
> There are two approaches I can think of easily:
> 
>  a) Large LUNs (ie TB+) that are mapped to a host server as disk, with
>     each LUN being configured as an LVM pool.  This lets the host
>     slice the pool up into volumes with the libvirt volume creation
>     commands.
That's a valid way to do it.
>  b) Pre-purposed LUNs mapped to a host server as disk, but passed
>     through directly to their respective guests.
> 
>     ie Something like Oracle, with 3 SAN LUNs mapped to guest FOO for
>        its database data
That's also valid.
> In a non-libvirt world I'd look at configuring the LUNs on the host
> with persistent name using multipath, then present them
> appropriately to whatever needs them from there.
Using a persistent name is the definitely the way to do it with or
without libvirt.
> However, libvirt has a pool type called "multipath".  Looking at
the
> docs online, it doesn't appear to be all that fully featured at this
> point.  Seems more of a brief mention and footnote, so I'm wondering
> whether to use it or skip it for now in the Fedora docs.
> 
> Anyone have thoughts/suggestions/etc? :)
The multipath pool is syntactic sugar, basically.  It's used to get a
list of multipath devices on a host easily.  The multipath devices can
then (as you suggest above) be carved up into disk or logical pools,
or assigned straight to VMs.

It's probably most useful when VMs are intended to use only the
multipath devices on a physical host.  I.e., the set of volumes in the
multipath pool is equivalent or nearly equivalent to the set of
devices that are intended to be assigned to VMs.

One design decision was to keep multipath support simple and that
libvirt should not attempt to configure multipath, so at the time that
the physical host's OS is installed, it needs to have its blacklist
set, and should have (again as you suggest above) user_friendly_names
set to no.  Those should be one-time tasks.

Dave