Foreman multipath pool support

Development
#1

I'm working on getting our foreman up and running but we're currently
looking at using a multipath pool and pre-defining LUNs in our san for
foreman to use. Currently, when presented with a multipath pool, foreman
continues to treat it like it can have libvirt create a volume on it,
but it can't (libvirt doesn't support volume creation / management at
all on multipath pools, currently)

What I think would be best for foreman to do right now is simply present
a list of available volumes on the multipath pool and I can choose one
to use. This seems like it should be fairly straightforward to add, and
I can almost certainly get a dev on my side to help me get this added
soon, I just want to make sure we do it in a way that will allow it to
be a candidate for inclusion in a later foreman release.

Any thoughts on implementation, here?

Thanks!

-Jeremy

P.S.

The alternative, of course, is to simply define one large lun for each
VM host and layer LVM on top of that, but we're hoping to be able to
have the ability to migrate VMs across hosts at some point, so we would
like to avoid that if at all possible.

#2

> I'm working on getting our foreman up and running but we're
> currently looking at using a multipath pool and pre-defining LUNs
> in our san for foreman to use. Currently, when presented with a
> multipath pool, foreman continues to treat it like it can have
> libvirt create a volume on it, but it can't (libvirt doesn't
> support volume creation / management at all on multipath pools,
> currently)

Makes sense, it's a kind of read-only pool as it's just re-exporting
the mpath devices that multipath's provided.

> What I think would be best for foreman to do right now is simply
> present a list of available volumes on the multipath pool and I can
> choose one to use. This seems like it should be fairly
> straightforward to add, and I can almost certainly get a dev on my
> side to help me get this added soon, I just want to make sure we do
> it in a way that will allow it to be a candidate for inclusion in a
> later foreman release.
>
> Any thoughts on implementation, here?

The libvirt UI in Foreman
(app/views/compute_resources_vms/form/libvirt/_volume.html.erb) could
be extended to allow selection of an existing volume instead of
creating a new volume, using a couple of radio buttons (similar to the
NAT/bridged network selection).

Assuming Fog makes it easy to connect existing volumes to a VM, then
this would happen automatically in new_vm in
app/models/compute_resources/foreman/model/libvirt.rb, where Foreman
constructs a hash of options to pass to Fog, including all of the
volumes that get associated to the host. You'd just need to make sure
the right attributes (possibly the pool and volume ID?) are passed
into Foreman from the UI form when an existing volume is selected.

The create_volumes method would probably need to ignore existing
volumes too.

> The alternative, of course, is to simply define one large lun for
> each VM host and layer LVM on top of that, but we're hoping to be
> able to have the ability to migrate VMs across hosts at some point,
> so we would like to avoid that if at all possible.

Indeed, makes sense, and I think this could be a useful feature for
non-multipath pools too.

Dominic Cleal
Red Hat Engineering

··· On 02/08/13 18:01, Jeremy Kitchen wrote:
#3

> I'm working on getting our foreman up and running but we're currently
> looking at using a multipath pool and pre-defining LUNs in our san for
> foreman to use. Currently, when presented with a multipath pool, foreman
> continues to treat it like it can have libvirt create a volume on it,
> but it can't (libvirt doesn't support volume creation / management at
> all on multipath pools, currently)
>
> What I think would be best for foreman to do right now is simply present
> a list of available volumes on the multipath pool and I can choose one
> to use. This seems like it should be fairly straightforward to add, and
> I can almost certainly get a dev on my side to help me get this added
> soon, I just want to make sure we do it in a way that will allow it to
> be a candidate for inclusion in a later foreman release.
>

no one is working on it afaik, so +1 for any contribution :slight_smile:

>
> Any thoughts on implementation, here?
>

So what you are saying is that libvirt is missing an API to create luns,
another way to implement it would be via adding another functionality to a
proxy, which can create the lun, prior to creating the vm?

> Thanks!
>
> -Jeremy
>
> P.S.
>
> The alternative, of course, is to simply define one large lun for each
> VM host and layer LVM on top of that, but we're hoping to be able to
> have the ability to migrate VMs across hosts at some point, so we would
> like to avoid that if at all possible.
>
yeah, sucks, so -1 :slight_smile:

thanks!
Ohad

··· On Fri, Aug 2, 2013 at 8:01 PM, Jeremy Kitchen wrote:
#4

>
> > I'm working on getting our foreman up and running but we're currently
> > looking at using a multipath pool and pre-defining LUNs in our san for
> > foreman to use. Currently, when presented with a multipath pool, foreman
> > continues to treat it like it can have libvirt create a volume on it,
> > but it can't (libvirt doesn't support volume creation / management at
> > all on multipath pools, currently)
> >
> > What I think would be best for foreman to do right now is simply present
> > a list of available volumes on the multipath pool and I can choose one
> > to use. This seems like it should be fairly straightforward to add, and
> > I can almost certainly get a dev on my side to help me get this added
> > soon, I just want to make sure we do it in a way that will allow it to
> > be a candidate for inclusion in a later foreman release.
> >
>
> no one is working on it afaik, so +1 for any contribution :slight_smile:

Ok, but does that approach sound sane? I'm not sure what the other pool
types (I've only used lvm and default so far) do, or what other compute
resource providers do, but as far as I can tell this is breaking new
ground and I just want to make sure it's sane :slight_smile:

> > Any thoughts on implementation, here?
> >
>
> So what you are saying is that libvirt is missing an API to create luns,
> another way to implement it would be via adding another functionality to a
> proxy, which can create the lun, prior to creating the vm?

That's something I've considered, and will probably attempt to do later,
but sadly the SAN doesn't have an API, only a set of "command line
tools" which I haven't had a chance yet to investigate, nor will
I before this project needs to be done, unless it becomes an absolute
necessity (and it isn't, I just manually munged the XML for the host and
it booted off the SAN without issue, so if that's what we need to do for
first deployment, that's what we'll do)

Also, I haven't yet looked into whether or not ovirt/openstack/something
elsesolves some of this abstraction for us, leaving that for
a "investigate later" thing.

I'll get cracking on the implementation I mentioned and throw it out
there for approval when we get closer. I'm going to try to get some dev
assistance with it this week.

··· On Mon, Aug 05, 2013 at 10:50:01AM +0300, Ohad Levy wrote: > On Fri, Aug 2, 2013 at 8:01 PM, Jeremy Kitchen wrote:
#5

Jeremy,

Do you have any updates on this? What did you end up doing? We are
currently running into the same issue and would love some insight into what
you found. I might look into building the volume selection into foreman if
no one else has started it.

Robert

··· On Monday, August 5, 2013 10:24:53 AM UTC-7, Jeremy Kitchen wrote: > > On Mon, Aug 05, 2013 at 10:50:01AM +0300, Ohad Levy wrote: > > On Fri, Aug 2, 2013 at 8:01 PM, Jeremy Kitchen <jer...@nationbuilder.com>wrote: > > > > > > I'm working on getting our foreman up and running but we're currently > > > looking at using a multipath pool and pre-defining LUNs in our san for > > > foreman to use. Currently, when presented with a multipath pool, > foreman > > > continues to treat it like it can have libvirt create a volume on it, > > > but it can't (libvirt doesn't support volume creation / management at > > > *all* on multipath pools, currently) > > > > > > What I think would be best for foreman to do right now is simply > present > > > a list of available volumes on the multipath pool and I can choose one > > > to use. This seems like it should be fairly straightforward to add, > and > > > I can almost certainly get a dev on my side to help me get this added > > > soon, I just want to make sure we do it in a way that will allow it to > > > be a candidate for inclusion in a later foreman release. > > > > > > > no one is working on it afaik, so +1 for any contribution :) > > Ok, but does that approach sound sane? I'm not sure what the other pool > types (I've only used lvm and default so far) do, or what other compute > resource providers do, but as far as I can tell this is breaking new > ground and I just want to make sure it's sane :) > > > > Any thoughts on implementation, here? > > > > > > > So what you are saying is that libvirt is missing an API to create luns, > > another way to implement it would be via adding another functionality to > a > > proxy, which can create the lun, prior to creating the vm? > > That's something I've considered, and will probably attempt to do later, > but sadly the SAN doesn't have an API, only a set of "command line > tools" which I haven't had a chance yet to investigate, nor will > I before this project needs to be done, unless it becomes an absolute > necessity (and it isn't, I just manually munged the XML for the host and > it booted off the SAN without issue, so if that's what we need to do for > first deployment, that's what we'll do) > > Also, I haven't yet looked into whether or not ovirt/openstack/something > elsesolves some of this abstraction for us, leaving that for > a "investigate later" thing. > > I'll get cracking on the implementation I mentioned and throw it out > there for approval when we get closer. I'm going to try to get some dev > assistance with it this week. > >
#6

I have a commit to fix this.

https://github.com/theforeman/foreman/pull/1151

Robert Birnie
rbirnie@gmail.com

··· On Thu, Dec 19, 2013 at 12:59 PM, Robert wrote:

Jeremy,

Do you have any updates on this? What did you end up doing? We are
currently running into the same issue and would love some insight into what
you found. I might look into building the volume selection into foreman if
no one else has started it.

Robert

On Monday, August 5, 2013 10:24:53 AM UTC-7, Jeremy Kitchen wrote:

On Mon, Aug 05, 2013 at 10:50:01AM +0300, Ohad Levy wrote:

On Fri, Aug 2, 2013 at 8:01 PM, Jeremy Kitchen < >> jer...@nationbuilder.com>wrote:

I’m working on getting our foreman up and running but we’re currently
looking at using a multipath pool and pre-defining LUNs in our san
for

foreman to use. Currently, when presented with a multipath pool,
foreman

continues to treat it like it can have libvirt create a volume on it,
but it can’t (libvirt doesn’t support volume creation / management at
all on multipath pools, currently)

What I think would be best for foreman to do right now is simply
present

a list of available volumes on the multipath pool and I can choose
one

to use. This seems like it should be fairly straightforward to add,
and

I can almost certainly get a dev on my side to help me get this added
soon, I just want to make sure we do it in a way that will allow it
to

be a candidate for inclusion in a later foreman release.

no one is working on it afaik, so +1 for any contribution :slight_smile:

Ok, but does that approach sound sane? I’m not sure what the other pool
types (I’ve only used lvm and default so far) do, or what other compute
resource providers do, but as far as I can tell this is breaking new
ground and I just want to make sure it’s sane :slight_smile:

Any thoughts on implementation, here?

So what you are saying is that libvirt is missing an API to create
luns,
another way to implement it would be via adding another functionality
to a
proxy, which can create the lun, prior to creating the vm?

That’s something I’ve considered, and will probably attempt to do later,
but sadly the SAN doesn’t have an API, only a set of “command line
tools” which I haven’t had a chance yet to investigate, nor will
I before this project needs to be done, unless it becomes an absolute
necessity (and it isn’t, I just manually munged the XML for the host and
it booted off the SAN without issue, so if that’s what we need to do for
first deployment, that’s what we’ll do)

Also, I haven’t yet looked into whether or not ovirt/openstack/something
elsesolves some of this abstraction for us, leaving that for
a “investigate later” thing.

I’ll get cracking on the implementation I mentioned and throw it out
there for approval when we get closer. I’m going to try to get some dev
assistance with it this week.

–
You received this message because you are subscribed to the Google Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.