Tag Archives: virtualisation

Adding SCSI Controller / SCSI Disks to KVM-based Guests

Following on from my previous article I wanted to add a SCSI disk to a KVM-based guest (hostname: mars). The guest was installed via kickstart with all volumes on /dev/vda. I’d seen conflicting reports of SCSI support (the fact you can’t add the SCSI controller/disks through virt-manager, for example) so I wanted to create a SCSI disk and attach it to the host at /dev/sda.

I first used my new best friend fallocate to fast-allocate the required image:

Next, I created the appropriate XML configuration for the new disk device:

Trying to attach this device via virsh yielded the following unpleasantness:

OK - let’s jump onto the guest and see what’s going on. First, I installed lspci and lsscsi so that I could diagnose the issue …

… and ran lspci:

OK - so there is a SCSI controller available, but it’s for the virtio block devices. Looking at the Red Hat Documentation we need to add a SCSI controller of type virtio-scsi. This can also be confirmed by the lack of output from the following command:

Let’s create a simple XML configuration file for our new SCSI controller:

And add it to our guest configuration:

Dumping the guest domain’s XML should now show the controller added to the configuration:

On the guest, lspci should show the new controller added:

The controller appears as “Device 1004“. I was then able to add the disk device as an appropriate SCSI drive:

And on the guest, fdisk proves it’s there:

As does a quick probe with lsscsi:

As I like making things difficult for myself, I’ll be placing a btrfs filesystem on this and playing around with volumes - but that’s something for another article :)

It’s worth noting that whilst the VM configuration within virt-manager shows that there is now a SCSI controller associated with the guest, it still will not allow the creation of SCSI disks - you’ll need to use virsh (at least you will on virt-manager version 0.9.0).

How to Network Solaris 11 Zones Under VMware or VirtualBox

Whilst playing around with the changes in zone virtualisation technology between Solaris 10 and Solaris 11, I found that all zones now use exclusive IP, not shared. There is a new anet interface type configured via zonecfg that handles this.

This will all be covered in detail in a future article, but for now take a look at this:

I boot my new testzone, and the vnic is automatically created over net0. But net0 is itself a virtual NIC (i.e. VMware or VirtualBox is virtualising this for us in the first place), whilst Solaris obviously sees it as a physical interface.

Inside the new zone, I was unable to ping anything. The zone was not on the network. The fix? Place net0 into promiscuous mode using snoop inside the global zone. This makes sense when you think about it, and will fix your zone networking allowing you to virtualise within your VM:

Reconfiguring KVM-based networking DHCP range with virsh

Whilst building a KVM-based virtualisation server on CentOS 6.4, I noticed that the default network created during the installation of the KVM/QEMU packages (192.168.122.0/24) allocated the entire address space to DHCP, as can be seen below in virt-manager (click to enlarge):

virtualnetwork

All of the configuration fields are read-only, and I wanted to reduce the DHCP scope so that I could build statically-addressed virtual servers without the hassle of creating static DHCP reservations for them. This scope can also be confirmed by looking at the current running dnsmasq configuration (dnsmasq is used by KVM/QEMU to manage DHCP):

The powerful virsh shell can be used to perform this modification and directly alter the XML configuration that backs the virtualisation platform.

To start, run virtsh net-edit <network-name> to fire up your $EDITOR:

Prior to making any modifications, my configuration was as follows:

Next, reduce the DHCP range as required - my modified configuration is as follows:

Once you quit your editor, you’ll see a message as follows, indicating that the change has been made:

If at this stage you dump the configuration with virsh net-dumpxml <network-name> you will see that the changes have NOT yet been applied:

To apply the changes, restart the network with virsh net-destroy <network-name> and virsh net-start <network-name>:

Now, a dump of the XML shows that the changes have been applied

as does another ps on the dnsmasq process:

Now, launching virt-manager shows that the desired DHCP scope is in effect:

virtnetwork-updated

Another case of command line winning over the GUI. virsh is a VERY powerful command, and there will be more articles on its usage as I dabble more with KVM-based virtualisation.

Adding Storage Devices to KVM-Based Guests

Introduction

During the process of configuring a CentOS KVM guest (hostname: mercury), I wanted to add a separate disk device for the /var/www filesystem so that I could configure the guest as a kickstart server with ample storage available.

To enable this, I wanted to do two things. First, add a new disk device to the virtualised guest for configuration as a new physical volume under LVM on the guest - this would be used to host /var/www. Second, I wanted to mount the CentOS (and possibly other) ISO images to the guest’s DVD drive so that I could populate the installation source tree.

Adding a Virtualised Hard Disk

Let’s start with adding the new hard disk device. dd is the command of choice here. You can create sparse files for test purposes (i.e. the full disk allocation is not consumed upon creation), but Red Hat warns against this as there can be data integrity issues, and obvious performance issues as the space is actually allocated whilst the device is being used. Therefore, the best choice is to pre-allocate the storage. This will obviously consume the full size of the device being created, but will be robust and will perform optimally.

I’ll create a 20GB volume for /var/www, under the default location for libvirt disk images - /var/lib/libvirt/images

As you can see, I have created the image file with a meaningful name (in this case, <hostname>-<device-associated-on-guest>). This will make managing the disk images easier as more guests are created. This will take some time - go and make a cup of tea.

Once done, dd should produce output along the following lines:

If your Linux distro comes with fallocate, you can do this in a second or too instead (depending on filesystem support - I use ext4 which does), rather than waiting on dd:

It’s worth noting that the original image created at guest installation (i.e. the one containing the OS) is available as /dev/sda (despite it being referenced as an IDE device in the configuration with a target of /dev/hda). So, the actual guest configuration shows an IDE drive:

However, within the guest, it’s detected as a SCSI drive at /dev/sda:

I’ll use virtio for any additional drives added, starting at /dev/vda. I could have added a SCSI HBA (via the virtio-scsi controller model) but there is no need to do this (and over-complicate things) for my requirements.

Continue reading