[Ovirt-devel] Taskomatic Qpid Transition, LVM and Migration.

[Ian Main]

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