BenV's notes

Now that Xen has deprecated the xm command and xend daemon, libxl is the way to go. However, libxl didn’t support external scripts for your block devices (like block-drbd) before version 4.2.0. Seems like that issue has been resolved, or at least as far as I care for now. However, with these changes I found that the block-drbd script (at least up until DRBD 8.4.2) still doesn’t work properly.

To save you some time debugging this shit, the problem is that the new xl stack forces the device type to be ‘phy‘ when a script is used. In the older versions xm/xend would report ‘drbd‘ to the block-drbd script as device type. Knowing this the fix for now is simple:

--- block-drbd.org 2012-11-21 12:35:08.338180920 +0100
+++ block-drbd 2012-11-21 12:35:33.278642801 +0100
@@ -248,6 +248,8 @@
fi

remove)
case $t in
+ phy)
+ ;&
drbd)
p=$(xenstore_read "$XENBUS_PATH/params")
drbd_resource=$p


Yay a new Xen version. Well, it’s not that new, but I’m upgrading to it today. And while we’re at it, Jeremy got his pvops kernel almost to version 3.1.0 (it’s at rc9 today, good enough for me atm).
So what’s new in this latest Xen version? First of all it has finally ditched the xm command for good. Well, it’s still there, but it’s really deprecated now because it has been replaced by xl. For a nice overview of what has been improved since Xen 4.0, they have a nice list over here.
One cool thing in the later Xen releases (that is: 4.0 and up) is the integration of Remus. We’ll test that out later. (continue reading…)

Once again I have some new hardware that’s been labeled “Xen Server”.
This time I want to set it up in a way that brings some redudancy so we can actually have 1 server fail and still have our hosts up and running.
(or at least back up in a few minutes instead of several hours).
To achieve this goal I will install the latest version of Xen (which seems to be 4.01) and use DRBD with LVM for storage. (continue reading…)

Xenbro has found its way into the Coloclue racks where it is now running with real IP addresses. The Coloclue network routes all IP space to the main IP address of the machine so that precious IP addresses are not ‘lost’ to reserved network and broadcast addresses. This means that my /29 has 8 usable addresses in stead of only 6. In order to set this up you simply change the network-script and vif-script to the -route variants in /etc/xen/xend-config.sxp so it looks like this:

(network-script network-route)
(vif-script vif-route)

Easy. Make sure ip forwarding is enabled though (check /proc/sys/net/ipv4/ip_forward, it should be 1) , and for IPv6 forwarding you need to enable /proc/sys/net/ipv6/conf/all/forwarding. Note that you must enable it on the -all- directory, only enabling it on a single interface won’t do what you’d expect (this took me a while to figure out ;)).
After requesting both a set of IPv4 and IPv6 addresses I stumbled upon Xen’s /etc/xen/scripts/vif-route script which doesn’t do anything with IPv6! Since I do want my IPv6 space routed to my domU (and probably to the others as well) I decided to molest the script a little. My modification assumes you provide both the IPv4 address and IPv6 range you want to use on the domU. Here’s the diff:
[Download not found]
Note that my patch adds some extra logging as well, you can hack that out yourself if it annoys you.
If patching is too difficult for you, here’s the patched vif-route script:
[Download not found]

Don’t forget to put your IP addresses in your domU’s config file:

# domU.cfg
vif = [ 'mac=00:16:11:11:2b:11, ip=2345::1/64 192.168.2.100' ]


After patching vif-route and enabling the script in xend-config.sxp you still have to set routes to the dom0 in your domU. Example for dom0 with 192.168.1.1 and 1234::1

# IPv4
root@domU# ifconfig eth0 192.168.2.10 netmask 255.255.255.255 # Your domU's IPv4 address here
root@domU# ip ro add 192.168.1.1 dev eth0
root@domU# ip ro add default via 192.168.1.1
# IPv6
root@domU# ip -6 addr add 2345::1/64 dev eth0 # Your domU's IPv6 range here
root@domU# ip -6 ro add 1234::1 dev eth0
root@domU# ip -6 ro add default via 1234::1


Now it works (unless you did something stupid of course) 🙂

Or more specific: CPU frequency scaling.

On my laptop this is one of the first things I enabled to make my battery last longer.
Now that we’re going to put a server in a rack where they will bill us depending on the amount of power consumed, this sounds like a welcome thing to have enabled.

Our latest Xen install has Xen 3.4, on which they’ve enabled it by default. Isn’t that nice?
So basically, if your processor etc is good enough to support it, you can mess around with it using the xenpm tool.

For instance we can check the parameters for CPU 0 like this:

root@xenbro:~# xenpm get-cpufreq-para 0
cpu id : 0
affected_cpus : *0 1 2 3
cpuinfo frequency : max [2600000] min [800000] cur [800000]
scaling_driver :
scaling_avail_gov : userspace performance powersave ondemand
current_governor : ondemand
ondemand specific :
sampling_rate : max [10000000] min [10000] cur [20000]
up_threshold : 80
scaling_avail_freq : 2600000 1900000 1400000 *800000
scaling frequency : max [2600000] min [800000] cur [800000]

As you can see, it’s very much like the whole cpufreq ordeal. It has an ondemand governor, a powersave one, etc. Right now this CPU is using the ondemand governor, which will ramp up the clock when demand increases.
However, since this is a quad core and not a real quad processor machine we can only change the governor for all 4 cores at the same time, not for individual ones. (would be cool to have 1 core burning away power while the rest idles by….).

Anyway, the xenpm tool allows us to monitor and change various aspects of this.
For instance this will do a little benchmark and show the processor states during the benchmark.

root@xenbro:~# xenpm start 10
Timeout set to 10 seconds
Start sampling, waiting for CTRL-C or SIGINT or SIGALARM signal ...
Elapsed time (ms): 10003

Avg freq 800000 KHz

As you can see my processor is mostly idle.
State C0 is the most active state, C1 is sleeping with use of the HLT instruction.
Your processor can have many more states, like my laptop which has 4.

Anyway, I put the change to ondemand governor in my /etc/rc.d/rc.local, so let’s hope it helps.

To read some more about the details of this stuff you can check out the Xenpm wiki page.

Another day, another time for fun!

Since we got Xen up and running yesterday, it’s now time for actually having some fun with it.
The goals are:

1. Getting xend started automagically when booting without destroying my network connection
2. Getting a domU up and running with a network connection
3. Getting an internal network between the domUs and dom0, shielded from the big bad internet.

(continue reading…)

You read it right, time for fun!

First we build ourselves a nice cute little server in a 2U rack case made by Chenbro (sounds like Xenbro to me ;)).
Inside we stash a quad core Phenom X2 810, 2 western digital 1TB disks from the “green” series and of course 8GB of DDR1333.
Could be faster, but this should do for not too much coin. (about 600 euros).
(continue reading…)

Our server in the datacenter is running slackware (duh) with a nice Xen installation on it.
Still running with Xen 3 using PAE since the last time I updated/upgraded it without any major problems for over 2 years now 🙂
(ignoring the time that the power supply let go of the the magic smoke)

So after the latest local root exploit thing, and testing it on some machines during har2009, I figured it might be nice to get the patch into my kernels. Running a webserver usually means you’re at risk after all, especially when it’s running wordpress 😉

So I grabbed the latest kernel that had that patch and went for the usual make menuconfig ordeal. After half an hour of selecting “yes”, “maybe”, “I guess so”, and
some XEN options (CONFIG_PARAVIRT_GUEST=y, CONFIG_XEN=y, CONFIG_HVC_DRIVER=y, CONFIG_XEN_BLKDEV_FRONTEND=y, CONFIG_XEN_NETDEV_FRONTEND=y, CONFIG_XEN_KBDDEV_FRONTEND=y, CONFIG_HVC_XEN=y, CONFIG_XEN_BALLOON=y, CONFIG_XEN_SCRUB_PAGES=y, CONFIG_XENFS=y, CONFIG_XEN_COMPAT_XENFS=y) I built the thing.
As I usually build bzImages I also did so here. make bzImage modules modules_install.
Half an hour later I had a shiny bzImage. Let’s try it on a test domain!

I copied the bzImage to /boot, changed the kernel = "/boot/vmlinuz-xen-old" option to the new place, and GO!
This is what it told me:

root@iejoor:/xen/hosts/purple# xm create -c purple.cfg-newkernel
Using config file "./purple.cfg-newkernel".
Started domain purple
root@iejoor:/xen/hosts/purple#

Huh, where’s my console?
Checking xm list it seemed to be there… but paused… and with constantly increasing ids. Waaait a minute!
Checking the log files (xend.log in this case) revealed a secret:

[2009-08-18 16:40:01 16116] DEBUG (DevController:162) Waiting for devices irq.
[2009-08-18 16:40:01 16116] DEBUG (DevController:162) Waiting for devices vkbd.
[2009-08-18 16:40:01 16116] DEBUG (DevController:162) Waiting for devices vfb.
[2009-08-18 16:40:01 16116] DEBUG (DevController:162) Waiting for devices console.
[2009-08-18 16:40:01 16116] DEBUG (DevController:167) Waiting for 0.
[2009-08-18 16:40:01 16116] DEBUG (DevController:162) Waiting for devices pci.
[2009-08-18 16:40:01 16116] DEBUG (DevController:162) Waiting for devices ioports.
[2009-08-18 16:40:01 16116] DEBUG (DevController:162) Waiting for devices tap.
[2009-08-18 16:40:01 16116] DEBUG (DevController:162) Waiting for devices vtpm.
[2009-08-18 16:40:01 16116] INFO (XendDomain:1165) Domain purple (35) unpaused.
[2009-08-18 16:40:01 16116] WARNING (XendDomainInfo:1240) Domain has crashed: name=purple id=35.
[2009-08-18 16:40:01 16116] DEBUG (XendDomainInfo:1879) XendDomainInfo.destroy: domid=35
[2009-08-18 16:40:01 16116] DEBUG (XendDomainInfo:1896) XendDomainInfo.destroyDomain(35)

Note the ‘WARNING’ line. Crashed?!
Gee, that’s … interesting. Why? Took me 5 minutes to find the other log file, but xend-debug.log had a magic line:
ERROR Invalid kernel: xc_dom_find_loader: no loader found
… great. Another why.
In case you’re wondering, the increasing status in ‘xm list’ was caused by the on_crash = 'reboot' line in the xen host config.
I quickly destroyed the doman and changed it to a oneshot try: on_crash = 'destroy'

After some searching another hint presented itself. Aren’t they nice?
This hint was: “Xen is a retarded piece of cancer and can’t decypher the bzImage format, try vmlinux instead”. Aha!
Back to the kernel, make vmlinux, copy, and another try to boot it. Obviously this was way too simple. It still crashed.
Checking my old kernel that works for both dom0 and domU with file I noticed that gz should at least work.

# file /boot/vmlinuz-2.6*
/boot/vmlinuz-2.6.18.8-xen: gzip compressed data, from Unix, last modified: Tue Nov 25 16:13:16 2008, max compression
/boot/vmlinuz-new: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped


Some more details about the crashing domains can be found using xm dmesg
It gave me something like:

(XEN) traps.c:413:d38 Unhandled general protection fault fault/trap [#13] on VCPU 0 [ec=0000]
(XEN) domain_crash_sync called from entry.S (ff18928e)
(XEN) Domain 38 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-3.2.3 x86_32p debug=n Not tainted ]----
(XEN) CPU: 3
(XEN) EIP: e019:[]
(XEN) EFLAGS: 00000282 CONTEXT: guest
(XEN) eax: 8000c068 ebx: c064c040 ecx: 80000000 edx: 00000cf8
(XEN) esi: c0651f3c edi: c0651f30 ebp: c06981b8 esp: c0651f14
(XEN) cr0: 8005003b cr4: 000006f0 cr3: 00bd5c80 cr2: 00000000
(XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019
(XEN) Guest stack trace from esp=c0651f14:
(XEN) 00000000 c03e9e60 0001e019 00010082 c04bd0cd 00000068 00000000 00000000
(XEN) 00002003 00000000 00003030 00000002 00000007 c064c07c c065dfd8 00000000
(XEN) c06423c0 c064c100 c0651fd8 c065a63f 00000005 00000000 00000000 00000000
(XEN) c065d02b 006faee4 00000000 00000000 c056dad4 00100000 00000000 00100000
(XEN) 00100000 00000000 006faee4 c065d27c 006faee4 00000000 00000000 c0651fe8
(XEN) 00000000 00000000 00000000 c0651fe8 00000000 00000000 c065756f c056dd50
(XEN) c04c5020 c0657073 c0651ff4 c065973e 00000000 17898175 00800001 03040800
(XEN) 00100f22 00000000 c08e0000 c04ba91b c04ba923 c0103371 c0103878 c0659a92
(XEN) c01039c7 c0103afc c0103d1a c0104004 c0104163 c01041eb c010451d c010457c
(XEN) c0659eb7 c0659ebf c04ba975 c04baa22 c0105536 c01055ae c0105781 c0105c5c
(XEN) c0105c9e c0106253 c0106345 c0106831 c010683d c0107b07 c010825e c0108333
(XEN) c065a45c c065a46a c0108e56 c065a982 c065a98a c0109bf0 c065af2c c065af93
(XEN) c065afe9 c065b042 c065b09b c065b0f4 c065b14d c065b1a6 c065b1ff c065b258
(XEN) c065b2b1 c065b32d c065b341 c065b397 c065b3f0 c065b449 c065c14f c065c157
(XEN) c010aee5 c010aef3 c010af77 c010af85 c065d7be c065d7d1 c010bdc3 c010be22
(XEN) c010c113 c010c14a c010c1c6 c010c2f3 c010c41a c010c443 c010c4dd c010d267
(XEN) c010d4cb c010d77b c010d782 c010de76 c010defd c010df0c c010df3f c010df49
(XEN) c010df84 c010df8c c010df94 c04bb1d7 c04bb466 c04bb4db c04bb5b9 c04bb60f
(XEN) c04bb62f c04bbb8b c04bbd60 c065de79 c065de81 c04bc041 c04bc46b c04bc50d
(XEN) c04bc899 c04bc902 c065e012 c065e01a c065e028 c065e030 c065e038 c065e040

As you can see, that’s really useful….. 😉

A useful page with some info can be found here. It confirms that a gz kernel should work (but bz probably doesn’t) since I’m still running Xen 3.2. However, I can’t find a good reason for why it won’t work.

Google to the rescue! Hard to find a useful keyword, since most xen kernel issues seem to be similar, but eventually I found this tidbit:
tiny kernel patch.
Weird that this should be needed, one would hope that basic shit like this would work after 8 kernel versions, but obviously they’re all retards when it comes to this.
Thanks Jeremy Fitzhardinge for the patch!
Just for quick reference, this is the actual patch:

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 28e5f59..e2485b0 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -356,7 +356,7 @@ static void __cpuinit early_init_amd(struct cpuinfo_x86 *c)
#endif
#if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_PCI)
/* check CPU config space for extended APIC ID */
- if (c->x86 >= 0xf) {
+ if (cpu_has_apic && c->x86 >= 0xf) {
unsigned int val;
val = read_pci_config(0, 24, 0, 0x68);
if ((val & ((1 << 17) | (1 << 18))) == ((1 << 17) | (1 << 18)))

So much for 'vanilla'.

However, it boots now:

root@iejoor:/xen/hosts/purple# xm create -c purple.cfg-newkernel
Using config file "./purple.cfg-newkernel".
Started domain purple
Reserving virtual address space above 0xf5800000
Linux version 2.6.30.5-jemoeder (root@iejoor) (gcc version 4.1.2) #9 SMP Tue Aug 18 22:59:38 CEST 2009
KERNEL supported cpus:
Intel GenuineIntel
AMD AuthenticAMD
NSC Geode by NSC
Cyrix CyrixInstead
Centaur CentaurHauls
Transmeta GenuineTMx86
Transmeta TransmetaCPU
UMC UMC UMC UMC
ACPI in unprivileged domain disabled
and a lot more yadieyada until it hits a new wall: root device.
Well, that sounds solvable.

In fact, here's a solution. What you say?
"AAAAH, I GET NOTHING, IT WON'T EVEN CRASH ANYMORE, JUST NO OUTPUT???!"
Ah yeah, I forgot to mention: they changed the console device as well as the block device. So here's a solution for both issues:
Edit your xen host config file and make it so:

root = "/dev/xvda1 ro"
extra = "xencons=hvc0"

(xvda1 is what used to be sda1, you can figure out the rest).

And after all this: HAHA! Success is mine!
Except of course for the undeniable fact that my domU has a fucked up fstab and all, but no issues there 🙂
Now go mess up your own system! Oh, I see... you already did. Good luck fixing it 😉

Update

I just tested a testing kernel -- 2.6.31-rc8, and it seems like they fixed it. Probably has been fixed in the testing branch for quite a while now, but still not in stable 2.6.30 🙂
Let's hope they release 2.6.31 soon.