Xen HVM e1000 Issues + Patch

Xen HVM has some very nice features for emulating certain hardware interfaces for HVM guests.

This post describes an issue with the e1000 model driver on Debian’s packaged xen-qemu-dm-4.0.

Enabling the e1000 driver is straightforward and accomplished by adding the model the VM config for the vif as follows:

vif = [
'type=ioemu, bridge=xen-br0, model=e1000',

(For completeness sake, the models available are: i82551, i82557b, i82559er, ne2k_pci, ne2k_isa, pcnet, rtl8139, e1000, smc91c111, lance and mcf_fec.)

When using the e1000 driver you will notice that the dom0 cannot ping the domU guest, nor can other guests ping the domU. However, pinging the domU from another machine on your network will work.

The reason for this is that the e1000 driver does not pad frames to be at least the minimum ethernet frame size. When the offending frame is forwarded through a physical adapter it will add the needed padding. This explains the odd behavior and can cause quite some frustration especially if your domU guest absolutely needs to use the e1000.

The solution is to patch and rebuild the pre-packaged xen-qemu-dm-4.0. The patch required for this is here:

--- a/hw/e1000.c	2010-07-02 11:36:34.000000000 -0500
+++ b/hw/e1000.c	2012-02-20 01:39:24.559113732 -0600
@@ -51,6 +51,7 @@
 #define IOPORT_SIZE       0x40
 #define PNPMMIO_SIZE      0x20000
+#define MIN_BUF_SIZE	  60
  * HW models:
@@ -602,11 +603,20 @@
     unsigned int n, rdt;
     uint32_t rdh_start;
     uint16_t vlan_special = 0;
-    uint8_t vlan_status = 0, vlan_offset = 0;
+    uint8_t vlan_status = 0, vlan_offset = 0, min_buf[MIN_BUF_SIZE];
     if (!(s->mac_reg[RCTL] & E1000_RCTL_EN))
+    /* Pad to minimum Ethernet frame length */
+    if (size < sizeof(min_buf)) {
+        memcpy(min_buf, buf, size);
+        memset(&min_buf[size], 0, sizeof(min_buf) - size);
+        buf = min_buf;
+        size = sizeof(min_buf);
+    }
     if (size > s->rxbuf_size) {
         DBGOUT(RX, "packet too large for buffers (%d > %d)\n", size,

Originally seen on: http://permalink.gmane.org/gmane.comp.emulators.qemu/80804

Running netatalk 2.2~beta4-1 on Debian Squeeze

Running netatalk 2.2~beta4-1 on Debian Squeeze is straightforward because the Wheezy release includes the package already. This article explains how to install the updated version using apt pinning.

Step 1: Add the wheezy sources to apt.

Using your favorite editor create the file /etc/apt/sources.list.d/wheeze.list

deb http://ftp.us.debian.org/debian/ wheezy main
deb-src http://ftp.us.debian.org/debian/ wheezy main

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main

Step 2: Pin debian packages to a specific releases.

Create the file /etc/apt/preferences.d/default with contents:

Package: *
Pin: release a=stable
Pin-Priority: 500

Create the file /etc/apt/preferences.d/netatalk with the contents:

Package: netatalk
Pin: release a=testing
Pin-Priority: 1000

Package: libgcrypt11
Pin: release a=testing
Pin-Priority: 1000

Package: libgnutls26
Pin: release a=testing
Pin-Priority: 1000

Package: libgpg-error0
Pin: release a=testing
Pin-Priority: 1000

Step 3: Update apt and install the new netatalk.

# apt-get update
# apt-get install netatalk

Step 4:Finishing up.

That’s it. After this restart netatalk with:

# /etc/init.d/netatalk restart

Step 5: Clean up after the upgrade (optional).

If your volumes show up empty or are missing, see the file /usr/share/doc/netatalk/README.Debian for instructions to resolve the issue.

The newer version of netatalk uses Berkeley DB 4.8 or newer. This implied that if you upgraded from an older install, the old metadata caches will be incompatible. The README mentioned above explains how to perform an upgrade of these files.

We decided to remove the .AppleDB metadata databases with the command:

# find / -name .AppleDB -exec rm -rf {} \;