Mirantis OpenStack Express 2.0 - Attaching and Using Volumes

This is the fourth in a series of short tutorials showing how to perform common cloud operations tasks in Mirantis OpenStack Express 2.0 – Mirantis’ “Private Cloud as a Service”

In our last tutorial, we learned how to create a block storage volume. Now, we’ll attach it to an instance, configure it for use, and explore more volume operations.

Step by Step

To begin: volumes can be extended, non destructively — though if you do so, you may need to resize or modify partitions to use the extra space.

Let’s take the 50GB volume we created last time, and turn it into a 60GB volume. From Mirantis OpenStack Express Horizon’s Volumes & Snapshots pane, pop down the More menu and select Extend Volume. We’ll enter 60GB here -- as you can see, Mirantis OpenStack Express keeps track of your storage quotas, and displays and updates them during all operations of this kind.

Mirantis OpenStack Express 2.0 lets you extend the size of block storage volumes easily.

Next, we’ll attach this volume to our running Cirros VM instance. Pick Edit Attachments from the More dropdown menu, and select a running instance to attach the volume.

Here, we attach the volume to our CirrosVM instance.

Heading over to the Instances pane, we’ll log into our instance using the built-in VNC console and issue a ‘sudo fdisk -l’ command to review attached storage in detail. As you can see, the new volume is visible to the instance, identified as /dev/vdb.

After attaching the volume, the storage is accessible to our instance. We can log into the instance and use fdisk -l to see the volume.

Since our volume is empty, let’s set it up as generic storage in the usual way. First, we’ll use ‘sudo fdisk /dev/vdb’ to create a partition table with one primary partition, using all the space.

We can use standard Linux commands to create a partition table on our new volume.

Now we’ll perform further operations on this partition, called ‘/dev/vdb1.’

First, we’ll make an ext3 file system.

Here, we're using mkfs to make an ext3 file system in our volume's primary partition.

Then we’ll create a mount point called '/data' And mount ‘/dev/vdb1’ to it. At this point, the volume’s storage is accessible to Linux.

Mounting our new volume.

We’ll also modify /etc/fstab to insure that our instance remounts the volume on restarts.

We'll use vi to modify the file system table (/etc/fstab) to reference our new volume, so our instance will mount it again at startup/reboot.

From the command line of our Cirros VM, we can now see the lost+found folder mkfs created at the root of our new volume's file system.

Trivially, we can now reboot our instance, log in, and see that we still have access to our volume and can read files stored on it.

Our VM is now set up to remount our volume after reboot. We can see the lost+found folder in /data.

Snapshots

Now that we’ve built a volume and configured a server to attach to it, we can use snapshots to leverage our work, knowing that a volume is not destroyed when an attached instance is terminated.

Let’s start by creating a snapshot of our Cirros VM instance. The Create Snapshot button raises a dialog that lets us name our snapshot, which is saved to the Images repository.

Mirantis OpenStack Express 2.0 makes it easy to snapshot a VM or volume, even on the fly. However, there are techniques (like flushing write buffers) and utilities (like fsfreeze) you should master to insure that snapshots always contain exactly the state of the machine or volume you wish to preserve. The OpenStack Docs deal with this in some detail, following a useful blog post by Sebastien Han.

Your snapshot is saved in the Images pane.

Now let’s snapshot our volume. In this case, Create Snapshot is an option in the More menu. The named snapshot is saved in the Volume Snapshots tab of the Volumes & Snapshots pane.

Just name your snapshot to preserve the state of a volume.

Note that OpenStack has forced a flush of buffers to help insure that a volume snapshot taken on the fly contains all the data you expect.

Now, let’s launch our instance snapshot. Once that’s spawned, we’ll attach our volume snapshot to it.

Launching our snapshotted instance. We need to specify the small model, here, to insure the instance launches with enough memory. We're also setting up (on the other tabs) keypair authentication, and dialing in the same network as we used with our original CirrosVM instance.

Our new instance, drawn from a snapshot of our first one, has spawned.

Here, we've created a new volume from our volume snapshot. We could, if we wished, create a bigger volume here than the original 60GB snapshot size. Note that creating new volumes from large snapshots is time-consuming.

We can then attach the new volume to the new instance. As we can see, the volume is designated /dev/vdb, like the original volume was to our CirrosVM instance.

Soft-rebooting the snapshot instance will execute the mount instruction in /etc/fstab.

We can use the Soft Reboot Instance button on the Instances pane to reboot our new instance. This will cause the file system table to be re-read, and the new volume to be mounted.

And when we visit our snapshot instance in the console, we can see that we have access to the snapshot volume and the data it contained when the snapshot was taken.

Success! Visiting our new VM via the VNC console, we can see that the new volume — a copy of our old one — has been mounted, and we can see the lost+found folder at the /data mount-point.

Now that we’ve experimented with basic features, our next tutorial will explore how to create platform model ‘flavors.’

Resources:

• Mirantis OpenStack Express 2.0 Documentation
• Mirantis OpenStack Express Operations Guide
• OpenStack Documentation: Create and Manage Volumes

Check out Express for yourself at https://express.mirantis.com.