[Howto] Connecting a USB GSM modem to a KVM guest – USB pass through

With current virtualization technologies it is possible to pass through devices from the host to the guest, calld USB pass through. KVM is no exception here, it even works with a USB GSM modem.

Many of customers I work with are migrating old IT systems and existing servers over to a newer and virtualized infrastructure. That often works without any problems. However, some services do depend on extra hardware like additional PCI cards – or, as in my case, on an external USB GSM modem.

To pass through such a device to the VM guest first the vendor and the product ID must be identified on the VM host:

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
Bus 002 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E230/E270/E870 HSDPA/HSUPA Modem

The last entry shows the mentioned GSM modem, built by Huawei. The interesting numbers are the vendor ID 12d1 and the product ID 1003. THe VM guest is oblivious of the device right now:

$ lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd 
Bus 001 Device 003: ID 0409:55aa NEC Corp. Hub

Next, the device must be defined in the VM guest XML. This can be done by directly editing the XML file within virsh: $ sudo virsh edit example-server. The command brings up an editor with the content of the XML definition file of the host. The USB device must be added in the device section:

  <devices>
    [...]
    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <vendor id='0x12d1'/>
        <product id='0x1003'/>
      </source>
    </hostdev>
  </devices>

Please note that a leading 0x must be added to the IDs! Save the file, reboot the VM guest, and check if the guest now shows the new device:

$ lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd 
Bus 001 Device 003: ID 0409:55aa NEC Corp. Hub
Bus 001 Device 004: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E230/E270/E870 HSDPA/HSUPA Modem

There it is. And the syslog shows that it was properly detected and can now be used in the usual ways, it’s done.

USB Serial support registered for GSM modem (1-port)
option 1-2.1:1.0: GSM modem (1-port) converter detected
usb 1-2.1: GSM modem (1-port) converter now attached to ttyUSB0
option 1-2.1:1.1: GSM modem (1-port) converter detected
usb 1-2.1: GSM modem (1-port) converter now attached to ttyUSB1
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems

Short Tip: Fix input/output error while creating LVM backed VMs with libvirt

Today I run into a strange error where I was not able anymore to create new VMs with virt-manager: I always got an input/output error when I tried to start the machine after installation.

A look into /var/log/syslog showed quite some errors on the dm-device – note that my VMs disks usually are on logical volumes.

Sep 12 15:27:55 example kernel: [19298.163712] device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception.
Sep 12 15:27:55 example kernel: [19298.243980] Buffer I/O error on device dm-5, logical block 1081985
Sep 12 15:27:55 example kernel: [19298.243983] lost page write due to I/O error on dm-5
Sep 12 15:27:55 example kernel: [19298.243994] Buffer I/O error on device dm-5, logical block 1081986
Sep 12 15:27:55 example kernel: [19298.243994] lost page write due to I/O error on dm-5

The fix is pretty easy: when you create the disk and thus the LV for the virtual machine, make sure you tell virt-manager that it should allocate the entire disk right from the start. It looks like sparse LV images are not supported right now.

[Howto] Fixing unstable clocksource in virtualised CentOS

Maintaining the correct time in virtual machines can be quite troublesome. If problems occur, a change of the clock source might be the right step.

Before the age of virtualization time was measured by tick counting: the operating system initializes a device which sends interrupts – called ticks – at a certain, fixed rate. The OS counts these interrupts, for example 100 a second, and thus knows how much time has passed.

However, in case you have a running virtual machine it cannot be guaranteed that the virtual machine has the proper resources to generate the ticks at fixed rate. Imagine a server hosting dozens of virtual guests, it might happen that at the moment the virtual machine for a specific guest does not get the resource to generate a tick. A backlog of ticks is build, and might grow more if the server machine is under heavy load. Thus the clock on the vm guest runs behind. If the backlog is too large, the ticks might even been dropped, so the clock source for the vm is unstable and the vm guest clock is further behind.

Linux tries to find out if the clock source is unstable and reports if that is the case. The error message in such cases looks like:

Clocksource tsc unstable (delta = -102057770 ns).  Enable clocksource failover by adding clocksource_failover kernel parameter.

The best is to check first what clock sources are available and which one is currently used:

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
kvm-clock tsc hpet acpi_pm
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock

The problem of an unstable clock source can be fixed most often by adding another, failover clock source, for example hpet or acpi_pm. These and other clock sources are explained in detail in “Understanding the Linux Kernel, 3rd Edition” by Daniel P. Bovet, Marco Cesati, btw.

The failover clock source has to be added to the kernel boot options in /etc/grub.conf:

clocksource_failover=acpi_pm in /etc/grub.conf

If you want further information about time keeping problems in virtual machines, there is a great techpaper by vmware exploring these problems and shedding more light on the various problems: Timekeeping in VMware Virtual Machines.