Busy Cinder volumes & Ceph
If you run into an issue where a Cinder volume you attached to a VM can not be deleted even after detaching it from the VM, and when you look into the logs you find something like ERROR cinder.volume.manager ……. Unable to delete busy volume. or WARNING cinder.volume.drivers.rbd ……… ImageBusy error raised while deleting rbd
Ceph RBD snapshots for an attached volume
You might find yourself in a scenario where you need to backup a CEPH volume attached to an Openstack Instance. CEPH snapshots come automatically to mind as the “state-in-time” solution. Once you take a CEPH snapshot, you can export it and backup the volume either as a physical file or at the file system level,
VM getting a DHCP address
DHCP requests are broadcast requests sent by the VM to its boradcast domain. If a DHCP server exists in this domain, it will respond back providing a DHCP IP lease following the DHCP protocol. In openstack, the same procedure is followed. A VM starts by sending its DHCP request to its boardcast domain which goes
Adding a new node to ceph
If you are expanding your ceph cluster with extra nodes. You will need to prepare the node to have ceph installed and prepare the OSDs to be part of the ceph cluster. In order to do this, you can use ceph-deploy to install ceph on the new nodes and prepare/activate the osds on it. The
VM to VM communication: different networks
So far we have only spoken about VM communication when they belong to the same network. But what happens when the VM has to communicate with another VM on a different network. The common rule of networking is that changing networks requires routing. This is exactly what neutron does to allow those kinds of VMs
VM to VM communication, same network, different compute hosts
In the last post, we spoke about VM to VM communication when they belong to the same network and happen to get deployed to the same host. This is a good scenario, but in a big openstack deployment, it’s unlikely that all your VMs belonging to the same network will end up on the same
VM to VM communication: Same network & same compute host
In a physical world, machines communicate with each other without routers when they belong to the same network. This is the same case with openstack, VMs communicate over the same network without routers. When two VMs belonging to the same network happen to get deployed on the same compute host, their logical diagram looks like
Traffic flows from an Openstack VM
As we mentioned in the last post, traffic flows through a set of Linux virtual devices/switches to reach its destination after leaving the VM. Outbound traffic goes downward while inbound traffic moves upwards. The flow of traffic from the VM goes through the following steps A VM generates traffic that goes through its internal vNIC
Neutron: How a VM communicates
In order to identify how a VM communicates in Openstack, we need to look into how it is connected logically when it’s created. This will allow us to know the steps that the VM traffic will have to go through before reaching its destination Before we speak about neutron, we first have to explain 6