[openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..

Vishvananda Ishaya vishvananda at gmail.com
Wed Mar 26 16:47:55 UTC 2014

Personally I view this as a bug. There is no reason why we shouldn’t support arbitrary grouping of zones. I know there is at least one problem with zones that overlap regarding displaying them properly:


There is probably a related issue that is causing the error you see below. IMO both of these should be fixed. I also think adding a compute node to two different aggregates with azs should be allowed.

It also might be nice to support specifying multiple zones in the launch command in these models. This would allow you to limit booting to an intersection of two overlapping zones.

A few examples where these ideas would be useful:

1. You have 3 racks of servers and half of the nodes from each rack plugged into a different switch. You want to be able to specify to spread across racks or switches via an AZ. In this model you could have a zone for each switch and a zone for each rack.

2. A single cloud has 5 racks in one room in the datacenter and 5 racks in a second room. You’d like to give control to the user to choose the room or choose the rack. In this model you would have one zone for each room, and smaller zones for each rack.

3. You have a small 3 rack cloud and would like to ensure that your production workloads don’t run on the same machines as your dev workloads, but you also want to use zones spread workloads across the three racks. Similarly to 1., you could split your racks in half via dev and prod zones. Each one of these zones would overlap with a rack zone.

You can achieve similar results in these situations by making small zones (switch1-rack1 switch1-rack2 switch1-rack3 switch2-rack1 switch2-rack2 switch2-rack3) but that removes the ability to decide to launch something with less granularity. I.e. you can’t just specify ‘switch1' or ‘rack1' or ‘anywhere’

I’d like to see all of the following work
nova boot … (boot anywhere)
nova boot —availability-zone switch1 … (boot it switch1 zone)
nova boot —availability-zone rack1 … (boot in rack1 zone)
nova boot —availability-zone switch1,rack1 … (boot


On Mar 25, 2014, at 1:50 PM, Sangeeta Singh <singhs at yahoo-inc.com> wrote:

> Hi,
> The availability Zones filter states that theoretically a compute node can be part of multiple availability zones. I have a requirement where I need to make a compute node part to 2 AZ. When I try to create a host aggregates with AZ I can not add the node in two host aggregates that have AZ defined. However if I create a host aggregate without associating an AZ then I can add the compute nodes to it. After doing that I can update the host-aggregate an associate an AZ. This looks like a bug.
> I can see the compute node to be listed in the 2 AZ with the availability-zone-list command.
> The problem that I have is that I can still not boot a VM on the compute node when I do not specify the AZ in the command though I have set the default availability zone and the default schedule zone in nova.conf.
> I get the error “ERROR: The requested availability zone is not available”
> What I am  trying to achieve is have two AZ that the user can select during the boot but then have a default AZ which has the HV from both AZ1 AND AZ2 so that when the user does not specify any AZ in the boot command I scatter my VM on both the AZ in a balanced way.
> Any pointers.
> Thanks,
> Sangeeta
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140326/81f39f2e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140326/81f39f2e/attachment.pgp>

More information about the OpenStack-dev mailing list