I'm trying to import an existing kvm VM into oVirt 4.1. It a new server
with a fresh installation of oVirt.
I'm working with the oVirt gui to achieve this.
After moving the VM from the old system into the export folder, the gui
allows me to import it.
The import seems to succeed. But after the VM is imported it fails to start.
Giving this error:
"VM zarafa is down with error. Exit message: Failed to find the
I can add a rule into ipdates such as this
iptables -I INPUT -s 192.168.0.10 -p tcp -m tcp --dport 5666 -j ACCEPT
I can see the addition has succeeded with this
iptables-save > /etc/sysconfig/iptables
But a reboot of the Engine VM (not the Host) doesn't keep the new rule,
and I was expecting that during bootup CentOS would read from
Alas it isn't.
Found a solution.
After reading this
I installed iptables-services
But once installed I found that iptables -L showed no rules.
thankfully I still had the default hosted-engine rules in
iptables-restore < /etc/sysconfig/iptables
service iptables save
restored the default hosted-engine rules including my rule for 5666.
Rebooting the hosted-engine VM and my rule 5666 for NRPE is still there.
To answer your other questions
> Did you ask to configure the firewall during engine-setup?
Looks like it setup firewalld for me.
> Alternatively, it's recommended to use firewalld.
For the moment I have disabled firewalld and are using iptables....Is
there a reason why firewalld is preferred over iptables?
------ Original Message ------
From: "Yedidyah Bar David" <didi(a)redhat.com>
To: "Andrew Dent" <adent(a)ctcroydon.com.au>
Cc: "users" <users(a)ovirt.org>
Sent: 29/05/2017 9:26:23 PM
Subject: Re: [ovirt-users] Ovirt Hosted-Engine VM iptables
>On Mon, May 29, 2017 at 1:14 PM, Andrew Dent <adent(a)ctcroydon.com.au>
>> I would like to add rules into the iptables of the Hosted Engine VM
>> I am wanting to monitor the Ovirt Engine using Nagios -> NRPE and I
>> like to open port 5666
>> the version is oVirt Engine Version: 184.108.40.206-1.el7.centos
>> I have tried using the normal process for iptables (iptables-save
>> it seems that the file
>> is ignored when the Ovirt Engine VM starts.
>What do you mean in "ignored"?
>What's the output of 'iptables-save'?
>Did you ask to configure the firewall during engine-setup?
>> How can I add permanent iptables rules into the Engine VM?
>On the engine vm (unlike hosts), the only thing that touches iptables
>is engine-setup. Before doing that it asks you if you want to configure
>the firewall. There aren't currently means to add your custom rules -
>either you manage it all by yourself or you let engine-setup do that.
>Alternatively, it's recommended to use firewalld. engine-setup can
>add to firewalld the stuff it wants, and you still can add your own
>If I got you wrong and you refer to the hosts (not engine), see also:
>> Kind regards
>> Users mailing list
after an upgrade I get the following errors in the web gui:
VDSM ovirt-node01 command SpmStatusVDS failed: (13, 'Sanlock resource
read failure', 'Permission denied')
VDSM ovirt-node03 command HSMGetAllTasksStatusesVDS failed: Not SPM
These messages happen from all nodes.
I can stop vms and migrate them but I cannot start any vm again
How do I get bet to a sane state where one node is SPM.
I seem to remember that online resize of VirtIO disk is possible.
Now I have an Oracle Linux VM with 2.6.39-400.215.3.el6uek.x86_64 kernel
where I resize a disk (/dev/vdb) from 500Gb to 900Gb.
Apparently the kernel acquired the change because in /var/log/messages I
May 31 14:16:16 dbatest3 kernel: virtio_blk virtio6: new size: 1887436800
512-byte logical blocks (966 GB/900 GiB)
but fdisk seems not to be able to recognize it:
[root@dbatest3 ~]# fdisk -l /dev/vdb
Disk /dev/vdb: 536.9 GB, 536870912000 bytes
16 heads, 63 sectors/track, 1040253 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
oVirt is 4.1.1 with hypervisor running the VM being in CentOS 7.3 with
libvirt 2.0.0-10.el7_3.5 and qemu-kvm-ev 2.6.0-28.el7_3.6.1
I was not able to find the rescan option I eventually need to execute (but
I think not necessary because the kernel already detected it).
Is this a bug in fdisk itself?
I have an LVM PV on the whole disk, but of course a pvresize doesn't notice
any change in it.
I verified that in my kernel the ACPI PCI hotplug feature is compiled into
the kernel and not as a module:
[root@dbatest3 ~]# grep "CONFIG_HOTPLUG_PCI_ACPI="
I tried also this:
echo 1 > /sys/devices/pci0000\:00/0000\:00\:09.0/rescan
because of the tree below:
[root@dbatest3 ~]# ll /sys/devices/pci0000\:00/0000\:00\:09.0/virtio6/
drwxr-xr-x 3 root root 0 May 31 11:45 block
-r--r--r-- 1 root root 4096 May 31 14:19 device
lrwxrwxrwx 1 root root 0 May 31 14:19 driver ->
-r--r--r-- 1 root root 4096 May 31 14:19 features
-r--r--r-- 1 root root 4096 May 31 14:19 modalias
drwxr-xr-x 2 root root 0 May 31 14:18 power
-r--r--r-- 1 root root 4096 May 31 14:19 status
lrwxrwxrwx 1 root root 0 May 31 14:16 subsystem -> ../../../../bus/virtio
-rw-r--r-- 1 root root 4096 May 31 14:16 uevent
-r--r--r-- 1 root root 4096 May 31 14:19 vendor
[root@dbatest3 ~]# ll /sys/devices/pci0000\:00/0000\:00\:09.0/virtio6/block
drwxr-xr-x 7 root root 0 May 31 11:45 vdb
[root@dbatest3 ~]# ll
-r--r--r-- 1 root root 4096 May 31 14:19 alignment_offset
lrwxrwxrwx 1 root root 0 May 31 14:19 bdi ->
-r--r--r-- 1 root root 4096 May 31 14:19 capability
-r--r--r-- 1 root root 4096 May 31 14:15 dev
lrwxrwxrwx 1 root root 0 May 31 14:19 device -> ../../../virtio6
-r--r--r-- 1 root root 4096 May 31 14:19 discard_alignment
-r--r--r-- 1 root root 4096 May 31 14:19 ext_range
drwxr-xr-x 2 root root 0 May 31 14:18 holders
-r--r--r-- 1 root root 4096 May 31 14:19 inflight
drwxr-xr-x 2 root root 0 May 31 14:18 power
drwxr-xr-x 3 root root 0 May 31 14:16 queue
-r--r--r-- 1 root root 4096 May 31 14:19 range
-r--r--r-- 1 root root 4096 May 31 14:16 removable
-r--r--r-- 1 root root 4096 May 31 14:19 ro
-r--r--r-- 1 root root 4096 May 31 14:16 serial
-r--r--r-- 1 root root 4096 May 31 14:19 size
drwxr-xr-x 2 root root 0 May 31 14:18 slaves
-r--r--r-- 1 root root 4096 May 31 14:19 stat
lrwxrwxrwx 1 root root 0 May 31 11:45 subsystem ->
drwxr-xr-x 2 root root 0 May 31 14:18 trace
-rw-r--r-- 1 root root 4096 May 31 11:45 uevent
Any hint to avoid guest reboot and have fdisk recognize the happened resize?
In the future I'm going to upgrade from the current 6.5 version, so that I
can also use Virtio-SCSI driver and so standard SCSI commands when adding
disks or resizing existing ones, but this VM was "imported" by another
environment and I have initially to be stick with it in this precise
Thanks in advance,