Jul 292015
 

Just a quick CPU benchmark with Phoronix test suite, comparing -cpu qemu64 and -cpu host (on Xeon E3-1241v3, 4vCPU/4GB virtuals).

Note: single run (fire & forget), virtual machines on the same physical hardware and benchmarks run simultaneously. YMMV.

Benchmark qemu64 host Higher/Lower better?
pts/stream-1.2.0 [Type: Copy] 14166.98 MB/s 14171.50 MB/s Higher
pts/stream-1.2.0 [Type: Scale] 13964.65 MB/s 14007.75 MB/s Higher
pts/stream-1.2.0 [Type: Triad] 15755.66 MB/s 15851.89 MB/s Higher
pts/stream-1.2.0 [Type: Add] 15730.77 MB/s 15863.64 MB/s Higher
pts/apache-1.6.1 25028.87 Requests Per Second 35859.45 Requests Per Second Higher
pts/john-the-ripper-1.5.1 [Traditional DES] 5849000 Real C/S 7179500 Real C/S Higher
pts/john-the-ripper-1.5.1 [Blowfish] 3170 Real C/S 3249 Real C/S Higher
pts/ttsiod-renderer-1.5.0 102.00 FPS 93.75 FPS Higher
pts/x264-1.9.0 86.56 FPS 94.52 FPS Higher
pts/graphics-magick-1.6.1 [HWB Color Space] 173 Iterations Per Minute 170 Iterations Per Minute Higher
pts/graphics-magick-1.6.1 [Local Adaptive Thresholding] 92 Iterations Per Minute 88 Iterations Per Minute Higher
pts/graphics-magick-1.6.1 [Sharpen] 95 Iterations Per Minute 102 Iterations Per Minute Higher
pts/graphics-magick-1.6.1 [Resizing] 159 Iterations Per Minute 156 Iterations Per Minute Higher
pts/himeno-1.1.0 1722.79 MFLOPS 1840.71 MFLOPS Higher
pts/compress-7zip-1.6.0 10173 MIPS 10291 MIPS Higher
pts/c-ray-1.1.0 44.54 Seconds 39.76 Seconds Higher
pts/compress-pbzip2-1.4.0 11.99 Seconds 13.95 Seconds Lower
pts/smallpt-1.0.1 153 Seconds 153 Seconds Lower
pts/crafty-1.3.0 71.60 Seconds 71.48 Seconds Lower
pts/encode-flac-1.5.0 7.38 Seconds 6.12 Seconds Lower
pts/encode-mp3-1.4.0 11.71 Seconds 11.21 Seconds Lower
pts/ffmpeg-2.4.0 18.99 Seconds 14.37 Seconds Lower
pts/povray-1.1.2 310.35 Seconds 248.59 Seconds Lower
pts/tachyon-1.1.1 26.57 Seconds 17.10 Seconds Lower
pts/openssl-1.9.0 286.50 Signs Per Second 543.67 Signs Per Second Lower
pts/mafft-1.4.0 7.40 Seconds 7.24 Seconds Lower
pts/gcrypt-1.0.3 1793 Microseconds 1647 Microseconds Lower

No wonder why UpCloud changed their parameters, -host usually wins…

Apr 012015
 

Beware, so you (too) won’t be bitten by this.

If you’re running vanilla KVM with default qemu-kvm -packages in RHEL (CentOS and probably others):

https://git.centos.org/blob/rpms!qemu-kvm!/958e1b8dccf9809600478f316ab641d490881fe7/SOURCES!kvm-rhel-Drop-machine-type-pc-q35-rhel7.0.0.patch;jsessionid=mc5igseasal0axkra6qhd4it

In short, q35 -support was a technical preview which is now dropped from qemu-kvm (qemu-kvm-rhev -only feature from now on), back to “pc”…

Nov 202014
 

As a reminder, how to enable serial console under KVM.

Hypervisor (CentOS 7):
– no changes required if required pty -devices are created automatically (-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 in guest command line)
–  if not found, you need the following bit in the devices section of virtual guests XML-file (modifying usually requires a full shutdown-start sequence for the virtual):

<serial type='pty'>
  <target port='0'/>
</serial>
<console type='pty'>
  <target type='serial' port='0'/>
</console>

Guest (Debian 7):
– modify /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet"
#GRUB_TERMINAL=console

->

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0 quiet"
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial"

Uncomment the following line from /etc/inittab:

T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100

Run update-grub and reboot virtual machine – now you should be able to use virsh console at the hypervisor.

<edit-16.1.2015>
– Added XML-configuration for serial/console
– Dropped 9600bps speed configuration
</edit>

Dec 102011
 

Once upon a time, virtual was installed under full virtualization (KVM) -mode. Network wasn’t bridged, it was routed.

And then the problem: IPv6 -traffic flowed nicely inbound, but outbound was capped to about 128 kbps.

Troubleshooting: after googling around with ipv6, kvm and debian we came around to this, Debian bug report about GSO Ipv6 issues under KVM. It’s supposed to be fixed in 2.6.32-5-amd64 (2.6.32-39) -package…well, upgrading didn’t work for us, propably another (similar kind of) bug or something needs to be done at host-machine.

Workaround:  disabling virtio_net’s gso worked for us:

ifdown eth0; modprobe -r virtio_net; modprobe virtio_net gso=0; ifup eth0
Dec 092011
 

Debian Squeeze was released 06.02.2011 and Lenny’s support will (probably) be is discontinued since 06.02.2012.

 

Problem: apt-get update && apt-get dist-upgrade broke everything, server did not boot anymore.

Troubleshooting: squeeze has grub2, which our Xen 3.x and pygrub didn’t understand

Solution: upgrading with following steps, use apt-get or aptitude, whichever you like.

  1. Update Lenny
    aptitude update
    aptidude upgrade
  2. Replace lenny with squeeze in /etc/apt/sources.list – or add necessary entries to another file under /etc/apt/sources.list.d/
    deb http://ftp.fi.debian.org/debian/ squeeze main contrib non-free
    deb http://ftp.fi.debian.org/debian/ squeeze-updates main contrib non-free
    deb http://security.debian.org/ squeeze/updates main contrib non-free
  3. Update repository
    aptitude update
  4. Upgrade critical parts first
    aptitude install dpkg apt aptitude
  5. (Dist-)upgrade rest
    aptitude upgrade
    aptitude dist-upgrade
  6. Replace grub2 with grub1 (or just keep your old menu.lst at /boot/grub/)
    aptitude purge grub-pc
    aptitude install grub-legacy
  7. Check that /boot/grub/menu.lst exists and defaults to right kernel
  8. Reboot and hope for the best

 

Also remember to use 2.6.39 -kernel from backports for live migration to work.
Update 01/2013: 2.6.32 -kernel usually works just fine, Lenny’s EOL date is 6.2.2012.