Archive

Posts Tagged ‘Fedora’

VRRP on oVirt not working

October 18th, 2013 Comments off

I’m using oVirt as KVM hypervisor and wanted to setup some high-available FreeBSD and pfSense Clusters with CARP/uCARP. Unfortunately, neither CARP nor uCARP were working. I could see VRRP advertisements on my KVM hypervisor coming in from one pfSense/FreeBSD VM…

kvm# tcpdump -i vnet13 -s 1500 -n -X  |grep -i vrrp
tcpdump: WARNING: vnet13: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vnet13, link-type EN10MB (Ethernet), capture size 1500 bytes
11:17:46.386437 IP 10.10.10.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36
11:17:47.353269 IP 10.10.10.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36
11:17:48.363266 IP 10.10.10.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36

…but these VRRP packets never reached the interface of the secondary pfsense/FreeBSD VM. It turns out that a new network-filters feature in oVirt prevented VRRP packets from getting forwarded. This feature was introduced in oVirt 3.2 and prevents guests from spoofing other mac-addresses than these which are assigned by the oVirt engine. A very kind guy on the oVirt mailinglist told me about this.

The fix is to disable the anti-spoofing feature on the oVirt engine (assuming running oVirt 3.3):

  1. On oVirt engine run: engine-config -s EnableMACAntiSpoofingFilterRules=false –cver=3.3
  2. Restart the ovirt-engine service: systemctl restart ovirt-engine
  3. Restart the VMs

Thanks to Moti Asayag from RedHat for this useful answer.

Disable automatic NIC renaming on Fedora

August 18th, 2013 Comments off

On Fedora I had some trouble with the so-called “predictable network interface names” feature and a rather complex network configuration. Good to know: There is an easy way to disable this feature by removing a RPM package:

# rpm -qa biosdevname
biosdevname-0.4.1-4.fc19.x86_64

# rpm -ev biosdevname-0.4.1-4.fc19.x86_64
Preparing packages…
biosdevname-0.4.1-4.fc19.x86_64

Now reboot your server, re-configure networking and everything should be working in the right way. Of course, you have already disabled the terrible NetworkManager, don’t you?

Update: The above step only works for Fedora 17 or udev versions before 2.0. When running udev 2.0+ or Fedora 18+ you need an additional step:

touch /etc/udev/rules.d/80-net-name-slot.rules

There is an article on the Debian Wiki describing this and other “improvements” in udev 2.0.

Categories: [EN] Snippets Tags: , , ,

oVirt and dummy interfaces

July 30th, 2013 Comments off

As of oVirt 3.2 it is not possible to use dummy interfaces, they will silently be ignored and never appear on your admin panel. This is especially annoying when running an All-in-one setup (oVirt node + engine on the same host) and you want some local networks on your host for testing purposes.

There is an easy workaround for the fearless:

— /usr/lib64/python2.7/site-packages/vdsm/config.py.orig      2013-03-14 11:32:54.000000000 +0100
+++ /usr/lib64/python2.7/site-packages/vdsm/config.py   2013-05-16 16:34:27.722959670 +0200
@@ -38,7 +38,7 @@
(‘extra_mem_reserve’, ’65’,
‘Memory reserved for non-vds-administered programs.’),

–        (‘fake_nics’, ”,
+        (‘fake_nics’, ‘dummy*’,
‘Comma-separated list of fnmatch-patterns for dummy hosts nics to ‘
‘be shown to vdsm.’),

As you can see the fix is quite easy. Simply change the pattern and restart vdsmd. Note: You need to re-apply the fix everytime you update the oVirt packages. And there is a non-zero chance that the fix won’t work in a future version of oVirt. You have been warned.

This was discussed on the oVirt Users mailinglist.

Categories: [EN] Tech Tags: , ,

oVirt: VM bootet nicht von ISO Image

May 15th, 2013 Comments off

Auf einem oVirt 3.2.1 Setup hatte ich ein seltsames Problem: Es konnte keine VM mehr von CD-ROM (ISO Image) booten. Im oVirt Admin Portal wurde nur eine nichtssagende Fehlermeldung angezeigt. Also habe ich auf dem oVirt Engine Server einen Blick in das engine.log geworfen und bekam eine bessere Meldung zu sehen:

2013-04-29 16:38:33,744 INFO  [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-9) Received a cdrom Device without an address when processing VM 658ca53d-12cf-4b03-973d-a0d2cdf5315f devices, skipping device: […]

OK, also irgendetwas gefällt oVirt scheinbar an der CD-ROM Konfiguration nicht. Im Admin Portal ist nichts Auffälliges zu finden… Also auf dem oVirt Node Server mit virsh -r (Kommandos list + dumpxml) noch einen Blick in die VM Konfiguration werfen:

    <disk type=’file’ device=’cdrom’>
<driver name=’qemu’ type=’raw’/>
<source startupPolicy=’optional’/>
<target dev=’hdc’ bus=’ide’/>
<readonly/>
<serial></serial>
<boot order=’1’/>
<alias name=’ide0-1-0’/>
<address type=’drive’ controller=’0′ bus=’1′ target=’0′ unit=’0’/>
</disk>

Und tatsächlich: oVirt hat definitiv kein ISO Image eingebunden. Also kein Wunder, dass die VM nicht von CD-ROM booten kann. Auf der oVirt Mailingliste wusste leider auch niemand Rat. Also habe ich die betroffene oVirt Node kurzerhand in den Maintenance Mode gesetzt und – einige Minuten später – wieder aktiviert. Und siehe da: Plötzlich kann wieder problemlos jedes ISO Image eingebunden und davon gebootet werden. Die Ursache für diesen Fehler ist zwar weiterhin unklar, aber immerhin ist die Funktionalität vorerst wiederhergestellt.

Categories: [DE] Tech Tags: , , , ,

oVirt: VM startet nicht

May 3rd, 2013 Comments off

Unter oVirt kann es vorkommen, dass eine VM nicht eingeschaltet werden kann. Im oVirt Frontend erscheint dann folgende Meldung:

Cannot run VM. Host swap percentage is above the defined threshold. – Check your configuration parameters for Host Swap Percentage.

Offensichtlich benutzt unsere oVirt Node, auf der die VM gestartet werden soll, bereits zu viel Swap. Mit top sieht man dann wahrscheinlich, dass nur wenig Swap verwendet wird und die RAM-Auslastung gar nicht so hoch ist. Also warum dann diese Meldung? Wir schauen uns auf dem oVirt Engine Server einmal die Einstellung für dieses Limit an:

# engine-config -g BlockMigrationOnSwapUsagePercentage
BlockMigrationOnSwapUsagePercentage: 0 version: general

In der Standardeinstellung darf bei oVirt gar kein Swap in Benutzung sein, damit das Starten einer VM möglich ist. Also kein Wunder, dass früher oder später wohl jeder diese Meldung erhält, denn auch auf großzügig dimensionierten Systemen wird irgendwann mal ein wenig Swap verwendet. Diese Einstellung ist geradezu extrem konservativ – und für meinen Geschmack um Größenordnungen zu niedrig eingestellt. Deshalb ändern wir sie auch gleich:Watch Full Movie Online Streaming Online and Download

# engine-config -s BlockMigrationOnSwapUsagePercentage=90 –cver=general
# service ovirt-engine restart

Wichtig: Nach dem ändern der Einstellung muss der oVirt Engine Dienst neugestartet werden (wie im obigen Beispiel). Ab sofort wird erst bei 90% belegtem Swap-Speicher der Start weiterer VMs verhindert. Eine Übersicht der Konfigurationsoptionen findet sich übrigens in der offiziellen Dokumentation zu RHEV 3.1.

Categories: [DE] Tech Tags: , , , , ,
css.php