Hello,
I am in need of upgrading librbd1 and librados2 for a oVirt 4.2.x cluster.
The cluster was installed via node ng.
Taking the repository for Ceph Mimic or Luminous will end with a dependency
problem because liburcu-cds.so.1 is already installed as a more recent version.
A hint on how to
> No need for that; but you will required to redeploy them from the new
> engine to update their configuration.
so I keep the old engine running while deploying the new engine on a different
storage? Curious.
I don't understand what "redeploy them [the old engine hosts] from
the new engine to
I am wondering whether global maintenance inhibits fencing of non-responsive
hosts. Is this so?
Background: I plan on migrating the engine from one cluster to another. I
understand this means to backup/restore the engine. While migrating the engine
it is shut down and all VMs will continue
I am in the process of migrating the engine to a new cluster. I hope I will
accomplish it this weekend. Fingers crossed.
What you need to know:
The migration is really a backup and restore process.
1. You create a backup of the engine.
2. Place the cluster into global maintenance and shutdown
This one is probably saving my weekend. Thanks a lot for your great work.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
If you can: restart your setup from scratch with at least 3 hosts. Really. If
you don't face harsh consequences for doing so. It isn't just worth the hassle
and pain. Use at least 3 hosts because: A node can corrupt due to many reasons.
Natural causes, self inflicted ones. A corrupt node can
You're so right. Thanks.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
Yeah. But I think this ist just an artefact of the current version. All images
are in sync.
dom_md/ids is an obsolete file anyway as the docs say.
see vdsm/block-storage-domains
https://www.ovirt.org/develop/developer-guide/vdsm/block-storage-domains.html
> probably one of the problems that I
> haven't switched the cluster from iptables to firewalld. But this is just
> my guess.
>
When switching to from 4.2.8 to 4.3.3 I did not change one host from iptables
to firewalld as well. I was still able to change it later even if the
documentation
For converting my Debian boxes I do this. It is nothing fancy. Things you would
do with plain physical systems as well.
I have a VM for preparing VM images where I attach newly created disks,
rsyncing all data from old host to the new image.
Then I shut down the preparation VM, remove the new
Yeah. I digged that bug report up as well.
Our oVirt setup comprises of
6 oVirt hosts which form 2 datacenters
Datacenter: Luise (has a ceph storage domain)
node01 to node03 are a hyper converged oVirt glusterfs. This is cluster
Luise01. My original is to move the engine onto this cluster.
Short correction: All nodes oVirt and ceph are connected with 3 stacked Cisco
3750e providing 10 and 1Gbit ports.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement:
Deployment on NFS again failed with TASK [ovirt.hosted_engine_setup : Wait for
OVF_STORE disk content].
I'm lost.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement:
I re-checked the versions with
[root@node05 ~]# rpm -qa | grep engine
ovirt-ansible-engine-setup-1.1.9-1.el7.noarch
ovirt-engine-appliance-4.3-20190416.1.el7.x86_64
ovirt-hosted-engine-ha-2.3.1-1.el7.noarch
ovirt-hosted-engine-setup-2.3.7-1.el7.noarch
I updated all nodes to 4.3.3.1, but I did not remove the 4.2 repo from
/etc/yum.repos.d.
I did now remove the old repos, ovirt-engine-appliance is now shown as 4.3.
I tried deployment to the hyper converged cluster. First try failed again with
"The target Data Center does not contain the
I'm current on 4.3.3.1
The software versions I am using:
ovirt-hosted-engine-setup: 2.3.7
ovirt-ansible-hosted-engine-setup: 1.0.17
ovirt-engine-appliance: 4.2
I think I found the bug. :-/
___
Users mailing list -- users@ovirt.org
To unsubscribe send
Shouldn't this be done by restoring the engine? Initial engine host and storage
parameters are collected while doing the restore. It might be a bit far
stretched, but at least be an automated repeatable experience.
Are there really procedures where you manipulate the DHW directly? I never saw
I restored my engine to a gluster volume named :/engine on a three node
hyperconverged oVirt 4.3.3.1 cluster. Before restoring I was checking the
status of the volumes. They were clean. No heal entries. All peers connected.
gluster volume status looked good. Then I restored. This went well. The
Please note that I am running a hyper-converged NodeNG setup. I understand that
upgrading single components is not really possible with a ovirt Node NG. And
could probably break the datacenter upgrade path.
Could you point out some reference for your suggestions? Docs, Bug reports or
the
Yes. After a reboot you could have a sync issue for up to a few hours. But this
issue persists now for 24 days. Additionally I see errors in the glustershd.log
of the two hosts that are having heal info for that volume. The first node
shows as OK and has no errors in its glustershd.log.
The
> What version of gluster are you running at the moment?
I'm running glusterfs-5.5-1.el7.x86_64 the one that comes with oVirt Node
4.3.3.1
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy
There are plans for Node NG 4.3.5 to switch to Gluster V6.
So far I still have unsynced entries with gluster 5.5. I tried to reset every
brick, but that resolved to having the same heal info for that volume.
I'm currently re-installing a node that has heal info on the gluster volume.
Let's
Sorry. The thread became separated. Yeah. I finished the migration. Simone
proposed I had a corrupted backup. And yes. I was backtracking my backups to
that point where I switched all datacenters to 4.3 compatibility and before
doing any engine migration. Lucky me, I had that backup available.
No need to worry. I'm so much impressed with the quality of oVirt. It has so
many different setup scenarios, mine even a tech preview style one ;-)
And good idea to file a bug for usability. To wrap things up:
Me typing Luise1 instead of Luise01 was my error to begin with. It triggered
> Without this file [dom_md/ids], you will not have any
> kind of storage.
Ok. Sounds I'm kind of in trouble with that file being un-healable by gluster?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Thanks for the list of options. Will try it.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
I'm having a problem with restore. It fails while "Wait for OVF_STORE disk
content". Looking at the ansible output and at the bug report
https://bugzilla.redhat.com/show_bug.cgi?id=1644748 isn't the original value of
60 minutes for OvfUpdateIntervalInMinutes restored too early?
[ INFO ] TASK
Why did you move to gluster v6? For the kicks? :-) The devs are currently
evaluating for themselves whether they can switch to V6 for the upcoming
releases.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to
ovirt node NG is a very good choice. Install experience, upgrade experience is
very nice. 4.3 just got out of beta at Redhat. So the woes we experience is due
to be a early adopter.
ovirt node NG provides a stable selection of components and versions. ovirt
node NG is tested. Spinning up your
Maybe I overlooked the information, but in recent RHVE 4.3 docs the information
how to use the export storage domain have been removed and there is no
alternative to do so, but to detach a data domain and attach it somewhere else.
But how can I move my VMs one by one to a new storage domain on
AND HAVE BACKUPS OF THE ENGINE. But I suppose you already have automated
backups of the engine. Right?
After raising the datacenter compatibility to 4.3 the backups of 4.2 oVirt are
incompatible with 4.3!
___
Users mailing list -- users@ovirt.org
To
You can take a look at the RHEV 4.3 documentation.
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/upgrade_guide/index
There is another good read at:
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/index
You
You were right Simone. I used an older backup that I knew was just before I
started with migrating the engine. I was able to restore that backup. I have
now the engine on my gluster backed Cluster.
Thanks !
___
Users mailing list -- users@ovirt.org
To
Bareos (a fork of Bacula) is nice. And they promote
http://relax-and-recover.org/ a desaster recovery strategy.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement:
First I rebooted the hosted I tried to deploy to. The node status is now "OK"
again. I will try to deploy on that node again.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement:
Deployment looked good, but the race condition (which I faced 5 times out of
seven deployments) is back again.
[ INFO ] TASK [ovirt.hosted_engine_setup : Add HE disks]
[ INFO ] changed: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Register disk details]
[ INFO ] ok: [localhost]
[
I really feel like an idiot. I tried to move our hosted engine from our Default
datacenter to our Ceph Datacenter.
I ran intro problems which were correctly addressed.
see:
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/ZFCLFWRN6XR6KMHMC63O7J37D5GNPVKZ/
It was in case a race
The second deployment still triggers "The target Data Center does not contain
the Virtual Disk".
Trying again. This time deleting the old data in the gluster volume. Changing
number of engine CPUs from 4 to 2. Hope this gives the race condition some
different gravity.
Still no success. The ansible script errors out again at "The target Data
Center does not contain the Virtual Disk". trying a fourth time.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement:
Meanwhile I was able to remove the old wrecked engine with the
LocalHostedEngine on Port 6900. It was stable enough to re-install that node
with engine undeployment selected. So I'm now able to bring back the engine to
the old Default Datacenter and NFS.
on
> all nodes
> ovirt-ha-agent.service & ovirt-ha-broker.service . Once everywhere is
> stopped, start
> the 2 services on all nodes and wait 4-5min.
> Last verify the status from each host, before removing global maintenance.
>
> Best Regards,
> Strahil NikolovOn May
Yes! I can confirm that a second deployment succeeded on the second run. Great
:-)
I was also able to delete the Local Engine with virsh. I'd like to point out
for reference, that this is only possible if a sasldb user is created like this:
# saslpasswd2 -a libvirt username
Password:
Yeah. That did the trick. What I did was:
Enable global maintenance.
On every affected host:
# systemctl stop ovirt-ha-agent
# hosted-engine --clean-metadata --host-id=1 --force-clean (repeat for every id)
Finally start the stopped ha-agents.
Check the status:
# hosted-engine --vm-status
Disable
I have 5 nodes (node01 to node05). Originally all those nodes were part of our
default datacenter/cluster with a NFS storage domain for vmdisk, engine and
iso-images. All five nodes were engine HA nodes.
Later node01, node02 and node03 were re-installed to have engine HA removed.
Then those
Hello today I tried to migrate the hosted engine from our Default Datacenter
(NFS) to our Ceph Datacenter. The deployment worked with the automatic
"hosted-engine --deploy --restore-from-file=backup/file_name" command. Perfect.
Only thing is: I messed up with the cluster name. The name should
Hello,
when trying to deploy the engine using "hosted-engine --deploy
--restore-from-file=myenginebackup" the ansible playbook errors out at
[ INFO ] TASK [ovirt.hosted_engine_setup : Trigger hosted engine OVF update
and enable the serial console]
[ INFO ] changed: [localhost]
[ INFO ]
I'd like to add a question on storage domains.
When will storage domains become obsolete? Like kind of a road map.
I'm asking because we are operating a OpenStack Cinder V1 Domain to access Ceph
RBD images. I know this is only a former tech preview, but this preview is
doing solid work. So I'd
After rebooting the node that was not able to mount the gluster volume things
improved eventually. SPM went away and restarted for the Datacenter and
suddenly node03 was able to mount the gluster volume. In between I was down to
1/3 active Bricks which results in read only glusterfs. I was
Hi,
I am currently upgrading my oVirt setup from 4.2.8 to 4.3.3.1.
The setup consists of:
Datacenter/Cluster Default: [fully upgraded to 4.3.3.1]
2 nodes (node04,node05)- NFS storage domain with self hosted engine
Datacenter Luise:
Cluster1: 3 nodes (node01,node02,node03) - Node NG with
Restarting improved things a little bit. Still bricks on node03 are shown as
down, but "gluster volume status" is looking better.
Saiph:~ andreas$ ssh node01 gluster volume status vmstore
Status of volume: vmstore
Gluster process TCP Port RDMA Port Online Pid
"systemctl restart glusterd" on node03 did not help. Still getting:
node03#: ls -l
/rhev/data-center/mnt/glusterSD/node01.infra.solutions.work:_vmstore
ls: cannot access
/rhev/data-center/mnt/glusterSD/node01.infra.solutions.work:_vmstore: Transport
endpoint is not connected
Engine still
The file handle is stale so find will display:
"find: '/rhev/data-center/mnt/glusterSD/node01.infra.solutions.work:_vmstore':
Transport endpoint is not connected"
"stat /rhev/data-center/mnt/glusterSD/node01.infra.solutions.work:_vmstore"
will output
stat: cannot stat
Hallo Group !
I am in need of upgrading librbd1 and librados2 for a oVirt 4.2.x cluster.
The cluster was installed via node ng.
Taking the repository for Ceph Mimic or Luminous will end in a dependency
problem because liburcu-cds.so.1 is already installed as a more recent version
provided by
I found a way.
[root@node02 yum.repos.d]# cat luminious.repo
[ovirt-4.2-centos-ceph-luminous]
enabled=1
name = CentOS-7 - ceph luminous
baseurl = http://mirror.centos.org/centos/7/storage/$basearch/ceph-luminous/
gpgcheck = 1
enabled = 1
gpgkey =
Thanks for your answer.
> Yes, now you can do it via backup and restore:
> take a backup of the engine with engine-backup and restore it on a new
> hosted-engine VM on a new storage domain with:
> hosted-engine --deploy --restore-from-file=mybackup.tar.gz
That is great news. Just to clear things
Hi friends of oVirt,
Roughly 3 years ago a user asked about the options he had to move the hosted
engine to some other storage.
The answer by Simone Tiraboschi was that it would largely not be possible,
because of references in the database to the node the engine was hosted. This
information
56 matches
Mail list logo
