Google Compute Engine

Exporting volumes from Cinder and re-creating COW layers

Today I wandered into a bit of a rat hole discovering how to export data from OpenStack Cinder volumes when you don't have admin permissions, and I thought it was worth documenting here so I remember it for next time. Let's assume that you have a Cinder volume named "child1", which is a 64gb volume originally cloned from "parent1". parent1 is a 7.9gb VMDK, but the only way I can find to extract child1 is to convert it to a glance image and then download the entire volume as a raw. Something like this: $ cinder upload-to-image $child1 "extract:$child1" Where $child1 is the UUID of the Cinder volume. You then need to find the UUID of the image in Glance, which the Cinder upload-to-image command will have told you, but you can also find by searching Glance for your image named "extract:$child1": $ glance image-list | grep "extract:$cinder_uuid" You now need to watch that Glance image until the status of the image is "active". It will go through a series of steps with names like "queued", and "uploading" first. Now you can download the image from Glance: $ glance image-download --file images/$child1.raw --progress $glance_uuid And then delete the intermediate glance…

Continue ReadingExporting volumes from Cinder and re-creating COW layers

Configuring load balancing and location headers on Google Cloud

I have a need at the moment to know where my users are in the world. This helps me to identify what compute resources to serve their request with in order to reduce the latency they experience. So how do you do that thing with Google Cloud? The first step is to setup a series of test backends to send traffic to. I built three regions: Sydney; London; and Los Angeles. It turns out in hindsight that wasn't actually nessesary though -- this would work with a single backend just as well. For my backends I chose a minimal Ubuntu install, running this simple backend HTTP service. I had some initial trouble finding a single page which walked through the setup of the Google Cloud load balancer to do what I wanted, which is the main reason for writing this post. The steps are: Create your test instances and configure the backend on them. I ended up with a setup like this: Next setup instance groups to contain these instances. I chose unmanaged instance groups (that is, I don't want autoscaling). You need to create one per region. But wait! There's one more layer of abstraction. We need a backend…

Continue ReadingConfiguring load balancing and location headers on Google Cloud

Setting up VXLAN between nested virt VMs on Google Compute Engine

I wanted to play with a VXLAN mesh between VMs on more than one hypervisor node, but the setup for VXLAN ended up being a separate post because it was a bit long. Read that post first if you want to follow the instructions here. Now that we have a working VXLAN mesh between our two nodes we can move on to installing libvirt (which is called libvirt-daemon-system on Debian, not libvirt-bin as on Ubuntu): sudo apt-get install -y qemu-kvm libvirt-daemon-system sudo virsh net-start default sudo virsh net-autostart --network default I'm going to use a little python helper to launch my VMs, so I need some other dependancies as well: sudo apt-get install -y python3-pip pkg-config libvirt-dev git git clone https://github.com/mikalstill/shakenfist cd shakenfist git checkout 6bfac153d249752b27d224ad9d079095b640498e sudo mkdir /srv/shakenfist sudo cp template.debian.xml /srv/shakenfist/template.xml sudo pip3 install -r requirements.txt Let's launch a quick test VM to make sure the helper works: sudo python3 daemon.py sudo virsh list You can destroy that VM for now, it was just testing the install. sudo virsh destroy ...name... Next we need to tweak the template that shakenfist is using to start instances so that it uses the bridge for networking (that template is the one…

Continue ReadingSetting up VXLAN between nested virt VMs on Google Compute Engine

Setting up VXLAN on Google Compute Engine

So my ultimate goal here is to try out VXLAN between some VMs on instances in Google compute engine, but today I'm just going to get VXLAN working because that took a fair bit longer than I expected. First off, boot your instances -- because I will need nested virt later I chose two instances on Google Cloud. Please note that you need to do a bit of a dance to turn on nested virt there. I also chose to use Debian for this experiment: gcloud compute instances create vx-1 --zone us-central1-b --min-cpu-platform "Intel Haswell" --image nested-vm-image Now do those standard things you do to all new instances: sudo apt-get update sudo apt-get dist-upgrade -y Now let's setup VXLAN between the two nodes, with a big nod to this web page. First create a VXLAN interface on each machine (if you care about the port your VXLAN traffic is on being to IANA standards, see the postscript at the end of this): sudo ip link add vxlan0 type vxlan id 42 dev eth0 dstport 0 Now we need to put the two nodes into a mesh, where 34.70.161.180 is the IP of the node we are not running this command on…

Continue ReadingSetting up VXLAN on Google Compute Engine

End of content

No more pages to load