Modifying virtual machine images

What to do when you have a virtual machine image and for a example you need to some files contents like ssh config or so? Modified images can be uploaded to glance – repeating same step after running several VMs of the same type can be easily avoided in this way.

There are few tools that can be used for that purpose and are extremely powerful (most importantly, these are usually run in place :

Example – install wireshark & nmap in an RHEL minimal install image (we assume there is Internet access from a machine running virt-customize command) – below is basically running locally a VM, modifying it and saving the changes to the image.

Example – modify ssh server config. Following edits a file in a filesystems and saves the changes to the image.

Guestfish gives access to the filesystem – it is more powerful the virt-edit in a sense that it allows browsing through the filesystems rather than modifying a file that you know a path for. You can also create new files and add contents to them. Example sequence of step to perform is as follows:


2) guestfish -a <qcow2/img>

3) run

4) list-filesystems

5) mount <root_filesystem> /

6) modify files

7) umount /

8) exit

Increase LV size of a qcow2 image

When you get a qcow2 image with a given size – it can’t be simply changed on-the-fly while running a VM or by giving just more space to a VM flavor in OpenStack. Situation gets even more complex when image has LVs inside but fortunately by using guestfish and virt-resize image can be suited to one’s needs. Below are the steps that I used to perform such modifications:

Default image: image-name-250G.qcow2
Resized: image-name-750G.qcow2

1. Check which device to resize (this image has LVM created PV on /dev/sda2):

2. Resize image (from 250 to 750GB) – resizing is NOT performed in place:

3. Resize disk and specific device (in this case it is /dev/sda2) and LVM PV:

4. Go to guestfish and use free space on VGS to create additional LV, create additional filesystem and mount point (DISABLE 64bit flag on EXT4, required by this image as it uses outdated e2fsck
that doesn’t support 64bit option):

5. Upload image to glance.

Automatically provisioning baremetal/VM server

During my endavours I had a situation where I had to provision 10 servers (install all of them manually and configure same things on all of them, same files etc).

There is a nice alternative to it called Stacki from StackIQ (bought by Teradata last year). What it offers is specialized PXE server that is used to boot baremetal/VM servers (CentOS/Redhat/Ubuntu). 

Its architecture look as follows (Stacki server == Frontend, server to be provisioned == backend):

Firstly in CSV file you prepare a list of hosts with their MACs and as a next step you add puppet that will be used to provision the servers after booting.

More can be found here:

Frontend machine can be a VM – actually it worked pretty nice – tested with provisioning other VMs.

Kill a hanging machine in VMware ESXi

It might not be possible to kill a “running” (in reality hanging) VM from Vcenter GUI or using vSphere Client. 

In such situation a login via SSH to ESXi host is needed, list all VMs and kill the appropriate one.

Connecting over SSH and running a command over NETCONF

When HW/virtualized/containerized network element offers NETCONF interface to manage, it is extremely beneficial to use it for repetitive tasks (upgrades, sanity checking, route table checking etc).

NETCONF can be used over different transports as below:

In case SSH is used then it must be made sure that SSH subsystem is enabled in SSH config on a device. 

If a YANG model is available then TailF offers a client and Java class generator under:

Alternatively, as in the example below, Python can be used to manually connect over SSH and based on YANG model (if used) instruct the device to perform a specific task.

There is a library in Python for that purpose called ncclient (NETCONF client):

Firstly we need to do the proper import in our client script after installing the library:

Let’s define method used for connecting to the device:

Create an object class that inherits from RPC class of ncclient library and define a method that will be compose an XML NETCONF message based on YANG model:

Connect to the device and perform requested action (probably not the safest way to use clear text password to connect):

The request in NETCONF formatted XML would look as follows:

And a corresponding YANG model:

Lastly in XML:

Juniper Contrail – how to check Next-Hop

One might need to check which MPLSoGRE/UDP/VXLAN tunnel is used to reach a specific prefix on a vrouter.

There are few steps needed to find it out after logging in to a compute node running a VM/contrainer with an interface of interest (its prefix or prefix reachable via it) :

    1. List all interfaces and see which vrouter VRF a specific interface maps to:

    2. Use the VRF id to dump routes in a routing table for this VRF and check a prefix in question and its next-hop id:

    3. Check next-hop id parameters with:

Inter-AS Option B between Juniper routers

Recently I stumbled on a topic related to interconnecting 2 Juniper routers with Inter-AS Option B. 

With this kind of connectivity it is not enough to have control plane working properly i.e. prefixes exchanged and visible in appropriate routing-instances on both ends – for data plane to work you need to have next-hop resolved – and it is implicit in case E-BGP peering is sourced with interface address. In case loopback is used as a source you need to have it resolved by:

  • either a LSP between the two ASBR (actually no label required, but it must appear in inet.3, it can even be a static dummy LSP)
  • or configure routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 which will allow L3VPN routes to be resolved in inet.0 instead of inet.3

More details can be found on the Juniper forum where I found the solution:


There are also 2 useful commands that can be used for troubleshooting next-hop connectivity

Heat templates with cinder volumes

While trying to launch several VMs using heat templates on RHEL OpenStack Liberty only 2 out of 8 launched. Rest failed because cinder volumes could not be created. 

heat stack status was CREATE_FAILED and cinder volume status was error


For a brief moment there was some log on a console related to haproxy failure

While checking the services I noticed that both haproxy and swift-proxy are not running so just decided to restart them

systemctl restart haproxy.service

systemctl start openstack-swift-proxy.service

After that I could again create cinder volumes via heat templates. So be careful – create VMs from templates with cinder one by one