12:17 p.m.
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
3:29 p.m.
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
5316
days inactive
5316
days old
1 comments
2 participants
participants (2)
-
Dave Allan -
Justin Clift