Skip to main content

Posts

Showing posts from February, 2015

Customising the Link attribute in Horizon dashboard's DataTable

I had a quick dab at Django & Openstack Horizon frameworks in order to build a dashboard for one of our Openstack projects. Our requirement was to show a table on the UI with the corresponding CRUD functions. I had used DataTable for this purpose, where in you define the table structure in tables.py and the view rendering is defined in views.py If a column is defined to be a link, DataTable by default uses the object id of each row to generate the corresponding link. In my scenario, I needed the link to point to a different object. Openstack's documentation was not very helpful and a quick grep through the openstack's code gave me the idea. The approach to generate a custom link is as follows inside a DataTable: from django.core.urlresolvers import reverse def get_custom_link(datum):     return reverse('horizon:myproject:mydashboard:detail', kwargs={'key': datum.value}) The value of the key will be used to generate the URL.

QuickBite: Tap Vs Veth

Linux supports virtual networking via various artifacts such as: Soft Switches (Linux Bridge, OpenVSwitch) Virtual Network Adapters (tun, tap, veth and a few more) In this blog, we will look at the virtual network adapters tap and veth. From a practical view point, both seem to be having the same functionality and its a bit confusing as to where to use what. A quick definition of tap/veth is as follows: TAP A TAP is a simulated interface which exists only in the kernel and has no physical component associated with it. It can be viewed as a simple Point-to-Point or Ethernet device, which instead of receiving packets from a physical media, receives them from user space program and instead of sending packets via physical media writes them to the user space program. When a user space program (in our case the VM) gets attached to the tap interface it gets hold of a file descriptor, reading from which gives it the data being sent on the tap interface. Writing to the file descri

Openstack : Unable to connect to instance console at port 6080

I have a VM on virtualbox which acts as an all-in-one Openstack setup. When I spawn a VM on it the VM boots up fine but from the browser I am not able to access its console. There are various ways to solve this issue: 1. In the latest version of devstack (as on February 2015) n-novnc is no longer a default service and needs to be added to the local.conf to enable it. enabled_services=n-novnc  ( https://ask.openstack.org/en/question/57993/dashboard-vnc-console-doesnt-work-on-devstack/ ) 2. See if this helps you in tweaking manually : http://docs.openstack.org/admin-guide-cloud/content/nova-vncproxy-replaced-with-nova-novncproxy.html 3.Another geeky solution is that, you can grep the KVM process to figure out the port on which the VNC is getting channeled to and access the console. openstack@Openstack-Server:~/devstack$ ps aux|grep qemu|grep vnc libvirt+  9167  0.6  2.4 1504044 97488 ?       Sl   14:25   0:49 /usr/bin/qemu-system-x86_64 -name instance-00000001 -S -machine

QuickBite: Avoid Fedora qcow download during Devstack installation

While installing the latest devstack, I found that it downloads Fedora's qcow image as a part of heat installation : https://download.fedoraproject.org/pub/alt/openstack/20/x86_64/Fedora-x86_64-20-20140618-sda.qcow2. Its a 200MB file and is definitely not needed for Neutron related development. I see that there is an option in local.conf which will make it stick to the default Cirros. You can do it by setting the below config in local.conf: IMAGE_URLS=" http://download.cirros-cloud.net/0.3.3/cirros-0.3.3-x86_64-uec.tar.gz " This downloads the latest 0.3.3 series image of Cirros. At a later point, you can visit http://download.cirros-cloud.net/ and download the latest version as shown there.

How to run Juniper Firefly (vSRX) on KVM -- SRX in a box setup

Juniper has released a virtual form factor SRX called Firefly Perimeter (vSRX). It provides security and networking features of the SRX Series Gateways in a virtual machine format. It can be spawned as a VM on a KVM+QEMU/VMWare hypervisor running on a X86 server. This post will give details on how to set it up as a standalone SRX box which can be used in any of your network deployments just like a normal SRX. Pre-requisites Have an X86 server with atleast 4 GB ram, 4 GB harddisk space and two ethernet ports. Install Ubuntu 14.04 on it (Centos should also work provided KVM related changes are taken care of) Assumption: You have logged into the system as root user. Get the Software Firefly Perimeter can be download as a part of Juniper's software evaluation program and can be tried out for 60 days. You will need a Juniper account to download it here . For the purpose of this post I will be using the appliance at "Firefly KVM Appliance - FOR EVALUATION ". Configure

QuickBite : Verifying VLAN Tag using Wireshark CLI (tshark)

If you want to verify the flow of packets from a VM (which is connected to a OVS) to a Switch and ensure that they are getting tagged properly, you can follow the process mentioned below: Step 1 : Are packets getting sent over eth1 Looks good. We can see that packets are getting sent over eth1. Step 2 : Check if packets are being received on ge-0/0/10 Looks good. If you see that packet count is not increasing on the interface, it may be because the corresponding VLAN is not associated with that interface (or the packet is being sent with out the VLAN tag) Check ge-0/0/10 configuration: Looks good. Step 3 : Lets check if packets are getting tagged when sent over eth1 [I have Wireshark installed on CentOS. Am using the Wireshark CLI as my server does not have gui installed on it] Done. You are now ready to trouble shoot basic packet flow. A few other commands that come in handy on a VM are: To check the routes known to the system : route -n To ch