[Pacemaker] Migrating VMs that depend on other VMs

[Lindsay Todd]

In my testing, I reappropriated two VMs, just to make sure I
understood the constraints on VM migrations:

primitive vm-compute-test ocf:ccni:xcatVirtualDomain \
        params nodename="compute-test" migration_network_suffix="-ib"
migration_transport="ssh" \
        op start interval="0" timeout="90s" \
        op stop interval="0" timeout="90s" \
        op monitor interval="45s" timeout="30s" \
        meta allow-migrate="true"
primitive vm-swbuildsl6 ocf:ccni:xcatVirtualDomain \
        params nodename="swbuildsl6" migration_network_suffix="-ib"
migration_transport="ssh" \
        op start interval="0" timeout="90s" \
        op stop interval="0" timeout="90s" \
        op monitor interval="45s" timeout="30s" \
        meta allow-migrate="true"
order o-vm-swbuildsl6-after-compute-test inf: vm-compute-test vm-swbuildsl6
order o-vm-compute-test inf: c-p-libvirtd vm-compute-test
order o-vm-swbuildsl6 inf: c-p-libvirtd vm-swbuildsl6

So it is just an ordering dependency.  I can freely migrate
vm-compute-test, although it induces a stop/start on vm-swbuildsl6.
Attempts to migrate vm-swbuildsl6 are always done as stop/start.  This
doesn't make sense to me, but is what the documentation describes.
(The ocf:ccni:xcatVirtualDomain resource is just VirtualDomain hacked
to use xCAT to start and stop VMs running on the KVM hypervisor.  The
c-p-libvirtd resource is a clone resource of libvirtd -- depending on
clones doesn't impact VM migration.)

What I plan to have is something more like this:

primitive vm-db0 ocf:ccni:xcatVirtualDomain ...
primitive vm-ldap01 ocf:ccni:xcatVirtualDomain ...
primitive vm-ldap02 ocf:ccni:xcatVirtualDomain ...
primitive vm-bq01 ocf:ccni:xcatVirtualDomain ...
primitive vm-bq02 ocf:ccni:xcatVirtualDomain ...
order o-bq-ldap inf: vm-db0 [ vm-ldap01 vm-ldap02 ] [vm-bq01 vm-bq02 ]
colocation c-spread-ldap -10: vm-ldap01 vm-ldap02
colocation c-spread-bq -10: vm-bq01 vm-bq02

The idea is to start the VMs in the correct order, and also try to
spread them out on different hypervisors.  I'd really like to not lose
the ability to migrate VMs.  I think the intent is sensible

If pacemaker can manage services inside VMs, that would give some nice
possibilities -- I would probably float IP addresses for the ldap
servers, etc.  But I might still end up needing a service with
specialized OS requirements best handled with a specialized VM,
perhaps one that can't easily run pacemaker-remote.  So VM migration
is still really needed.

/Lindsay


On Tue, May 14, 2013 at 4:26 AM, Lars Marowsky-Bree <lmb at suse.com> wrote:
> On 2013-05-13T12:28:17, Lindsay Todd <rltodd.ml1 at gmail.com> wrote:
>
>> Folks: On my cluster built on SL6.4, I need to deploy some VMs that depend
>> on other VMs:
>>
>>    - db0 has no dependendencies
>>    - ldap01,ldap02 require db0 to be running -- ordering constraint, but no
>>    collocation (other than we'll use a collocation constraint to recommend
>>    ldap01, ldap02 run on different physical hosts)
>>    - bq01, bq02 depend on at least one of ldap01, ldap02 running
>>
>> At this point, I've got a test arrangement corresponding to only the db01
>> and ldap01 resources being deployed, but it is enough to expose a problem...
>>
>> The constraints themselves are quite simple.  The trouble arises when we
>> try to migrate VMs.  As the "Pacemaker Configuration Explained" manual
>> states: "The resource must not, directly or indirectly, depend on any
>> primitive or group resources."  What is the reason for this restriction?
>
> Because we can't migrate the dependencies.
>
> But I think this ought to be limited to collocation dependencies; live
> migration of resources that are merely ordered should be fine.
> (Technically speaking.)
>
> Can you show the actual dependencies you have configured, please?
> "depend on" is a bit unspecific and doesn't clarify if you're looking at
> order or collocation or both.
>
>
> Regards,
>     Lars
>
> --
> Architect Storage/HA
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org