[openstack-dev] [fuel] [vmware] Two hypervisors in one cloud

Andrey Danin adanin at mirantis.com
Sat Jan 24 11:25:39 UTC 2015

I agree. But, as far as I know [2], there should be a some kind of ML2
integration layer for each plugin, and it should be in Neutron code base
(see [1] for example). There is no vDS ML2 driver in Neutron at all and FF
will become soon. So, it seems we cannot manage to adjust a blueprint spec
[3], make it approved, refactor a code of the driver and provide a 3rd
party CI for that in such a short period before FF.

[1] thin Mellanox ML2 driver https://review.openstack.org/#/c/148614/
[3] https://blueprints.launchpad.net/neutron/+spec/ml2-dvs-mech-driver

On Sat, Jan 24, 2015 at 12:45 AM, Kevin Benton <blak111 at gmail.com> wrote:

> It's worth noting that all Neutron ML2 drivers are required to move to
> their own repos starting in Kilo so installing an extra python package to
> use a driver will become part of the standard Neutron installation
> workflow. So I would suggest creating a stackforge project for the vDS
> driver and packaging it up.
> On Fri, Jan 23, 2015 at 11:39 AM, Andrey Danin <adanin at mirantis.com>
> wrote:
>> Hi, all,
>> As you may know, Fuel 6.0 has an ability to deploy either a KVM-oriented
>> environment or a VMware vCenter-oriented environment. We wants to go
>> further and mix them together. A user should be able to run both
>> hypervisors in one OpenStack environment. We want to get it in Fuel 6.1.
>> Here is how we gonna do this.
>> * When vCenter is used as a hypervisor the only way to use volumes with
>> it is to use Cinder VMDK backend. And vise versa, KVM cannot operate with
>> the volumes provided by Cinder VMDK backend. All that means that we should
>> have two separe infrastructures (a hypervisor + a volume service) for each
>> HV presented in environment. To do that we decided to place corresponding
>> nova-compute and cinder-volume instances into different Availability Zones.
>> Also we want to disable 'cross_az_attach' option in nova.conf to restrict a
>> user to mount a volume to an instance which doesn't support this volume
>> type.
>> * A cinder-volume service is just a proxy between vCenter Datastore and
>> Glance when used with VMDK. It means that the service itself doesn't need a
>> local hard drive but sometimes can significantly consume network. That's
>> why it's not a good idea to always put it to a Controller node. So, we want
>> to add a new role called 'cinder-vmdk'. A user will be able to put this
>> role to whatever node he wants: a separate node or combine with other
>> roles. HA will be achieved by placing the role on two or more nodes.
>> Cinder-volume services on each node will be configured identicaly,
>> including 'host' stanza. We have the same approach now for Cinder+Ceph.
>> * Nova-compute services for vCenter are kept running on Controller nodes.
>> They are managed by Corosync.
>> * There are two options for network backend exist. A good old
>> Nova-network and a modern Neutron with ML2 DVS driver enabled. The problem
>> with Nova-network is that we have to run it in 'singlehost' mode. It means,
>> that the only nova-network service will be running for the whole
>> environment. It makes the service a single point of failure, prevents a
>> user to use Security Groups, and increases a network consuming for the node
>> where the service is running. The problem with Neutron is that there is no
>> ML2 DVS driver in an upstream Neutron for Juno and even Kilo. The is an
>> unmerged patch [1] with almost no chances to get in Kilo. Good news are
>> that we managed to run a PoC lab with this driver and both HVs enabled. So,
>> we can build the driver as a package but it'll be a little ugly. That's why
>> we picked the Nova-network approach as a basis. In Cluster creation wizard
>> will be something to choose if you want to use vCenter in a cluster or not.
>> Depending on it the nova-network service will be run in the 'singlenode' or
>> 'multinode' mode. May be, if we have enough resources we'll implement a
>> Neutron + vDS support also.
>> * We are going to move all VMWare-specific settings to a separate UI tab.
>> On the Settings tab we will keep a Glance backend switch (Swift, Ceph,
>> VMware) and a libvirt_type switch (KVM, qemu). At the cluster creation
>> wizard there will be a checkbox called 'add a VMware vCenter support into
>> your cloud'. When it's enabled a user can choose nova-network only.
>> * OSTF test suit will be extended to support separate sets of tests for
>> each HV.
>> [1] Neutron ML2 vDS driver https://review.openstack.org/#/c/111227/
>> Links to blueprints:
>> https://blueprints.launchpad.net/fuel/+spec/vmware-ui-settings
>> https://blueprints.launchpad.net/fuel/+spec/cinder-vmdk-role
>> https://blueprints.launchpad.net/fuel/+spec/vmware-dual-hypervisor
>> I would appreciate to see your thoughts about all that.
>> --
>> Andrey Danin
>> adanin at mirantis.com
>> skype: gcon.monolake
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
> Kevin Benton
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Andrey Danin
adanin at mirantis.com
skype: gcon.monolake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150124/6b2d1c96/attachment.html>

More information about the OpenStack-dev mailing list