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”…
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>
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