Deleting old export backups in oVirt
by Wesley Stewart
I am using a script to make weekly backups of my VMs, but I really dont
need more than 1-2 weeks per VM. I pulled open my NFS share where the
export domain points to, but all the VM's have a long guid and I cannot see
which folder corresponds to which backup.
For example, when I click "Import" and then "load" one of the backup VMs
listed is:
Ubuntu_Server_BACKUP_20170731_012832
All I see are folders that look like:
"f42fd734-e5e6-964e-87D1-8dbc554f0e19"
Going into the folder there is a "META" file, which I can open, but there
is no reference to the actual VM name. Is there an easy way to tell which
folder goes to which VM?
-Wesley
6 years, 8 months
supervdsmd IOError to /dev/stdout
by Richard Chan
After an upgrade to 4.0 I have a single host that cannot start supervdsmd
because of IOError on /dev/stdout. All other hosts upgraded correctly.
In the systemd unit I have to hack StandardOutput=null.
Any thing I have overlooked? The hosts are all identical and it is just
this one
that has this weird behaviour.
--
Richard Chan
6 years, 8 months
Lost disk image on guest
by Paul-Erik Törrönen
Updated the ovirt to latest stable and after the host reboot (hardware
was relocated) all of the VMs on the host are ok except one which has
lost it's disk image (it still exists physically on the storage device).
Uploading this image to the storage fails (I get the usual initiating -
0/XXXMB uploaded - Paused by system, the ovirt-imageio-proxy is running
on the engine and has nothing in it's log), and I'm also unable to
create any new disks when editing the problematic VM (the
Attach/Create/+/--buttons are all grayed out).
The question is: Is the only course to 'fix' this situation to delete
the whole VM and install it from scratch?
Poltsi
6 years, 8 months
Ovirt 4.1 gluster with libgfapi
by TranceWorldLogic .
Hi,
I was going through gluster document it was talking about libgfapi, that
gives better performance.
And I also went through many bug description and comment and mail thread in
ovirt group.
But still not understood, how to enable libgfapi ?
Is it supported in 4.1 ? I am confuse.
Please help me to understand whether it supported or not.
If supported, then how can I enable it ? or use it ?
Thanks,
~Rohit
6 years, 8 months
oVirt 3.6.x and Centos 6.9
by Neil
Hi guys,
I upgraded to the latest ovirt-engine-3.6.7.5-1.el6.noarch available in the
ovirt 3.6 repo, however I seem to be encountering a known bug (
https://bugzilla.redhat.com/show_bug.cgi?id=1387949) which looks to be
fixed in ovirt 3.6.9.2 but I can't seem to find out how to install this.
I was hoping it was via http://resources.ovirt.org/pub/ovirt-3.6-snapshot
but this link is dead.
Is anyone using ovirt 3.6.9 and how does one obtain it?
The issues I'm facing is, after trying to update my cluster version to 3.6,
my hosts weren't compatible, as it says they only compatible with version
3.3, 3.4 and 3.5 etc. I then upgraded 1 hosts to Centos 6.9 and installed
and updated the latest vdsm from the 3.6 repo, but this still didn't allow
me to change my cluster version. I then rolled back the cluster version to
3.5.
At the moment because I've upgraded 1 host, I can't select this host as SPM
and I'm wondering if I can upgrade my remaining hosts, or will this prevent
any hosts from being my SPM? I'm seeing the following error "WARNING
Unrecognized protocol: 'SUBSCRI'" on my upgraded host.
I'm wanting to upgrade to the latest 3.6 as well as upgrade all my hosts,
so that I can start the ovirt 4 upgrade next.
Please could I have some guidance on this?
Thank you.
Regards.
Neil Wilson.
6 years, 8 months
sanlock ids file broken after server crash
by Johan Bernhardsson
Hello,
The ids file for sanlock is broken on one setup. The first host id in
the file is wrong.
>From the logfile i have:
verify_leader 1 wrong space name 0924ff77-ef51-435b-b90d-50bfbf2e�ke7
0924ff77-ef51-435b-b90d-50bfbf2e8de7 /rhev/data-center/mnt/glusterSD/
Note the broken char in the space name.
This also apears. And it seams as the hostid too is broken in the ids
file:
leader4 sn 0924ff77-ef51-435b-b90d-50bfbf2e�ke7 rn ��7 afa5-3a91-415b-
a04c-221d3e060163.vbgkvm01.a ts 4351980 cs eefa4dd7
Note the broken chars there as well.
If i check the ids file with less or strings the first row where my
vbgkvm01 host are. That has broken chars.
Can this be repaired in some way without taking down all the virtual
machines on that storage?
/Johan
6 years, 8 months
VDSM Command failed: Heartbeat Exceeded
by Neil
Hi guys,
Please could someone assist me, my DC seems to be trying to re-negotiate
SPM and apparently it's failing. I tried to delete an old autogenerated
snapshot and shortly after that the issue seemed to start, however after
about an hour, the snapshot said successfully deleted, and then SPM
negotiated again albeit for a short period before it started trying to
re-negotiate again.
Last week I upgraded from ovirt 3.5 to 3.6, I also upgraded one of my 4
hosts using the 3.6 repo to the latest available from that repo and did a
yum update too.
I have 4 nodes and my ovirt engine is a KVM guest on another physical
machine on the network. I'm using an FC SAN with ATTO HBA's and recently
we've started seeing some degraded IO. The SAN appears to be alright and
the disks all seem to check out, but we are having rather slow IOPS at the
moment, which we trying to track down.
ovirt engine CentOS release 6.9 (Final)
ebay-cors-filter-1.0.1-0.1.ovirt.el6.noarch
ovirt-engine-3.6.7.5-1.el6.noarch
ovirt-engine-backend-3.6.7.5-1.el6.noarch
ovirt-engine-cli-3.6.2.0-1.el6.noarch
ovirt-engine-dbscripts-3.6.7.5-1.el6.noarch
ovirt-engine-extension-aaa-jdbc-1.0.7-1.el6.noarch
ovirt-engine-extensions-api-impl-3.6.7.5-1.el6.noarch
ovirt-engine-jboss-as-7.1.1-1.el6.x86_64
ovirt-engine-lib-3.6.7.5-1.el6.noarch
ovirt-engine-restapi-3.6.7.5-1.el6.noarch
ovirt-engine-sdk-python-3.6.7.0-1.el6.noarch
ovirt-engine-setup-3.6.7.5-1.el6.noarch
ovirt-engine-setup-base-3.6.7.5-1.el6.noarch
ovirt-engine-setup-plugin-ovirt-engine-3.6.7.5-1.el6.noarch
ovirt-engine-setup-plugin-ovirt-engine-common-3.6.7.5-1.el6.noarch
ovirt-engine-setup-plugin-vmconsole-proxy-helper-3.6.7.5-1.el6.noarch
ovirt-engine-setup-plugin-websocket-proxy-3.6.7.5-1.el6.noarch
ovirt-engine-tools-3.6.7.5-1.el6.noarch
ovirt-engine-tools-backup-3.6.7.5-1.el6.noarch
ovirt-engine-userportal-3.6.7.5-1.el6.noarch
ovirt-engine-vmconsole-proxy-helper-3.6.7.5-1.el6.noarch
ovirt-engine-webadmin-portal-3.6.7.5-1.el6.noarch
ovirt-engine-websocket-proxy-3.6.7.5-1.el6.noarch
ovirt-engine-wildfly-8.2.1-1.el6.x86_64
ovirt-engine-wildfly-overlay-8.0.5-1.el6.noarch
ovirt-host-deploy-1.4.1-1.el6.noarch
ovirt-host-deploy-java-1.4.1-1.el6.noarch
ovirt-image-uploader-3.6.0-1.el6.noarch
ovirt-iso-uploader-3.6.0-1.el6.noarch
ovirt-release34-1.0.3-1.noarch
ovirt-release35-006-1.noarch
ovirt-release36-3.6.7-1.noarch
ovirt-setup-lib-1.0.1-1.el6.noarch
ovirt-vmconsole-1.0.2-1.el6.noarch
ovirt-vmconsole-proxy-1.0.2-1.el6.noarch
node01 (CentOS 6.9)
vdsm-4.16.30-0.el6.x86_64
vdsm-cli-4.16.30-0.el6.noarch
vdsm-jsonrpc-4.16.30-0.el6.noarch
vdsm-python-4.16.30-0.el6.noarch
vdsm-python-zombiereaper-4.16.30-0.el6.noarch
vdsm-xmlrpc-4.16.30-0.el6.noarch
vdsm-yajsonrpc-4.16.30-0.el6.noarch
gpxe-roms-qemu-0.9.7-6.16.el6.noarch
qemu-img-rhev-0.12.1.2-2.479.el6_7.2.x86_64
qemu-kvm-rhev-0.12.1.2-2.479.el6_7.2.x86_64
qemu-kvm-rhev-tools-0.12.1.2-2.479.el6_7.2.x86_64
libvirt-0.10.2-62.el6.x86_64
libvirt-client-0.10.2-62.el6.x86_64
libvirt-lock-sanlock-0.10.2-62.el6.x86_64
libvirt-python-0.10.2-62.el6.x86_64
node01 was upgraded out of desperation after I tried changing my DC and
cluster version to 3.6, but then found that none of my hosts could be
activated out of maintenance due to an incompatibility with 3.6 (I'm still
not sure why as searching seemed to indicate Centos 6.x was compatible. I
then had to remove all 4 hosts, and change the cluster version back to 3.5
and then re-add them. When I tried changing the cluster version to 3.6 I
did get a complaint about using the "legacy protocol" so on each host under
Advanced, I changed them to use the JSON protocol, and this seemed to
resolve it, however once changing the DC/Cluster back to 3.5 the option to
change the protocol back to Legacy is no longer shown.
node02 (Centos 6.7)
vdsm-4.16.30-0.el6.x86_64
vdsm-cli-4.16.30-0.el6.noarch
vdsm-jsonrpc-4.16.30-0.el6.noarch
vdsm-python-4.16.30-0.el6.noarch
vdsm-python-zombiereaper-4.16.30-0.el6.noarch
vdsm-xmlrpc-4.16.30-0.el6.noarch
vdsm-yajsonrpc-4.16.30-0.el6.noarch
gpxe-roms-qemu-0.9.7-6.14.el6.noarch
qemu-img-rhev-0.12.1.2-2.479.el6_7.2.x86_64
qemu-kvm-rhev-0.12.1.2-2.479.el6_7.2.x86_64
qemu-kvm-rhev-tools-0.12.1.2-2.479.el6_7.2.x86_64
libvirt-0.10.2-54.el6_7.6.x86_64
libvirt-client-0.10.2-54.el6_7.6.x86_64
libvirt-lock-sanlock-0.10.2-54.el6_7.6.x86_64
libvirt-python-0.10.2-54.el6_7.6.x86_64
node03 CentOS 6.7
vdsm-4.16.30-0.el6.x86_64
vdsm-cli-4.16.30-0.el6.noarch
vdsm-jsonrpc-4.16.30-0.el6.noarch
vdsm-python-4.16.30-0.el6.noarch
vdsm-python-zombiereaper-4.16.30-0.el6.noarch
vdsm-xmlrpc-4.16.30-0.el6.noarch
vdsm-yajsonrpc-4.16.30-0.el6.noarch
gpxe-roms-qemu-0.9.7-6.14.el6.noarch
qemu-img-rhev-0.12.1.2-2.479.el6_7.2.x86_64
qemu-kvm-rhev-0.12.1.2-2.479.el6_7.2.x86_64
qemu-kvm-rhev-tools-0.12.1.2-2.479.el6_7.2.x86_64
libvirt-0.10.2-54.el6_7.6.x86_64
libvirt-client-0.10.2-54.el6_7.6.x86_64
libvirt-lock-sanlock-0.10.2-54.el6_7.6.x86_64
libvirt-python-0.10.2-54.el6_7.6.x86_64
node04 (Centos 6.7)
vdsm-4.16.20-1.git3a90f62.el6.x86_64
vdsm-cli-4.16.20-1.git3a90f62.el6.noarch
vdsm-jsonrpc-4.16.20-1.git3a90f62.el6.noarch
vdsm-python-4.16.20-1.git3a90f62.el6.noarch
vdsm-python-zombiereaper-4.16.20-1.git3a90f62.el6.noarch
vdsm-xmlrpc-4.16.20-1.git3a90f62.el6.noarch
vdsm-yajsonrpc-4.16.20-1.git3a90f62.el6.noarch
gpxe-roms-qemu-0.9.7-6.15.el6.noarch
qemu-img-0.12.1.2-2.491.el6_8.1.x86_64
qemu-kvm-0.12.1.2-2.491.el6_8.1.x86_64
qemu-kvm-tools-0.12.1.2-2.503.el6_9.3.x86_64
libvirt-0.10.2-60.el6.x86_64
libvirt-client-0.10.2-60.el6.x86_64
libvirt-lock-sanlock-0.10.2-60.el6.x86_64
libvirt-python-0.10.2-60.el6.x86_64
I'm seeing a rather confusing error in the /var/log/messages on all 4 hosts
as follows....
Jul 31 16:41:36 node01 multipathd: 36001b4d80001c80d0000000000000000: sdb -
directio checker reports path is down
Jul 31 16:41:41 node01 kernel: sd 7:0:0:0: [sdb] Result:
hostbyte=DID_ERROR driverbyte=DRIVER_OK
Jul 31 16:41:41 node01 kernel: sd 7:0:0:0: [sdb] CDB: Read(10): 28 00 00 00
00 00 00 00 01 00
Jul 31 16:41:41 node01 kernel: end_request: I/O error, dev sdb, sector 0
I say confusing, because I don't have a 3000GB LUN
[root@node01 ~]# fdisk -l | grep 3000
Disk /dev/sdb: 3000.0 GB, 2999999528960 bytes
I did have one on Friday, last week, but I trashed it and changed it to a
1500GB LUN instead, so I'm not sure if perhaps this error is still trying
to connect to the old LUN perhaps?
My LUNS are as follows...
Disk /dev/sdb: 3000.0 GB, 2999999528960 bytes (this one doesn't actually
exist anymore)
Disk /dev/sdc: 1000.0 GB, 999999668224 bytes
Disk /dev/sdd: 1000.0 GB, 999999668224 bytes
Disk /dev/sde: 1000.0 GB, 999999668224 bytes
Disk /dev/sdf: 1000.0 GB, 999999668224 bytes
Disk /dev/sdg: 1000.0 GB, 999999668224 bytes
Disk /dev/sdh: 1000.0 GB, 999999668224 bytes
Disk /dev/sdi: 1000.0 GB, 999999668224 bytes
Disk /dev/sdj: 1000.0 GB, 999999668224 bytes
Disk /dev/sdk: 1000.0 GB, 999999668224 bytes
Disk /dev/sdm: 1000.0 GB, 999999668224 bytes
Disk /dev/sdl: 1000.0 GB, 999999668224 bytes
Disk /dev/sdn: 1000.0 GB, 999999668224 bytes
Disk /dev/sdo: 1000.0 GB, 999999668224 bytes
Disk /dev/sdp: 1000.0 GB, 999999668224 bytes
Disk /dev/sdq: 1000.0 GB, 999999668224 bytes
Disk /dev/sdr: 1000.0 GB, 999988133888 bytes
Disk /dev/sds: 1500.0 GB, 1499999764480 bytes
Disk /dev/sdt: 1500.0 GB, 1499999502336 bytes
I'm quite low on SAN disk space currently so I'm a little hesitant to
migrate VM's around for fear of the migrations creating too many snapshots
and filling up my SAN. We are in the process of expanding the SAN Array
too, but we trying to get to the bottom of the bad IOPS at the moment
before adding on addition overhead.
Ping tests between hosts and engine all look alright, so I don't suspect
network issues.
I know this is very vague, everything is currently operational, however as
you can see in the attached logs, I'm getting lots of ERROR messages.
Any help or guidance is greatly appreciated.
Thanks.
Regards.
Neil Wilson.
6 years, 8 months
