So my OpenFiler VM crashed (OK, you got me: I was trying to 'tweak' it). That wasn't so bad but I had 25GB worth of ISOs being shared out to my other VMs. This was bad news, but I managed to save my day. Luckily I always make it a point to add discrete virtual disks (VDIs) in XenCenter when I want to add another share or iSCSI disk in OpenFiler. So maybe I was in luck.

My first step was not so successful: I had decided to bring up a quick-and-dirty Debian VM, detach the VDI from the now defunct OpenFiler VM, and attach it to the Debian VM. After doing the usual:

fdisk -l

...to see what the device name was of the VDI (which the XenCenter kindly tells you as well), I tried to mount it. Now, you may or may not know that the mount command is just a triage to the mount command that's specific to the type of filesystem you're trying to mount. Often the mount command can tell what kind of filesystem is on the device, and call the correct mount for you. You can also give the mount command a clue by saying something like:

mount /dev/sdc1 /mnt -t xfs

...which in this case tells mount that the device contains an "xfs" filesystem. Use the manual pages like this:

man mount

...for a full description of this (or any other) command.

After the mount command kept on burping that it didn't know the filesystem type, I tried to coerce it since I knew I had chosen to format the disk using the xfs filesystem type in OpenFiler. Nothing would work; it was almost like the message from mount was telling me to give up, since this filesystem is toast. I found myself telling the Debian VM that it "just didn't understand what I wanted", and that if it didn't do what I wanted, I would give It the virtual equivalent of the "elevator shaft" treatment. This is what we used to do back in the day to real hardware that wouldn't comply - next-to-top-floor drop down the elevator shaft.

My first attempt behind me, I had the brilliant idea of reinstalling a fresh copy of OpenFiler, because surely it would know what I wanted, after all this VDI was created by OpenFiler. Lucky for me that these things take minutes using XenServer: You can do things that your boss would have given you 2-weeks of sick leave, for even suggesting just a few short years ago - all from the comfort of your ergonomically correct office chair.

So there I was issuing the mount command again, and again the mount command just didn't get it (it turns out I didn't get it, but you know how that goes). Time for a cuppa tea. By-the-way, I've always been 'green' when drinking my black tea - always from a mug, never from Styro.

During my tea break, I started thinking it through (which is like reading the manual for your barn door, after your Harley has been nicked): OpenFiler actually leverages the Logical Volume manager to do its stuff. The LVM has a Volume Group, which is a collection of physical volumes, which in the case of a VM is the VDI (or VDIs) that you assign to that VM. On a real machine it would be a collection of physical disk drives. You can have lots of physical disks of differing sizes and type collected in a Volume Group, and then meter out Logical Volumes from that group. A logical volume, looks and acts like a physical volume, except the LVM may be spreading your one LV amongst several PVs, depending on the attributes of your VG. A good example is setting up RAID; at the LV level, you're not really interested how the LVM is dealing with it, but you're glad it can. When I say that an LV 'looks' like a PV, I mean it's just another block device, like:

/dev/XSLocalEXT-0cbc8c20-3268-5876-db13-128ad9d0b9c1/0cbc8c20-3268-5876-db13-128ad9d0b9c1

You can get a list of LVs on your system by using:

lvdisplay

Similarly, you can get a list of VGs on your system by using:

vgdisplay

One 'ah, ah!' moment later, I was able to explain it to myself. The xfs format wasn't on the physical drive I was trying to mount, it was on the Logical Volume. The PV has the LVM format imposed on it, and the LV has the xfs filesystem format imposed on it. So maybe if I mounted the LV that would give me what I wanted: access to that 25GB-worth of ISOs. Bingo! (That's reminds me, I'll be doing some training at Synergy this May in Vegas). Lucky for me that I had kept this particular VDI in a VG of its own, and by itself. I suspect, though, that had I had multiple VDIs in the VG, I could have still gotten it to work since LVM marks the disks appropriately to make them system independent.

The rest of the story is simple, but worth mentioning since (again), doing this back in the day, would have taken you having to pawn your wedding ring, and as much time as you would have been in the dog-house for doing so. I dropped a brand new 30GB VDI into the OpenFiler VM, because even though the old VDI was recognized, I couldn't get OpenFiler to re-share it. After a few clicks in the OpenFiler admin tool, I had shared the new disk. Using the mount command by itself, i.e.:

mount

...I was able to discover where OpenFiler had mounted my new disk, and copy everything from the old disk to the new from the CLI. I was then able to detach the old disk, and delete it.

Basically, this story is true, but I may have made the stuff up about the Harley being stolen, the tea-bag and the ergo-chair. I'll leave that for you to figure out! Let me know.

In part-1, I discussed how to mount a read-only NTFS USB drive into your XenServer filesystem.

In part-2, I discussed formatting a USB drive exclusively for XenServer.

In part-3, I discussed accessing CIFS shares in XenServer.

In this final part I talk about an OpenFiler virtual machine, and getting data inside it for sharing.

I use OpenFiler (http://openfiler.com), as a virtual machine inside my lab, for the following reasons:

• I can create shares on-the-fly, that support multiple protocols, for example the same share can be offered as NFS, CIFS and FTP.
• Easy browser-based admin.
• I can add virtual disks on-the-fly to support my requirements.
• OpenFiler supports iSCSI, so I can offer a slice of disk as an iSCSI LUN, and setup the presentation of that LUN, all from my browser.

Also, getting data into OpenFiler is fairly easy from a USB drive in the Control domain, and thus making it available to all other machines - virtual or otherwise:

• Create and start your OpenFiler VM, and setup a share.
• From the Control Domain, you can mount that share as either NFS or CIFS (as shown previously).
• This doesn't have to be the same XenServer's Control Domain as the OpenFiler VM is running.
• Copy the data from your USB drive into a path in your mount point as previously described.

The only thing I haven't described is how to mount an NFS share. It has a familiar syntax, as shown in the following example:

mount 192.168.1.51:/NFS_ShareName /mnt

My hope is that you can leverage some of these tips to help you get your data on and off your USB drive into your XenServer virtual machines.

In part-1, I discussed how to mount a read-only NTFS USB drive into your XenServer filesystem.

In part-2, I discussed formatting a USB drive exclusively for XenServer.

In this week's installment, I'll talk about Accessing CIFS shares in XenServer.

There's actually a simpler way to read and write to an NTFS partition from XenServer, but you'll need to plug your USB drive into a Windows machine and share it. Once shared, and knowing the share name, and the IP address of your Windows machine, you can use the following example mount commands:

mount //192.168.1.51/ShareName /mnt

or
mount //192.168.1.51/Sharename /mnt -o username=olivierw

You may have to supply a password for your share, and you may have to supply an alternate user name to the CIFS service (other than the default 'root' user). By-the-way, this is the method that XenServer itself uses when you create an ISO CIFS Storage Repository in XenCenter.

In part-1, I discussed how to mount a read-only NTFS USB drive into your XenServer filesystem.

In this week's installment, I'll talk about Formatting a USB drive exclusively for XenServer.

If you wanted to dedicate a USB drive to your XenServers, you could format it with a Linux filesystem. That way you could use it as storage to backup your VMs, and restore them on other machines if needed. Assuming you know the device name of the partition you want to use, use the following as an example command:

mkfs -v -t ext3 /dev/sdc1

Warning: Doing this will destroy any existing data on the partition, and you will not be able to use this disk on a Windows machine without reformatting it using Windows Disk Manager: You have been warned!

As always, with any Linux command you can use the online manual (if it's installed), for example:

man mkfs

Once formatted, you can mount this device into the filesystem, as shown previously in part-1. Now you can read and write to the drive, as in this following example which will backup a VM to the external USB drive:

xe vm-export vm='W2K8 DC' filename='/mnt/backups/W2K8 DC.xva'

Come back next week, and I'll talk about Accessing CIFS shares in XenServer.

Since your XenServer machine is Linux-based, there are some challenges in getting/putting data from/to a removable USB device. The lab I work in is isolated from our corporate network, so I've come up with four handy solutions that I'd like to share here over the coming weeks:

• Accessing an NTFS USB drive in XenServer
• Formatting a USB drive exclusively for XenServer
• Accessing CIFS shares in XenServer
• OpenFiler virtual machine, and getting data inside it for sharing

First off: Once you've plugged a USB drive into you XenServer machine, how do you access the data therein? The first thing to do is logon to the Control Domain, usually through XenCenter, and type the command:

fdisk -l
 
 

Notice that the fdisk command shows the disks that XenServer knows about. I've highlighted here (in red) an NTFS USB drive that I've plugged into the XenServer. Notice also that the device name is /dev/sdc, and that the first partition on that device has itself a device name of /dev/sdc1. In this example, the local disk on which I've installed XenServer is /dev/sda, which has three partitions (shown first in the listing).

Accessing an NTFS USB drive in XenServer

Here I've plugged in an NTFS USB drive, and I've established that XenServer (Linux) knows the first partition by the name /dev/sdc1.  Since this is a disk device, we need to "mount" it into the Linux filesystem. In this way, it will become a part of the filesystem hierarchy. The only thing I need is an empty directory to mount "over". Most Linux distributions come with an empty /mnt directory for just this purpose:

mount /dev/sdc1 /mnt

Note that the target directory of your mount has to exist, and any files that existed in that directory will be "hidden" until you un-mount the device (see later for un-mounting). There's nothing special about the directory you mount over - it's a regular directory. What I usually end up doing is creating another directory inside of /mnt to mount my disk over. That way I can have many "mount points" if I want to transfer data between them.

The big drawback with mounting an NTFS drive is that it's supported in read-only mode only. This isn't usually a problem with software like NTFS-3G being available, but Citrix doesn't support the installation of any software inside of the XenServer Control Domain.

But at least now I can use regular Linux commands to copy data from the drive, for example you could import an already backed-up VM straight from the drive, using something like:

xe vm-import filename='/mnt/backups/Windows XP.xva'

This assumes that there was an existing folder in the root of the mounted partition called backups.

Before unplugging the USB drive, you'll need to "un-mount" the drive, making sure that your current working directory is not somewhere down the /mnt path (or wherever you've mounted the device):

cd /
umount /mnt

Now you can safely unplug the USB drive from the XenServer machine.

Make sure you stop by for part 2 next week!

In my previous post on the subject of storage (Is SAN really NAS spelt backwards), I introduced a fundamentals whitepaper. Behind XenServer Storage, builds on this and shows how XenServer leverages the different kinds of storage. Feedback welcome!

Google 'storage' and, apart from the odd link to IKEA, data storage is starting to become more prominent. That Ultra-640 SCSI, 15,000 RPM 30GB drive you proudly have in your best server is taking center stage in Storage Area Networks (SANs). As the options for building a SAN are becoming numerous, and the prices are starting to look attractive, maybe you need to get to grips with the fundamental technologies, and terminology. Have I got a whitepaper for you! Introduction to Storage Technologies.

If you're like me, you'll like to mentally create pictures to make sense of what you're reading. The underpinnings of Xen networking, as I found out, is not that difficult once you have the correct pictures in mind. Once I'd discovered the secrets, I decided to write a paper explaining it to myself. Hopefully, others will find this useful as well!

"It's important to understand that XenServer networking operates at Layer 2 of the OSI. This means it's independent of any Layer 3 addressing, such as IP. As we'll see, XenServer acts as a Layer 2 virtual switch..." Read more in my Citrix Knowledge Center article.