Optimized Placement of Windows Instances in OpenStack Havana

Introduction

Microsoft SPLA license requires a cloud provider to license all cores of the physical host running a Windows VM. Since the default scheduling algorithm in OpenStack distributes VMs evenly across all hosts, Windows VMs would be spread randomly, therefore all cores would need to be SPLA licensed. A more cost-efficient and license-optimised placement algorithm for Windows images must be found. The goal is to analyze current OpenStack Havana features for such advanced grouping and placement mechanisms.

OpenStack Placement Options

Some further reasons for segregation or grouping of VMs and workloads can be:

  • geographic placement
  • host capabilities (e.g. all hosts with SSDs)
  • affinity/anti-affinity features (e.g. all VMs within same network on same host)

OpenStack provides multiple ways to segregate or group hosts and workloads:

  • Cells
  • Regions
  • Availability zones
  • Host aggregates
  • Filter Scheduler

Where as cells and regions are used for running the cloud in a discrete distributed fashion, i.e. utilize multiple data centers, availability zones and host aggregates are used for partitioning within a single data center. Filter Scheduler provides a more fine-grained option for VM placement.

Availability Zones

Availability zones are designed for users to be able to choose where to host their virtual machines. In order to utilize a availability zones, the user must use the availability-zone flag when creating an instance, as in:

Host Aggregates

Host aggregates are intended as a way to group servers that have a particular quality to them e.g. “all hosts using solid-state drives,” or “all hosts with trusted hardware” (for secure applications). They serve as an intelligent way for schedulers to know where to place VM’s based on some sort of characteristic. In order to utilize this feature:

  1. a host aggregate must be created
  2. metadata must be associated to the aggregate e.g. windows=true
  3. a host must be associated to the aggregate
  4. optional: a new flavor can be created e.g. nova flavor-create windows.large 6 8192 80 4
  5. metadata must be associated to flavor e.g. nova flavor-key set_key –name=windows.large  –key=windows –value=true

Now, when a user requests an instance with the windows.large flavor, the scheduler only considers hosts with the windows=true key-value pair.

Filter Scheduler

The Filter Scheduler (nova.scheduler.filter_scheduler.FilterScheduler) is the default scheduler for scheduling virtual machine instances. It supports filtering and weighting to make informed decisions on where a new instance should be created. When the Filter Scheduler receives a request for a resource, it first applies filters to determine which hosts are eligible for consideration when dispatching a resource. Filters are binary: either a host is accepted by the filter, or it is rejected. Hosts that are accepted by the filter are then processed by a different algorithm to decide which hosts to use for that request, implemented by the weighting feature (see Figure 1).

Filtering and Weighting
Fig.1: Filtering and Weighting (Source: http://docs.openstack.org/havana/config-reference/content/figures/5/a/a/common/figures/filteringWorkflow1.png)

The scheduler_available_filters configuration option in nova.conf provides the Compute service with the list of the filters that are used by the scheduler. The default setting specifies all of the filters that are included with the Compute service:

This configuration option can be specified multiple times. For example, if implementing an own custom filter in Python called myfilter.MyFilter and wanting to use both the built-in filters and the custom filter, nova.conf file would contain:

The scheduler_default_filters configuration option in nova.conf defines the list of filters that are applied by the nova-scheduler service. The default filters are:

The appropriate filter for optimized placement of Windows instances is the IsolatedHostsFilter

IsolatedHostsFilter

The IsolatedHostsFilter allows the admin to define a special (isolated) set of images and a special (isolated) set of hosts, such that the isolated images can only run on the isolated hosts, and the isolated hosts can only run isolated images. The admin must specify the isolated set of images and hosts in the nova.conf file using the isolated_hosts and isolated_images configuration options. For example:

In order not to restrict the isolated hosts to a set of isolated images, the flag “restrict_isolated_hosts_to_isolated_images” can be added to nova.conf. If it’s set to true then the filter acts like the default one, if set to false the isolated hosts can run every image, but isolated images must be run on isolated hosts. By default it is set to true. The correct scheduler_default_filters configuration option in nova.conf would be:

Create default ‘root’ user for MySQL

Recently, I had the issue that the MySQL ‘root’ user could not log into the data base:

The root cause was not that a wrong password was used or the user ‘root’ had no access rights. The root cause was that the user ‘root’ was not existing in the mysql.user table. In fact, the whole user table was empty. So the default ‘root’ user needs to be recreated again.

In order to log into MySQL without a user and password, MySQL needs to be restarted with the --skip-grant-tables option.

Then log into MySQL

The usual CREATE USER command will not work here as this command would also set default permissions, however starting MySQL without grant tables will not allow you to set permissions. So the user ‘root’ needs to manually inserted into the mysql.user table, along with all privileges.

Newer versions of MySQL might contain more privileges so make sure that all have been updated (all ‘*_priv’ columns contain a ‘Y’).

Then quit the database console, kill the mysqld_safe daemon, start the standard mysql daemon and test it again.

The default ‘root’ user has now been restored and access with a password should be possible again!

Tired of multiple “fake” email addresses?

Honestly, how many fake, forgotten, or abandoned email addresses have owned within your internet era? Whether for registering to a forum you only need once, selling an item on craigslist, signing up for a trial software or registering to an online dating service your wife should never find out about, we’ve all had to use our creative mind to come up with new, randomized email addresses that look more like a ciphering code than an actual word or name (bs77flat01@hotmail.com).

No need for that anymore, thanks to – you guessed right – Google!

Gmail supports sub-addressing (RFC5233) of emails. Messages can be sent to addresses in the format username+extratext@gmail.com, where extratext can be any string, and will arrive in the inbox of username@gmail.com.

Gmail also does not recognize dots as characters within a username. Instead, it will ignore all dots in a username. For instance, the account google@gmail.com receives mail sent to goo.gle@gmail.com, g.o.o.g.l.e@gmail.com, etc. This allows users to sign up for different services with different aliases and then easily filter, delete, apply a label or create a rule from all emails from those services. In addition, should users start to receive spam messages that are directed to their email address with the extra text or dots, they will know what services have leaked out their email address to others.