Ovirt devel - Jan 2009 - Taskomatic Qpid Transition, LVM and Migration.

Howdy!

So I did a little more playing around with volume scanning and found
that it basically does work, except when you get multiple pools.  To
illustrate I did the following:

- Created second storage pool named ovirtpriv:more_storage
- Added the storage server to ovirt via the WUI.
- Added a few LVM volumes to a few pools as seen in the screenshot
below.
- Added the more_storage pool to ovirt via the WUI.

At this point you can see that the LVM volumes are getting picked up in
both pools:

http://stemwinder.org/messed_storage_pools.png

I then:

- Created another volume in ovirtpriv:storage under lun3 called
underlun3_new.
- Used 'Refresh' via the WUI to rescan ovirtpriv:more_storage

At which point you see:

http://stemwinder.org/another_messed_pool.png

And creating volumes in the ovirtpriv:more_storage pool also causes them
to show up in ovirtpriv:storage pool.

Now, I'm really not sure if this can be fixed via more libvirt trickery
or not but I'd really like to see the qpidified taskomatic get some
testing time before the release.  I also think that this should really
be implemented within libvirt-qpid rather than using libvirt-style
calls from taskomatic.

So, I'd like to propose that I post a new patch on Monday with
Chris's comments incorporated but with LVM scanning still removed so
that we can get some testing of taskomatic/qpid.  At that point I'll
make it top priority to get the LVM scanning working again properly.
This will likely mean a new version of libvirt-qpid that figures all
this out and provides a nice pointer to a volumes LVM pool making it
much easier for taskomatic to figure out.

This sound reasonable?  Chris, you ok with that?

The other sticking point is migration.  Currently we are still using
ruby-qpid to do the migration via libvirt.  I have spoken to the
libvirt folks about the creation of a split (src and dst) API to allow
migration to be set up over qpid but it sounds dubious.  It is also
likely that we will need libvirt to libvirt communications in the
future anyway as that is the way they are headed.

So for now I think we're going to need to carry the libvirt gssapi
configuration going forward until a better solution is found.

	Ian

Ian Main wrote:
> So, I'd like to propose that I post a new patch on Monday with
> Chris's comments incorporated but with LVM scanning still removed so
> that we can get some testing of taskomatic/qpid.  At that point I'll
> make it top priority to get the LVM scanning working again properly.
> This will likely mean a new version of libvirt-qpid that figures all
> this out and provides a nice pointer to a volumes LVM pool making it
> much easier for taskomatic to figure out.
> 
> This sound reasonable?  Chris, you ok with that?
I guess that is fine; we'll have a temporary break in functionality, but as
long
as we fix it up pretty quickly, it should be OK.

As far as getting LVM working, I actually came up with another idea that may
work and require no changes to libvirt itself.  The basic problem with the
current algorithm (besides the fact that it is complicated) is that
pool.lookup_vol_by_name() works globally, not on a particular pool.  I *think*
we could actually write a quick wrapper to that call that does the right thing;
after all, we do have the pool already, so we can fetch all of the volumes that
are attached, and see if *this* volume matches up with one of the ones we
already know about.  It would have to be looked at in more detail, though.
> 
> The other sticking point is migration.  Currently we are still using
> ruby-qpid to do the migration via libvirt.  I have spoken to the
> libvirt folks about the creation of a split (src and dst) API to allow
> migration to be set up over qpid but it sounds dubious.  It is also
> likely that we will need libvirt to libvirt communications in the
> future anyway as that is the way they are headed.
> 
> So for now I think we're going to need to carry the libvirt gssapi
> configuration going forward until a better solution is found.
Just to be clear; by "libvirt gssapi configuration", you mean that you
are still
doing migration by directly connecting to dst and src on from the ovirt WUI, and
then doing the transaction like that?  If so, that makes sense; anything else is
going to require a lot more thought and time to implement.

-- 
Chris Lalancette