I have been working with Docker this past few months and ran into an interesting situation where all my experimentation with docker basically meant my machine was full of stopped containers and unused images filling up the drive space. I goggled around and found that there is no single “docker clean” command that will clean up all the curd on my machine. So after a 10-15 minute search I was able to identify these two commands that did the job for me.

docker rm $(docker ps -a -q --filter="status=exited") and docker rmi $(docker images -q -f dangling=true)

The both the commands use sub command to get a list of image or container IDs that I consider to remove and the rm/rmi removes those images/containers.

docker ps -a -q --filter="status=exited")
“docker ps” is to list containers,
“-a” means all containers even the ones that are not running anymore,
“-q” means quite mode, dont give all the details about the containers just the container ID and finally the filter
“–filter=”status=exited”, filters the result to only include containers that have the status exited, basically containers that are not running and most likely not needed anymore.

docker rmi $(docker images -q -f dangling=true)
“docker images” is to list images
“-q” same as above, for images
“-f” is the short for “–filter” same as above for images. And for images we are looking for images that currently not tagged, in docker world images that have been superseded and are dangling and can be removed.

Here is the full shell script that I now run every few days to clear everything out.

#!/bin/bash
set -e

echo "Deleting all stopped containers"
docker rm $(docker ps -a -q --filter="status=exited")

echo "Deleting all ‘untagged/dangling’ () images"
docker rmi $(docker images -q -f dangling=true)

Just to clarify, this is not a post on how to configure apache/nginx to proxy requests to iPython notebook server or a backend proxy.

This is when you have a iPython notebook server running on your laptop/desktop behind a corporate/school proxy/firewall and any web requests needs to go through such proxy. On bash shell you just export the env variable like this and its taken care off. However for a iPython server the env variables are not inherited from user bash profile.

You have to modify the iPython notebook server env. Create a file named 00-something.py under your .ipython notebook server profile and add the following:

For example:
vi /.ipython/profile_myserver/startup/00-startup.py

and add

import sys,os,os.path
os.environ['HTTP_PROXY']="http://proxy.example.com:port:80"
os.environ['HTTPS_PROXY']="http://proxy.example.com:port:443"

you confirm the env variables by running

%env in a cell and the output

{'CLICOLOR': '1',
'GIT_PAGER': 'cat',
'HOME': '/home/jay',
'HTTP_PROXY': 'http://proxy.example.com:80',
..

Next try
import requests
requests.get("http://google.com")

If you get a response [200] then you are all set.

I had a few of folks ask me about snmp configuration on 1000v last so am reusing the content I sent them for this post. This is basically a 5 minute configuration of Nexus 1000v SNMP monitoring with SolarWinds NPM.

Software Versions used:

Nexus 1000v version 4.0(4)SV1(3b)

Nexus 1000v version 4.0(4)SV1(4)

SolarWinds Orion NPM 10.2

Network Topology:
SolarWinds NPM was running in a VM on the same cluster as the VSM. Basically they were connected to the same physical Nexus 5020 and on the same vlan. So a very flat backend network topology and no firewall in between. before you begin make sure you can ping from Nexus 1000v to the NMS.

Configuration Steps:

Step 1.
Configure Nexus 1000v SNMP to send traps to the NMS.

Here we are using user xxxxxx to send traps to the NMS using management interface.
Continue reading

Note 1: Even though Cisco fully supports VUM based upgrades we generally recommend the CLI for VEM upgrades as it provides more granular control on what gets upgraded when.

Note 2: If you plan on manually upgrading the VEM modules make sure you have disabled VMware Update Manager (VUM) service so that it does not automatically roll back changes we make. Once the vem upgrade is complete we can start it back up.

Step 0 Run a “show mod” to check the status of the modules

switch#  show mod
Mod  Ports  Module-Type                       Model               Status
---  -----  --------------------------------  ------------------  ------------
1    0      Virtual Supervisor Module         Nexus1000V          active *
3    248    Virtual Ethernet Module           NA                  ok
4    248    Virtual Ethernet Module           NA                  ok
5    248    Virtual Ethernet Module           NA                  ok
6    248    Virtual Ethernet Module           NA                  ok

Mod  Sw               Hw
---  ---------------  ------
1    4.0(4)SV1(3b)     0.0
3    4.0(4)SV1(3b)     1.11
4    4.0(4)SV1(3b)     1.11
5    4.0(4)SV1(3b)     1.11
6    4.0(4)SV1(3b)     1.11 

Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
5    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA
6    02-00-0c-00-06-00 to 02-00-0c-00-06-80  NA

Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    172.16.165.55    NA                                    NA
3    172.16.165.91    dcedbaac-1dc0-11df-0000-00000000000e  172.16.165.91
4    172.16.165.92    dcedbaac-1dc0-11df-0000-00000000000d  172.16.165.92
5    172.16.165.93    dcedbaac-1dc0-11df-0000-00000000000c  172.16.165.93
6    172.16.165.94    dcedbaac-1dc0-11df-0000-00000000000b  172.16.165.94
* this terminal session

This is looking good, with one active VSM and multiple VEM modules and all running the same version.
Continue reading

Cisco Nexus team released the update to the Nexus 1000v product taking it to release 4.2(1) SV1(4). They did a great job of documenting the entire upgrade process both in docs and in a series of screencasts. Check it out it’s really worth your time.

However one obvious thing that they have missed so far is how to upgrade if your VSM is in standalone mode. Part of the problem is the Upgrade application (GUI) does not support standalone mode and the upgrade document does not address the manual upgrade (CLI) method for standalone VSM.

Here is a quick guide on how to upgrade your standalone VSM from 4.0(4) SV1(3, 3a, or 3b) to 4.2(1) SV1(4).

Before you start make sure you have run the pre-upgrade check script against your 1000v configuration to make sure you don’t run into the 7 configurations that are incompatible with Nexus 4.0.x to 4.2.x code.

Now the actual steps:

Step 0 Do a show mod and make sure you have already upgraded all the VEM modules. Remember this has changed from earlier releases. You HAVE to upgrade the VEM first and VSM second to upgrade to release 4.2(1) SV1(4).

show mod
Mod  Ports  Module-Type                       Model               Status
---  -----  --------------------------------  ------------------  ------------
1    0      Virtual Supervisor Module         Nexus1000V          active *
3    248    Virtual Ethernet Module           NA                  ok
4    248    Virtual Ethernet Module           NA                  ok
5    248    Virtual Ethernet Module           NA                  ok
6    248    Virtual Ethernet Module           NA                  ok

Mod  Sw                Hw
---  ----------------  ------------------------------------------------
1    4.0(4)SV1(3b)      0.0
3    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
4    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
5    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
6    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)

Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
5    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA
6    02-00-0c-00-06-00 to 02-00-0c-00-06-80  NA

Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    172.16.165.55    NA                                    NA
3    172.16.165.91    dcedbaac-1dc0-11df-0000-00000000000e  172.16.165.91
4    172.16.165.92    dcedbaac-1dc0-11df-0000-00000000000d  172.16.165.92
5    172.16.165.93    dcedbaac-1dc0-11df-0000-00000000000c  172.16.165.93
6    172.16.165.94    dcedbaac-1dc0-11df-0000-00000000000b  172.16.165.94

Continue reading