[ English | 한국어 (대한민국) | English (United Kingdom) | Indonesia | français | русский | Deutsch ]
Verwalten Sie Ihre Cloud¶
In diesem Kapitel werden OpenStack-Vorgangsaufgaben dokumentiert, die für die Operationsunterstützung in einer OpenStack-Ansible-Bereitstellung von wesentlicher Bedeutung sind.
Es erläutert Vorgänge wie die Verwaltung von Abbildern, Instanzen oder Netzwerken.
[ English | 한국어 (대한민국) | English (United Kingdom) | Indonesia | français | русский | Deutsch ]
Abbilder verwalten¶
Ein Abbild stellt das Betriebssystem, die Software und alle Einstellungen dar, die Instanzen abhängig von den Projektzielen benötigen. Erstellen Sie zuerst Abbilder, bevor Sie Instanzen erstellen.
Das Hinzufügen von Abbildern kann über das Dashboard oder die Befehlszeile erfolgen. Eine andere verfügbare Option ist das Tool python-openstackclient, das auf dem Controller-Knoten oder auf einer Workstation installiert werden kann.
Hinzufügen eines Abbildes mit dem Dashboard¶
Um ein Abbild über das Dashboard hinzuzufügen, bereiten Sie eine Image-Binärdatei vor, auf die über HTTP mit einer gültigen und direkten URL zugegriffen werden muss. Abbilder können mit .zip oder .tar.gz komprimiert werden.
Bemerkung
Das Hochladen von Abbildern über das Dashboard steht Benutzern mit Administratorrechten zur Verfügung. Bediener können Benutzerzugriffsrechte festlegen.
Melden Sie sich am Dashboard an.
Wählen Sie im Navigationsbereich die Registerkarte Admin und klicken Sie auf Abbilder.
Klicken Sie auf die Schaltfläche Abbild erstellen. Das Dialogfeld Abbild erstellen wird angezeigt.
Geben Sie die Details des Abbildes ein, einschließlich Abbildort, wo der URL-Ort des Abbildes benötigt wird.
Klicken Sie auf die Schaltfläche Abbild erstellen. Das neu erstellte Abbild kann einige Zeit dauern, bis es vollständig hochgeladen wurde, da das Abbild in einer Abbildwarteschlange eintrifft.
Hinzufügen eines Abbildes über die Befehlszeile¶
Der Dienstprogrammcontainer stellt eine CLI-Umgebung für zusätzliche Konfiguration und Verwaltung bereit.
Zugriff auf den Dienstprogrammcontainer:
$ lxc-attach -n `lxc-ls -1 | grep utility | head -n 1`
Verwenden Sie den Openstack-Client im Dienstprogrammcontainer, um alle flüchtigen Abbilder zu verwalten. Lesen Sie die offizielle Dokumentation des Openstack-Clients zum Verwalten von Abbildern.
[ English | 한국어 (대한민국) | English (United Kingdom) | Indonesia | français | русский | Deutsch ]
Instanzen verwalten¶
In diesem Kapitel wird beschrieben, wie Sie Instanzen erstellen und darauf zugreifen.
Erstellen einer Instanz mithilfe des Dashboards¶
Erstellen Sie mithilfe eines Abbildes eine neue Instanz über die Dashboard-Optionen.
Melden Sie sich am Dashboard an und wählen Sie das Projekt Compute aus der Dropdown-Liste aus.
Klicken Sie auf die Option Abbilder.
Suchen Sie das Abbild, das als Instanzbasis dienen soll, aus der Tabelle Abbilder.
Klicken Sie in der Spalte Aktionen auf Starten.
Überprüfen Sie das Dialogfeld Instanzen starten und finden Sie die Registerkarte Details. Geben Sie die entsprechenden Werte für die Instanz ein.
Klicken Sie im Dialogfeld Instanz starten auf die Registerkarte Access & Security. Wählen Sie das Schlüsselpaar aus. Legen Sie die Sicherheitsgruppe als „default“ fest.
Klicken Sie auf den Tab Netzwerk. Diese Registerkarte ist nicht verfügbar, wenn das OpenStack-Netzwerk (Neutron) nicht aktiviert wurde. Wenn das Netzwerk aktiviert ist, wählen Sie die Netzwerke aus, in denen sich die Instanz befinden soll.
Klicken Sie auf die Registerkarte Datenträger-Optionen. Diese Registerkarte ist nur verfügbar, wenn ein Blockspeicherdatenträger für die Instanz vorhanden ist. Wählen Sie jetzt Nicht von einem Datenträger booten.
Weitere Informationen zum Anhängen von Blockspeicher-Datenträger an Instanzen für dauerhaftes Speichern finden Sie im Abschnitt Managing volumes for persistent storage weiter unten.
Fügen Sie bei Bedarf benutzerdefinierte Skripts hinzu, indem Sie auf die Registerkarte Post-Creation klicken. Diese werden ausgeführt, nachdem die Instanz erstellt wurde. Einige Instanzen unterstützen Benutzerdaten, z.B. Root-Kennwörter oder Admin-Benutzer. Geben Sie hier gegebenenfalls die für die Instanz spezifischen Informationen ein.
Klicken Sie auf Erweiterte Optionen. Geben Sie an, ob die Instanz ein Konfigurationslaufwerk zum Speichern von Metadaten verwendet, indem Sie einen Festplattenpartitionstyp auswählen.
Klicken Sie auf Starten, um die Instanz zu erstellen. Die Instanz wird auf einem Rechenknoten gestartet. Die Seite Instanz wird geöffnet und beginnt mit dem Erstellen einer neuen Instanz. Die geöffnete Seite Instance listet den Instanznamen, die Größe, den Status und die Aufgabe auf. Energiezustand und öffentliche und private IP-Adressen sind hier ebenfalls aufgeführt.
Der Vorgang dauert weniger als eine Minute. Die Instanzerstellung ist abgeschlossen, wenn der Status als aktiv aufgeführt ist. Aktualisieren Sie die Seite, um die neue aktive Instanz zu sehen.
Starten einer Instanz Optionen¶ Feldname
Erforderlich
Einzelheiten
Verfügbarkeitszone
Wahlweise
Die Verfügbarkeitszone, in der der Abbild-Dienst die Instanz erstellt. Wenn keine Verfügbarkeitszonen definiert sind, werden keine Instanzen gefunden. Der Cloud-Anbieter legt die Verfügbarkeitszone auf einen bestimmten Wert fest.
Instanzname
Erforderlich
Der Name der neuen Instanz, die zum anfänglichen Hostnamen des Servers wird. Wenn der Servername in der API geändert oder direkt geändert wird, bleiben die Dashboard-Namen unverändert
Abbild
Erforderlich
Die Art des Containerformats, eines von
ami,ari,aki,blankoderovfVariante
Erforderlich
Die vCPU-, Speicher- und Festplattenkonfiguration. Beachten Sie, dass die Erstellung größerer Varianten lange dauern kann. Wenn Sie eine Instanz zum ersten Mal erstellen und etwas Kleines zum Testen möchten, wählen Sie
m1.small.Instanzanzahl
Erforderlich
Wenn Sie mehrere Instanzen mit dieser Konfiguration erstellen, geben Sie eine ganze Zahl ein, die der Quote entspricht, die durch das Kontingent zulässig ist (standardmäßig
10).Instanzstartquelle
Erforderlich
Geben Sie an, ob die Instanz auf einem Abbild oder einem Snapshot basieren soll. Wenn Sie zum ersten Mal eine Instanz erstellen, sind noch keine Snapshots verfügbar.
Abbildname
Erforderlich
Die Instanz startet von dem ausgewählten Abbild. Diese Option wird mit der aus der Tabelle ausgewählten Instanz vorbelegt. Wählen Sie jedoch
Boot from Snapshotin Instance Boot Source und stattdessenSnapshot.Sicherheitsgruppen
Wahlweise
Diese Option weist Sicherheitsgruppen einer Instanz zu. Die Standardsicherheitsgruppe wird aktiviert, wenn hier keine benutzerdefinierte Gruppe angegeben wird. Sicherheitsgruppen definieren ähnlich wie eine Cloud-Firewall, welcher eingehende Netzwerkverkehr an Instanzen weitergeleitet wird.
Schlüsselpaar
Wahlweise
Geben Sie ein Schlüsselpaar mit dieser Option an. Wenn das Abbild einen statischen Schlüsselsatz verwendet (nicht empfohlen), wird kein Schlüsselpaar benötigt.
Ausgewählte Netzwerke
Wahlweise
Um ein Netzwerk zu einer Instanz hinzuzufügen, klicken Sie auf + im Feld Netzwerke.
Anpassungs-Skript
Wahlweise
Geben Sie ein Anpassungsskript an. Dieses Skript wird ausgeführt, nachdem die Instanz gestartet wurde und aktiv wird.
Erstellen einer Instanz über die Befehlszeile¶
In der Befehlszeile wird die Instanzerstellung mit dem Befehl openstack server create verwaltet. Bevor Sie eine Instanz starten, bestimmen Sie mithilfe der Befehle openstack image list und openstack flavour list, welche Abbilder und Varianten verfügbar sind, um eine neue Instanz zu erstellen.
Melden Sie sich bei einem beliebigen Dienstprogrammcontainer an.
Geben Sie den Befehl openstack server create mit einem Namen für die Instanz zusammen mit dem Namen des zu verwendenden Abbilds und Variante ein:
$ openstack server create --image precise-image --flavor 2 --key-name example-key example-instance +-------------------------------------+--------------------------------------+ | Property | Value | +-------------------------------------+--------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | instance-0000000d | | OS-EXT-STS:power_state | 0 | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | accessIPv4 | | | accessIPv6 | | | adminPass | ATSEfRY9fZPx | | config_drive | | | created | 2012-08-02T15:43:46Z | | flavor | m1.small | | hostId | | | id | 5bf46a3b-084c-4ce1-b06f-e460e875075b | | image | precise-image | | key_name | example-key | | metadata | {} | | name | example-instance | | progress | 0 | | status | BUILD | | tenant_id | b4769145977045e2a9279c842b09be6a | | updated | 2012-08-02T15:43:46Z | | user_id | 5f2f2c28bdc844f9845251290b524e80 | +-------------------------------------+--------------------------------------+Um zu überprüfen, ob die Instanz erfolgreich erstellt wurde, geben Sie den Befehl openstack server list ein:
$ openstack server list +------------------+------------------+--------+-------------------+---------------+ | ID | Name | Status | Networks | Image Name | +------------------+------------------+--------+-------------------+---------------+ | [ID truncated] | example-instance | ACTIVE | public=192.0.2.0 | precise-image | +------------------+------------------+--------+-------------------+---------------+
Verwalten einer Instanz¶
Melden Sie sich am Dashboard an. Wählen Sie eines der Projekte und klicken Sie auf Instanzen.
Wählen Sie eine Instanz aus der Liste der verfügbaren Instanzen.
Überprüfen Sie die Spalte Aktionen und klicken Sie auf die Option Mehr. Wählen Sie den Instanzstatus aus.
Die Spalte Aktionen enthält die folgenden Optionen:
Ändern Sie die Größe einer Instanz oder erstellen Sie sie neu
Zeigen Sie das Protokoll der Instanzkonsole an
Bearbeiten Sie die Instanz
Ändern Sie Sicherheitsgruppen
Die Instanz pausieren, fortsetzen oder anhalten
Weiches oder hartes Zurücksetzen der Instanz
Bemerkung
Beenden Sie die Instanz in der Spalte Aktionen.
Managing volumes for persistent storage¶
Datenträger werden an Instanzen angehängt, wodurch dauerhafter Speicher aktiviert wird. Der Datenträgerspeicher stellt eine Speicherquelle für Instanzen bereit. Administratoren können Datenträger einer laufenden Instanz anhängen oder ein von einer Instanz zu einer anderen verschieben.
Nova-Instanzen Live-Migration¶
Nova ist in der Lage, Live-Migrationsinstanzen von einem Host zu einem anderen Host zu unterstützen, um verschiedene operative Aufgaben zu unterstützen, darunter:
Host-Wartung
Host-Kapazitätsverwaltung
Ändern der Größe und Verschieben von Instanzen zu besserer Hardware
Nova Konfigurations-Laufwerk Implikation¶
Abhängig von der verwendeten OpenStack-Ansible-Version kann Nova so konfiguriert werden, dass Konfigurationslaufwerk-Anhänge für Instanzen erzwungen werden. In diesem Fall wird ein ISO9660-CD-ROM-Image für die Instanz über den Einhängepunkt /mnt bereitgestellt. Dies kann von Tools wie cloud-init verwendet werden, um auf Instanzmetadaten zuzugreifen. Dies ist eine alternative Möglichkeit, auf die Metadaten im Nova EC2-Stil zuzugreifen.
Um eine Live-Migration von Nova-Instanzen zu ermöglichen, muss diese erzwungene Bereitstellung des CD-ROM-Laufwerks entweder deaktiviert werden oder das Format des Konfigurationslaufwerks muss in ein Datenträgerformat wie vfat geändert werden, ein Format, das sowohl Linux als auch Windows-Instanzen können darauf zugreifen.
Diese Umgehung ist für alle Libvirt-Versionen vor 1.2.17 erforderlich.
Um die erzwungene Bereitstellung des Konfigurations-Laufwerks zu deaktivieren, fügen Sie der Datei /etc/openstack_deploy/user_variables.yml folgende Überschreibung hinzu:
nova_force_config_drive: False
Um das Format des Konfigurationslaufwerks in ein Festplattenstilformat zu ändern, verwenden Sie die folgende Konfiguration innerhalb der Datei /etc/openstack_deploy/user_variables.yml:
nova_nova_conf_overrides:
DEFAULT:
config_drive_format: vfat
force_config_drive: false
Tunnelling gegen direkten Transport¶
In der Standardkonfiguration ermittelt Nova die korrekte Transport-URL für die Übertragung der Daten von einem Host zum anderen. Abhängig von der nova_virt_type Überschreibung werden folgende Konfigurationen verwendet:
kvm verwendet standardmäßig
qemu+tcp://%s/systemqemu verwendet standardmäßig `` qemu+tcp://%s/system``
xen verwendet standardmäßig
xenmigr://%s/system
Libvirt TCP-Port zum Übertragen der zu migrierenden Daten.
OpenStack-Ansible ändert die Standardeinstellung und verwendet eine verschlüsselte SSH-Verbindung, um die Instanzdaten zu übertragen.
live_migration_uri = "qemu+ssh://nova@%s/system?no_verify=1&keyfile={{ nova_system_home_folder }}/.ssh/id_rsa"
Andere Konfigurationen können in der /etc/openstack_deploy/user_variables.yml Datei konfiguriert werden:
nova_nova_conf_overrides:
libvirt:
live_migration_completion_timeout: 0
live_migration_progress_timeout: 0
live_migration_uri: "qemu+ssh://nova@%s/system?keyfile=/var/lib/nova/.ssh/id_rsa&no_verify=1"
Ausführen der Migration¶
Die Livemigration ist über den nova-Client zugänglich.
nova live-migration [--block-migrate] [--force] <uuid> [<host>]
Beispielhafte Live Migration auf einem lokalen Speicher:
nova live-migration --block-migrate <uuid of the instance> <nova host>
Überwachung des Status¶
Sobald die Live-Migrationsanfrage angenommen wurde, kann der Status mit dem Novaclient überwacht werden:
nova migration-list
+-----+------------+-----------+----------------+--------------+-----------+-----------+---------------+------------+------------+------------+------------+-----------------+
| Id | Source Node | Dest Node | Source Compute | Dest Compute | Dest Host | Status | Instance UUID | Old Flavor | New Flavor | Created At | Updated At | Type |
+----+-------------+-----------+----------------+--------------+-----------+-----------+---------------+------------+------------+------------+------------+-----------------+
| 6 | - | - | compute01 | compute02 | - | preparing | f95ee17a-d09c | 7 | 7 | date | date | live-migration |
+----+-------------+-----------+----------------+--------------+-----------+-----------+---------------+------------+------------+------------+------------+-----------------+
Um die Liste zu filtern, können die Optionen --host oder --status verwendet werden:
nova migration-list --status error
In Fällen, in denen die Live-Migration fehlschlägt, müssen sowohl der Quell- als auch der Zielcomputerknoten auf Fehler überprüft werden. In der Regel reicht es aus, nur nach der UUID der Instanz zu suchen, um Fehler im Zusammenhang mit der Livemigration zu finden.
Andere Formen der Instanzmigration¶
Neben der Live-Migration bietet Nova die Möglichkeit, ganze Hosts in einer Online- (Live) oder Offline- (Cold-) Migration zu migrieren.
Die folgenden nova-Client-Befehle werden bereitgestellt:
host-evacuate-liveLive migriert alle Instanzen des angegebenen Hosts auf andere Hosts, wenn die Ressourcennutzung dies zulässt. Es empfiehlt sich, gemeinsam genutzten Speicher wie Ceph oder NFS für die Host-Evakuierung zu verwenden.
host-servers-migrateDieser Befehl ähnelt der Host-Evakuierung, migriert jedoch alle Instanzen vom angegebenen Host, während sie heruntergefahren werden.
resizeÄndert der Variante einer Nova-Instanz (erhöhen) während des Neustarts und migriert (kalt) die Instanz auf einen neuen Host, um den neuen Ressourcenanforderungen gerecht zu werden. Dieser Vorgang kann je nach Größe des Disk-Images sehr viel Zeit in Anspruch nehmen.
[ English | 한국어 (대한민국) | English (United Kingdom) | Indonesia | français | русский | Deutsch ]
Netzwerke verwalten¶
Betriebsüberlegungen wie Compliance können die Verwaltung von Netzwerken erforderlich machen. Zum Beispiel das Hinzufügen neuer Provider-Netzwerke zur OpenStack-Ansible Managed Cloud. Die folgenden Abschnitte sind die häufigsten administrativen Aufgaben, die zum Ausführen dieser Aufgaben beschrieben werden.
Weitere allgemeine Informationen zur Fehlerbehebung in Ihrem Netzwerk finden Sie im Kapitel Netzwerk-Fehlerbehebung im Betriebshandbuch.
Weitere Informationen zum Netzwerk finden Sie im Netzwerkhandbuch.
Hinzufügen von Provider-Bridges mithilfe neuer Netzwerkschnittstellen¶
Fügen Sie jedes Provider-Netzwerk zu Ihrer Cloud hinzu, um es OpenStack-Ansible und dem Betriebssystem mitzuteilen, bevor Sie die erforderlichen Playbooks ausführen können, um die Konfiguration abzuschließen.
OpenStack-Ansible-Konfiguration¶
Alle Provider-Netzwerke müssen der OpenStack-Ansible-Konfiguration hinzugefügt werden.
Editieren Sie die Datei /etc/openstack_deploy/openstack_user_config.yml und fügen Sie einen neuen Block unter dem Abschnitt provider_networks hinzu:
The container_bridge setting defines the physical network bridge used
to connect the veth pair from the physical host to the container.
Inside the container, the container_interface setting defines the name
at which the physical network will be made available. The
container_interface setting is not required when Neutron agents are
deployed on bare metal.
Make sure that both settings are uniquely defined across their provider
networks and that the network interface is correctly configured inside your
operating system.
group_binds define where this network need to attached to, to either
containers or physical hosts and is ultimately dependent on the network
stack in use. For example, Linuxbridge versus OVS.
The configuration range defines Neutron physical segmentation IDs which are
automatically used by end users when creating networks via mainly horizon and
the Neutron API.
Similar is true for the net_name configuration which defines the
addressable name inside the Neutron configuration.
This configuration also need to be unique across other provider networks.
Weitere Informationen finden Sie unter Konfigurieren Sie die Bereitstellung im OpenStack-Ansible-Bereitstellungshandbuch.
Aktualisieren des Knotens mit der neuen Konfiguration¶
Führen Sie die entsprechenden Playbooks aus, abhängig vom Abschnitt group_binds.
Wenn Sie zum Beispiel die Netzwerke aktualisieren, die eine Änderung an allen Knoten mit einem Linux-Bridge-Agenten erfordern, führen Sie Folgendes aus: Wenn Sie Infra-Knoten mit den Namen infra01, infra02 und infra03 haben, führen Sie Folgendes aus:
# openstack-ansible containers-deploy.yml --limit localhost,infra01,infra01-host_containers
# openstack-ansible containers-deploy.yml --limit localhost,infra02,infra02-host_containers
# openstack-ansible containers-deploy.yml --limit localhost,infra03,infra03-host_containers
Aktualisieren Sie dann die Neutron-Konfiguration.
# openstack-ansible os-neutron-install.yml --limit localhost,infra01,infra01-host_containers
# openstack-ansible os-neutron-install.yml --limit localhost,infra02,infra02-host_containers
# openstack-ansible os-neutron-install.yml --limit localhost,infra03,infra03-host_containers
Aktualisieren Sie dann ggf. Ihre Compute-Knoten.
Entfernen Sie Anbieterbrücken von OpenStack¶
Ähnlich wie beim Hinzufügen eines Provider-Netzwerks wird beim Entfernen derselbe Vorgang verwendet, jedoch in umgekehrter Reihenfolge. Die Neutron-Ports müssen vor dem Entfernen der OpenStack-Ansible-Konfiguration entfernt werden.
Zuweisung aller neutron floating IPs aufheben:
Bemerkung
Exportieren Sie das Neutron-Netzwerk, das als einzelne UUID entfernt werden soll.
export NETWORK_UUID=<uuid> for p in $( neutron port-list -c id --device_owner compute:nova --network_id=${NETWORK_UUID}| awk '/([A-Fa-f0-9]+-){3}/ {print $2}' ); do floatid=$( neutron floatingip-list -c id --port_id=$p | awk '/([A-Fa-z0-9]+-){3}/ { print $2 }' ) if [ -n "$floatid" ]; then echo "Disassociating floating IP $floatid from port $p" neutron floatingip-disassociate $floatid fi done
Entfernen Sie alle Neutron-Ports von den Instanzen:
export NETWORK_UUID=<uuid> for p in $( neutron port-list -c id -c device_id --device_owner compute:nova --network_id=${NETWORK_UUID}| awk '/([A-Fa-f0-9]+-){3}/ {print $2}' ); do echo "Removing Neutron compute port $p" neutron port-delete $p done
Entfernen Sie die Router-Ports und DHCP-Agenten von Neutron:
export NETWORK_UUID=<uuid> for line in $( neutron port-list -c id -c device_id --device_owner network:router_interface --network_id=${NETWORK_UUID}| awk '/([A-Fa-f0-9]+-){3}/ {print $2 "+" $4}' ); do p=$( echo "$line"| cut -d'+' -f1 ); r=$( echo "$line"| cut -d'+' -f2 ) echo "Removing Neutron router port $p from $r" neutron router-interface-delete $r port=$p done for agent in $( neutron agent-list -c id --agent_type='DHCP Agent' --network_id=${NETWORK_UUID}| awk '/([A-Fa-f0-9]+-){3}/ {print $2}' ); do echo "Remove network $NETWORK_UUID from Neutron DHCP Agent $agent" neutron dhcp-agent-network-remove "${agent}" $NETWORK_UUID done
Entferne das Neutron-Netzwerk:
export NETWORK_UUID=<uuid> neutron net-delete $NETWORK_UUID
Entfernen Sie das Provider-Netzwerk aus der Konfiguration
provider_networksder OpenStack-Ansible-Konfiguration/etc/openstack_deploy/openstack_user_config.ymlund führen Sie die folgenden Playbooks erneut aus:# openstack-ansible lxc-containers-create.yml --limit infra01:infra01-host_containers # openstack-ansible lxc-containers-create.yml --limit infra02:infra02-host_containers # openstack-ansible lxc-containers-create.yml --limit infra03:infra03-host_containers # openstack-ansible os-neutron-install.yml --tags neutron-config
Starten Sie einen Container für den Netzwerkagenten neu¶
Unter bestimmten Umständen, bei der Konfiguration oder bei temporären Problemen, muss ein bestimmter oder alle Neutronenagenten-Container neu gestartet werden.
Dies kann mit mehreren Befehlen erreicht werden:
Beispiel für das Neustarten von noch zugänglichen Containern.
In diesem Beispiel wird der Container mit dem Namen
neutron_agents_container_hostname_namevon innen gestartet:# ansible -m shell neutron_agents_container_hostname_name -a 'reboot'
Beispiel für das Neustarten eines einzelnen Containers im Abstand von 60 Sekunden:
# ansible -m shell neutron_agents_container -a 'sleep 60; reboot' --forks 1
Wenn der Container nicht antwortet, kann er vom physischen Netzwerkhost neu gestartet werden:
# ansible -m shell network_hosts -a 'for c in $(lxc-ls -1 |grep neutron_agents_container); do lxc-stop -n $c && lxc-start -d -n $c; done' --forks 1
