[ovirt-users] Upgrading librbd1 and librados2 for oVirt 4.2.x
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 get a more recent versions of the above libraries would be very much appreciated. Thanks, - Andreas ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZA74LCDEUKUIWFQVI6HNWYDVAQOPGUS4/
[ovirt-users] Re: 4.2 / 4.3 : Moving the hosted-engine to another storage
> 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 update their configuration" means. In fact the current engine incarnation is running on an old cluster, that has no access to the new storage (the cluster is to go away). The engine is also managing the new cluster to which we want to move the engine. The engine is the only piece that keeps us from shutting down the old cluster. That's the motivation for restoring the engine on the new cluster. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/WVOFX4ZXDF4PKR5JHW4BKR45ZQRC56CS/
[ovirt-users] Global maintenance and fencing of hosts
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 running. This is good. When starting the engine in the new location, I really don't want the engine to fence any host on its own, because of reasons I can not yet know. So is global maintenance enough to suppress fencing, or do I have to deactivate fencing on all hosts? ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/3KRJRAWBFC4QAXVYXUGXVA3324USBHBN/
[ovirt-users] Re: Migrate self-hosted engine between cluster
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 the engine. 3. Then you create a new engine on the other cluster and before engine-setup you restore the engine backup. 4. Start the new engine. From here I'm not yet sure what should happen in what order: - re-install the nodes with the old engine to remove the Engine HA Setup from that host. - re-install nodes on the new cluster to receive the Engine HA Setup. There is documentation about backup and restore of the engine here: https://ovirt.org/documentation/self-hosted/chap-Backing_up_and_Restoring_an_EL-Based_Self-Hosted_Environment.html ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/H4IDZJHKCLOVCDEN4ZRJI4KSPNPLWP5H/
[ovirt-users] Re: Migrate self-hosted engine between cluster
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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/2IJDVBDF5ZOUL2MJMXBSSBVF2ZBZKNIG/
[ovirt-users] Re: botched 3.6 -> 4.0/1/2 upgrade, how to recover
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 only recover through re-installation. This is triggered by the engine with VMs safe on the other nodes. On a single node system how can this be possible with only a corrupted node at hand? If you really can only stick to a one host setup you could try Proxmox. They have a community edition. For multi host setups choose oVirt. It is just great. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/NISRIS3ZGGBSSQTNOE4PF53HBROI7RQ5/
[ovirt-users] Re: deprecating export domain?
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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KIT4FV6ATTRGEEDTU75PDU556NRGX3TO/
[ovirt-users] Re: ovirt 4.3.3.7 cannot create a gluster storage domain
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 ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/MVQXFPVRJCHGL4YJ3KAJQLXXBTGJ6LNO/
[ovirt-users] Re: Can't bring upgraded to 4.3 host back to cluster
> 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 somewhere said iptables support is to be removed in 4.3. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/QMJGVX4LFSMGXKRN3ZS7UOAYMFBWC6XS/
[ovirt-users] Re: Does anyone have a positive experience with physical host to oVirt conversion?
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 disk from it. Create a new VM and attach the disk to that VM. I boot a rescue CD, fix /etc/fstab and networking, Re-Install grub to the disk. Done. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/4TKO7YKDOZEM67XTVAIZ24IK7LTCB5AH/
[ovirt-users] Re: Engine restore errors out on "Wait for OVF_STORE disk content"
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. Datacenter: Default Cluster Default node04 and node05. It uses an nfs storage: see below. The engine used to live here. Datacenter Luise Cluster: Luise02 node06 is currently the only node. This cluster will gain all nodes from the Default Datacenter as soon as it is decommissioned. All nodes are by Supermicro 4 cores 48GB Intel Xeon E5506 @ 2.13 GHz They use two bonded 1Gbit Links for connectivity. I was sceptical with performance, but we are running multiple around 10-20 TYPO3 CMSes plus lesser IO hungry things in around 3 to 6 VMs per Node. They all use Ceph as storage domain. All nodes I tried to deploy to are without virtual load. Storage: The glusterfs is provided by the hyper converged setup provided by oVirt Node NG. It is quite small because is just our gateway to boot the cinder VM that will guide our ceph nodes to their rbd destiny. Every Node has a 250GB SSD. This gives us 90GB for the :/engine gluster volume. There is also a 100GB volume for the supporting VMs that provide the bootstrap to cinder. There is little IO going to these volumes. The ceph is a 10Gbit connected cluster of 3 Nodes with SSD OSDs. The oVirt connect via a Cisco The NFS server is serving a Raid-10 btrfs formatted filesystem added with a bcache. My migration history so far: Tried to Migrate to Luise Datacenter I did a typo with entering Luise1 instead the correct cluster Luise01. Ironically that migration succeeded. Tried to Migrate back to Default. First one erred out with "Disk Image is not available in the cluster". Second one succeeded after following your advice to try it a second time. I removed the accidentally created Luise1 cluster. Tried to Migrate to Luise again. This time I forgot to completely shut down the hosted engine on Default Datacenter. I shut it down and tried again. All subsequent retires to deploy to the hyper converged Luise01 cluster failed. I used the Local Engine to re-install node05 which was hosting the engine I forget to shut down. I was not able to access the web interface for some reason, so I supposed it was damaged in a way. After 4 tries of deployment to our hyper converged cluster that all erred with the "Disk Image is not available" I'm not trying to go back to the Default Datacenter. Twice it erred out at "Wait for OVF_STORE disk content" ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/DCIZCN5F6J4DBQHNDM3U4O7HX5KTDVUH/
[ovirt-users] Re: Engine restore errors out on "Wait for OVF_STORE disk content"
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: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/JXEKEGGLYIIPVPGJGV6HQ476AVVWNZID/
[ovirt-users] Re: Engine restore errors out on "Wait for OVF_STORE disk content"
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: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/DFG5ECI2DADG7GVREBFAOLL7BQSNDGWK/
[ovirt-users] Re: Engine restore errors out on "Wait for OVF_STORE disk content"
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 ovirt-ansible-hosted-engine-setup-1.0.17-1.el7.noarch python-ovirt-engine-sdk4-4.3.1-2.el7.x86_64 so probably I was already on the latest versions. I did not do any updated. First I was doing a "rpm info" to get the version. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/WOXKWWN6QVF4D6HORBL3ZD7YZQ4XDCZD/
[ovirt-users] Re: Engine restore errors out on "Wait for OVF_STORE disk content"
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 Virtual Disk.". I'm retrying. Should this fail again, I will try a deployment to the old NFS backed Default Datacenter. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/J626ORT5IYZL3HCJRLGLV5N3D6Q2UWZF/
[ovirt-users] Re: Engine restore errors out on "Wait for OVF_STORE disk content"
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 an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/J4Y5HE77S33TCWPME4CGCT7OLG3MGDSC/
[ovirt-users] Re: HostedEngine migration from ovirt1:/engine to gluster1:/engine (new ip)
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 a reference in the documentation. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/5JYINPWJINWQPIN2LQO2ZTEUGHY3YKQ2/
[ovirt-users] Gluster volume heals and after 5 seconds has /dom_md/ids dirty again
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 engine is up. But the engine gluster volume shows entries on node02 and node03. The engine was installed to node01. I have to deploy the engine to the other two hosts to reach full HA, but I bet maintenance is not possible until the volume is healed. I tried "gluster volume heal engine" also with added "full". The heal entries will disappear for a few seconds and then /dom_md/ids will pop up again. The __DIRECT_IO_TEST__ will join later. The split-brain info has no entries. Is this some kind of hidden split brain? Maybe there is data on node01 brick which got not synced to the other two nodes? I can only speculate. Gluster docs say: this should heal. But it doesn't. I have two other volumes. Those are fine. One of them containing 3 VMs that are running. I also tried to shut down the engine, so no-one was using the volume. Then heal. Same effect. Those two files will always show up. But none other. Heal can always be started successfully from any of the participating nodes. Reset the volume bricks one by one and cross fingers? [root@node03 ~]# gluster volume heal engine info Brick node01.infra.solutions.work:/gluster_bricks/engine/engine Status: Connected Number of entries: 0 Brick node02.infra.solutions.work:/gluster_bricks/engine/engine /9f4d5ae9-e01d-4b73-8b6d-e349279e9782/dom_md/ids /__DIRECT_IO_TEST__ Status: Connected Number of entries: 2 Brick node03.infra.solutions.work:/gluster_bricks/engine/engine /9f4d5ae9-e01d-4b73-8b6d-e349279e9782/dom_md/ids /__DIRECT_IO_TEST__ Status: Connected Number of entries: 2 ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/L3YCRPRAGPUMBZIBFOPT6L4B7H4M6HLS/
[ovirt-users] Re: Gluster volume heals and after 5 seconds has /dom_md/ids dirty again
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 sorts? > I encountered serious issues with 5.3-5.5 (crashing bricks, multiple brick > processes for > the same brick causing disconnects and excessive heals). I had better luck > with 5.6, > although it’s not clear to me if the duplicate brick process issue is still > present in > that version. I finally jumped to 6 which has been more stable for me. I’d > recommend > upgrading at least to 5.6 if not going right to 6.1. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/BFOB6QEST6EAGEZGSCM4GO7BFRUYCKEI/
[ovirt-users] Re: Gluster volume heals and after 5 seconds has /dom_md/ids dirty again
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 errors are like this: [2019-05-13 15:18:40.808945] W [MSGID: 114031] [client-rpc-fops_v2.c:2634:client4_0_lookup_cbk] 0-engine-client-1: remote operation failed. Path: (95ba9fb2-b0ae-436c-9c31-2779cf202235) [No such file or directory] [2019-05-13 15:18:40.809113] W [MSGID: 114031] [client-rpc-fops_v2.c:2634:client4_0_lookup_cbk] 0-engine-client-2: remote operation failed. Path: (95ba9fb2-b0ae-436c-9c31-2779cf202235) [No such file or directory] [root@node02 ~]# Looks like the first node is sane and the other two are the masters but are not so sane. :-/ ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/4JROBW3YYGM65YNATOF7EHSMMA3H6NFL/
[ovirt-users] Re: Gluster volume heals and after 5 seconds has /dom_md/ids dirty again
> 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 Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/OPMOUE5FQRYF4Q6ZMPBDFM6EYAXRNM44/
[ovirt-users] Re: Gluster volume heals and after 5 seconds has /dom_md/ids dirty again
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 see what happens after that. See: https://lists.ovirt.org/archives/list/de...@ovirt.org/thread/IVTYCFKCQ5P2WZ43CM245PTX5T54PLQX/ ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/VUBOALBOM2HWS5ZA2G3MP52E4FKRPBYQ/
[ovirt-users] Re: Engine restore errors out on "Wait for OVF_STORE disk content"
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. I think my backups became corrupted, because I did a backup from the engine after I moved it to a cluster that was originally not defined. I had a typo in the cluster name. And used that backup and tried to get the engine back to my nfs storage. That worked. I did another backup at that place again and from that point on the backup would always break the deployment for whatever reason. The logs are available at https://lists.ovirt.org/archives/list/users@ovirt.org/thread/HXJZWN7L6WXSDLQB3SMIAUEJGI6QFBGC/ ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TNHQO4VPZES7NXUR5KI3LACBQ4NK2FM4/
[ovirt-users] Re: Engine restore errors out on "Wait for OVF_STORE disk content"
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 everything. Luise01 is our hyper converged oVirt node cluster. It is our ceph bootstrap. Yeah... How could you forget the zero.. node01, node02 and node03 are forming Luise01. I ordered deployment of the engine to node01 on Luise1 and hosted-engine happily did so. Creating a new cluster Luise1 on node01 masking the glusterfs bricks on node01 for the remaining Luise01 cluster nodes. This most probably also triggered this issue: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/L3YCRPRAGPUMBZIBFOPT6L4B7H4M6HLS/ It has already been addressed by Nir Soffer. See https://lists.ovirt.org/archives/list/users@ovirt.org/message/OSZGHT65OUUSGKTLYKJVZPVRFTBPI3EO/ I will create a bug report for that. A node that has already joined a cluster should not be a viable destination for an engine deployment to a new to create cluster. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YIDVCKVYKRGQUDK4R22Z6GNWRHHZWNMF/
[ovirt-users] Re: ovirt 4.3.3.7 cannot create a gluster storage domain
> 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 Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FIR74ALG7WJFIPNIAHZH4PRBY7UI2QRO/
[ovirt-users] Re: deprecating export domain?
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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KFHXK5QYWZRN3G2MNLTSKWN4EK42LVQH/
[ovirt-users] OvfUpdateIntervalInMinutes restored to original value too early?
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 [ovirt.hosted_engine_setup : Fetch host SPM_ID]
[ INFO ] changed: [localhost -> engine.infra.solutions.work]
[ INFO ] TASK [ovirt.hosted_engine_setup : Parse host SPM_ID]
[ INFO ] ok: [localhost -> engine.infra.solutions.work]
[ INFO ] TASK [ovirt.hosted_engine_setup : Restore original
DisableFenceAtStartupInSec]
[ INFO ] changed: [localhost -> engine.infra.solutions.work]
[ INFO ] TASK [ovirt.hosted_engine_setup : Remove DisableFenceAtStartupInSec
temporary file]
[ INFO ] changed: [localhost -> engine.infra.solutions.work]
[ INFO ] TASK [ovirt.hosted_engine_setup : Restore original
OvfUpdateIntervalInMinutes]
[ INFO ] changed: [localhost -> engine.infra.solutions.work]
[ INFO ] TASK [ovirt.hosted_engine_setup : Remove OvfUpdateIntervalInMinutes
temporary file]
[ INFO ] changed: [localhost -> engine.infra.solutions.work]
[ INFO ] TASK [ovirt.hosted_engine_setup : Removing temporary value]
[ INFO ] changed: [localhost -> engine.infra.solutions.work]
[ INFO ] TASK [ovirt.hosted_engine_setup : Restoring original value]
[ INFO ] changed: [localhost -> engine.infra.solutions.work]
[ INFO ] TASK [ovirt.hosted_engine_setup : Remove temporary directory for
ansible as postgres user]
[ INFO ] changed: [localhost -> engine.infra.solutions.work]
[ INFO ] TASK [ovirt.hosted_engine_setup : Fail if he_force_ip4 and
he_force_ip6 are set at the same time]
[ INFO ] skipping: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Prepare getent key]
[ INFO ] skipping: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Trigger hosted engine OVF update
and enable the serial console]
[ INFO ] changed: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Wait until OVF update finishes]
[ INFO ] ok: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Parse OVF_STORE disk list]
[ INFO ] ok: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Check OVF_STORE volume status]
[ INFO ] changed: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Wait for OVF_STORE disk content]
[ ERROR ] {u'_ansible_parsed': True, u'stderr_lines': [u'20+0 records in',
u'20+0 records out', u'10240 bytes (10 kB) copied, 0.000164261 s, 62.3 MB/s',
u'tar: 1e74609b-51e1-45c8-9106-2596ee59ba3a.ovf: Not found in archive', u'tar:
Exiting with failure status due to previous errors'], u'changed': True, u'end':
u'2019-05-10 12:57:57.610068', u'_ansible_item_label': {u'image_id':
u'59d16f28-64ed-4c3f-aaad-7d98e2718f53', u'name': u'OVF_STORE', u'id':
u'98bd5cfc-809d-4d40-83e0-98e379af5f97'}, u'stdout': u'', u'failed': True,
u'_ansible_item_result': True, u'msg': u'non-zero return code', u'rc': 2,
u'start': u'2019-05-10 12:57:56.928294', u'attempts': 12, u'cmd': u"vdsm-client
Image prepare storagepoolID=597f329c-0296-03af-0369-0139
storagedomainID=8f115ea6-91ec-4e10-9240-bc8eda47b7ff
imageID=98bd5cfc-809d-4d40-83e0-98e379af5f97
volumeID=59d16f28-64ed-4c3f-aaad-7d98e2718f53 | grep path | awk '{ print $2 }'
| xargs -I{} sudo -u vdsm dd if={} | tar -tvf - 1e74609b-51e1-45c8-9106-259
6ee59ba3a.ovf", u'item': {u'image_id':
u'59d16f28-64ed-4c3f-aaad-7d98e2718f53', u'name': u'OVF_STORE', u'id':
u'98bd5cfc-809d-4d40-83e0-98e379af5f97'}, u'delta': u'0:00:00.681774',
u'invocation': {u'module_args': {u'warn': False, u'executable': None,
u'_uses_shell': True, u'_raw_params': u"vdsm-client Image prepare
storagepoolID=597f329c-0296-03af-0369-0139
storagedomainID=8f115ea6-91ec-4e10-9240-bc8eda47b7ff
imageID=98bd5cfc-809d-4d40-83e0-98e379af5f97
volumeID=59d16f28-64ed-4c3f-aaad-7d98e2718f53 | grep path | awk '{ print $2 }'
| xargs -I{} sudo -u vdsm dd if={} | tar -tvf -
1e74609b-51e1-45c8-9106-2596ee59ba3a.ovf", u'removes': None, u'argv': None,
u'creates': None, u'chdir': None, u'stdin': None}}, u'stdout_lines': [],
u'stderr': u'20+0 records in\n20+0 records out\n10240 bytes (10 kB) copied,
0.000164261 s, 62.3 MB/s\ntar: 1e74609b-51e1-45c8-9106-2596ee59ba3a.ovf: Not
found in archive\ntar: Exiting with failure status due to previous errors',
u'_ansible_no_log': False}
___
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:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HJ272VCIHH5NIVDHJWP4HRQLV7BYQJHI/
[ovirt-users] Re: ovirt 4.3.3.7 cannot create a gluster storage domain
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 users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/JYZRKA4QBTXYDR3WXFRW7IXLCSGGVSLC/
[ovirt-users] Re: Gluster volume heals and after 5 seconds has /dom_md/ids dirty again
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 own oVirt mix seems more error prone to me. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/DQWUV6EMBELX65YKK2CDJULNBPKFHH6N/
[ovirt-users] Re: deprecating export domain?
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 a different datacenter without completely detaching the original storage domain? I don't want to bring down all of my VMs on the old storage domain for import. I want to export and import them one by one. When all VMs are moved to the new data center only then I want to decommission the old data center. What is the rationale to deprecate the export storage and already remove documentation when there seems to be no alternative available? ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/O4HXTTYAFOC53XQR432ZFMN3JL6IJBIC/
[ovirt-users] Re: oVirt upgrade version from 4.2 to 4.3
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 unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/4OK5TM7E2KNGQONN746WA57ID66IDKKY/
[ovirt-users] Re: oVirt upgrade version from 4.2 to 4.3
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 should probably wait for 4.3.4 to arrive, since 4.3.3 is still a little bit rough on the edges. I can currently only create a new VM via the templates, because the normal creation dialog errors, when I change the datacenter. Otherwise the upgrade went very well. If you are running off of oVirt Node NG it is very straightforward. I did: 1. Check of all nodes are using firewalld. You have to switch all nodes to use firewalld, because Iptables is deprecated and removed in 4.3 as it was said in documentation. You have to re-install every node for that. So every node has to go through maintenance. 2. Upgrade the engine. First to the 4.2.8 then to 4.3.x My upgrade flow for this is: Engine Update START Minor Upgrades first enable global maintenance mode login to engine engine-upgrade-check yum update "ovirt-*-setup*" engine-setup yum update when success: disable global maintenance mode Major Upgrade enable global maintenance mode login to engine yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release[releasenumber].rpm engine-upgrade-check yum update "ovirt-*-setup*" engine-setup remove the old ovirt release from /etc/yum.repos.d yum update when success: disable global maintenance mode Engine Upgrade END 3. Upgrade the nodes. First to 4.2.8 then as specified in ovirt release info: yum install https://resources.ovirt.org/pub/ovirt-4.3/rpm/el7/noarch/ovirt-node-ng-image-update-4.3.3-1.el7.noarch.rpm 4. Upgrade the Datacenter Compatibility to 4.3 This includes rebooting all VMs at one point. You can read about it in the documentation. Then you're done. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/SBTRBHU6WMA3BGHAVX3BZKQF3PAQBC5H/
[ovirt-users] Re: OvfUpdateIntervalInMinutes restored to original value too early?
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 unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/BNF7YZJLNBFDIKXEOZ4AXUNWJ5EEOUOG/
[ovirt-users] Re: Every now and then Backup question
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: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ODNXJDWIZBNCL445SUTMKENDQWUZCCX3/
[ovirt-users] Re: Hosted engine restore went very wrong
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: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7QPI7HXV3G3K2XYUM7ZS3JNDC2Y5PCXM/
[ovirt-users] Re: Hosted engine restore went very wrong
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]
[ INFO ] TASK [ovirt.hosted_engine_setup : Set default graphics protocols]
[ INFO ] ok: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Check if FIPS is enabled]
[ INFO ] changed: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Select graphic protocols]
[ INFO ] skipping: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Add VM]
[ ERROR ] Error: Fault reason is "Operation Failed". Fault detail is "[Cannot
attach Virtual Disk. The target Data Center does not contain the Virtual
Disk.]". HTTP response code is 409.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault
reason is \"Operation Failed\". Fault detail is \"[Cannot attach Virtual Disk.
The target Data Center does not contain the Virtual Disk.]\". HTTP response
code is 409."}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing
ansible-playbook
[ INFO ] Stage: Clean up
[ INFO ] Cleaning temporary resources
[ INFO ] TASK [ovirt.hosted_engine_setup : Execute just a specific set of
steps]
[ INFO ] ok: [localhost]
Will try again, but yesterday I got this error two times in a row.
___
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:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5OTPHSX2B5NAPC7M6JLUMNXVQWYBOLUB/
[ovirt-users] Hosted engine restore went very wrong
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 condition. I was able to bring back the engine to our
Default Cluster. And then I tried to
do the move again to our Ceph Datacenter.
I got the error "The target Data Center does not contain the Virtual Disk"
twice yesterday. Because it was late,
I decided to do it in the next morning.
I did a new backup from the engine. Copied it over to the new node of the Ceph
Datacenter and started the
hosted-engine --deploy. But I FORGET TO SHUTDOWN the other engine! Oh man.
The deploy script errored out with:
[ ERROR ] fatal: [localhost]: FAILED! => {"censored": "the output has been
hidden due to the fact that 'no_log: true' was specified for this result",
"changed": false}
[ ERROR ] fatal: [localhost -> engine.infra.solutions.work]: FAILED! =>
{"changed": false, "msg": "There was a failure deploying the engine on the
local engine VM. The system may not be provisioned accord
Then I realised something was different this time.
I shutdown and undefined the Local Engine. The node is now in a degraded state.
Is it possible to start the deployment again on a degraded node?
I started the old engine again, but I'm not able to reach the login page.
Any Idea what to do next?
___
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:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3DMBPWWXL7XWNXO7REZTJJPUE54WBMJJ/
[ovirt-users] Re: Hosted engine restore went very wrong
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. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/PPE6QW3XZ3DNIOBCMTFODS3T4RNPOVZH/
[ovirt-users] Re: Hosted engine restore went very wrong
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: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/2IIJMBLONEIWASKYNCRZPVSJRIHTVJN5/
[ovirt-users] Re: Hosted engine restore went very wrong
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. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/QXNFLO7J57KIARQ2FHXYHGOCZOP5FJFG/
[ovirt-users] Re: Stale hosted engine node information harmful ?
I did that. There is no change. Node01,02 and 03 are still present in "hosted-engine --vm-status". > In a Red Hat Solution , it is recommended to restart ovirt-ha-agent & > ovirt-ha-broker. > > I usually set the global maintenance and wait 20s-30s . Then I just stop 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 2, 2019 12:30, Andreas Elvers > https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/675IE4RGUAROUDCYMLW4EVI5B2M6VC2M/
[ovirt-users] Re: Problem with restoring engine
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: After that it was possible to do this with the created credentials # virsh destroy HostedEngineLocal # virsh undefine HostedEngineLocal Glancing at the ansible output of the deployment process, the playbook seems to take care of old local engines anyway. Thanks again for your help Simone. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZRAODEEX5IZ7PQLDH7QNYONQJTYM6ATI/
[ovirt-users] Re: Stale hosted engine node information harmful ?
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 global maintenance.. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZDPNWLP5CYZWGFJSH3WNFBJEVIUPQSPC/
[ovirt-users] Stale hosted engine node information harmful ?
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 nodes were removed from the default cluster. Eventually node01,02
and 03 were completely re-installed to host our new Ceph/Gluster based
datecenter. The engine is still running on the old default Datacenter. Now I
wish to move it over to our ceph/gluster datacenter.
when I look at the current output of "hosted-engine --vm-status" I see:
--== Host node01.infra.solutions.work (id: 1) status ==--
conf_on_shared_storage : True
Status up-to-date : False
Hostname : node01.infra.solutions.work
Host ID: 1
Engine status : unknown stale-data
Score : 0
stopped: True
Local maintenance : False
crc32 : e437bff4
local_conf_timestamp : 155627
Host timestamp : 155877
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=155877 (Fri Aug 3 13:09:19 2018)
host-id=1
score=0
vm_conf_refresh_time=155627 (Fri Aug 3 13:05:08 2018)
conf_on_shared_storage=True
maintenance=False
state=AgentStopped
stopped=True
--== Host node02.infra.solutions.work (id: 2) status ==--
conf_on_shared_storage : True
Status up-to-date : False
Hostname : node02.infra.solutions.work
Host ID: 2
Engine status : unknown stale-data
Score : 0
stopped: True
Local maintenance : False
crc32 : 11185b04
local_conf_timestamp : 154757
Host timestamp : 154856
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=154856 (Fri Aug 3 13:22:19 2018)
host-id=2
score=0
vm_conf_refresh_time=154757 (Fri Aug 3 13:20:40 2018)
conf_on_shared_storage=True
maintenance=False
state=AgentStopped
stopped=True
--== Host node03.infra.solutions.work (id: 3) status ==--
conf_on_shared_storage : True
Status up-to-date : False
Hostname : node03.infra.solutions.work
Host ID: 3
Engine status : unknown stale-data
Score : 0
stopped: False
Local maintenance : True
crc32 : 9595bed9
local_conf_timestamp : 14363
Host timestamp : 14362
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=14362 (Thu Aug 2 18:03:25 2018)
host-id=3
score=0
vm_conf_refresh_time=14363 (Thu Aug 2 18:03:25 2018)
conf_on_shared_storage=True
maintenance=True
state=LocalMaintenance
stopped=False
--== Host node04.infra.solutions.work (id: 4) status ==--
conf_on_shared_storage : True
Status up-to-date : True
Hostname : node04.infra.solutions.work
Host ID: 4
Engine status : {"health": "good", "vm": "up", "detail":
"Up"}
Score : 3400
stopped: False
Local maintenance : False
crc32 : 245854b1
local_conf_timestamp : 317498
Host timestamp : 317498
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=317498 (Thu May 2 09:44:47 2019)
host-id=4
score=3400
vm_conf_refresh_time=317498 (Thu May 2 09:44:47 2019)
conf_on_shared_storage=True
maintenance=False
state=EngineUp
stopped=False
--== Host node05.infra.solutions.work (id: 5) status ==--
conf_on_shared_storage : True
Status up-to-date : True
Hostname : node05.infra.solutions.work
Host ID: 5
Engine status : {"reason": "vm not running on this host",
"health": "bad", "vm": "down", "detail": "unknown"}
Score : 3400
stopped: False
Local maintenance : False
crc32 : 0711afa0
local_conf_timestamp : 318044
Host timestamp
[ovirt-users] Problem with restoring engine
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 be Luise01
but I entered Luise1. Duh...
Now I want to bring the engine back to the Default Datacenter. Easy thing. Just
repeat the same steps again.
1. Enable global ha maintenenace
2. Stop and disable the engine
3. create the engine backup
4 ... continue with all the steps from chapter 13.1.8 RHEV Docs 4.3 Beta.
Everything looked great. The ansible playbook was running, then asking for the
storage domain. I entered the NFS path. It got registered, but then the ansible
playbook errors out with
[ INFO ] TASK [ovirt.hosted_engine_setup : Add VM]
[ ERROR ] Error: Fault reason is "Operation Failed". Fault detail is "[Cannot
attach Virtual Disk. The target Data Center does not contain the Virtual
Disk.]". HTTP response code is 409.
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault
reason is \"Operation Failed\". Fault detail is \"[Cannot attach Virtual Disk.
The target Data Center does not contain the Virtual Disk.]\". HTTP response
code is 409."}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing
ansible-playbook
[ INFO ] Stage: Clean up
[ INFO ] Cleaning temporary resources
I see that there is a bug report on
https://bugzilla.redhat.com/show_bug.cgi?id=1649424
Any idea how to get around this error ?
Additionally I now have a HostedEngineLocal (shut off) on that node... How do I
remove it?
engine-cleanup ?
Have to get some sleep.
best regards.
___
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:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZFCLFWRN6XR6KMHMC63O7J37D5GNPVKZ/
[ovirt-users] Engine restore errors out on "Wait for OVF_STORE disk content"
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 ] TASK [ovirt.hosted_engine_setup : Wait until OVF update finishes]
[ INFO ] ok: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Parse OVF_STORE disk list]
[ INFO ] ok: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Check OVF_STORE volume status]
[ INFO ] changed: [localhost]
[ INFO ] TASK [ovirt.hosted_engine_setup : Wait for OVF_STORE disk content]
[ ERROR ] {u'_ansible_parsed': True, u'stderr_lines': [u'20+0 records in',
u'20+0 records out', u'10240 bytes (10 kB) copied, 0.000141645 s, 72.3 MB/s',
u'tar: ebb09b0e-2d03-40f0-8fa4-c40b18612a54.ovf: Not found in archive', u'tar:
Exiting with failure status due to previous errors'], u'changed': True, u'end':
u'2019-05-08 15:21:47.595195', u'_ansible_item_label': {u'image_id':
u'65fd6c57-033c-4c95-87c1-b16c26e4bc98', u'name': u'OVF_STORE', u'id':
u'9ff8b389-5e24-4166-9842-f1d6104b662b'}, u'stdout': u'', u'failed': True,
u'_ansible_item_result': True, u'msg': u'non-zero return code', u'rc': 2,
u'start': u'2019-05-08 15:21:46.906877', u'attempts': 12, u'cmd': u"vdsm-client
Image prepare storagepoolID=597f329c-0296-03af-0369-0139
storagedomainID=f708ced4-e339-4d02-a07f-78f1a30fc2a8
imageID=9ff8b389-5e24-4166-9842-f1d6104b662b
volumeID=65fd6c57-033c-4c95-87c1-b16c26e4bc98 | grep path | awk '{ print $2 }'
| xargs -I{} sudo -u vdsm dd if={} | tar -tvf - ebb09b0e-2d03-40f0-8fa4-c40
b18612a54.ovf", u'item': {u'image_id':
u'65fd6c57-033c-4c95-87c1-b16c26e4bc98', u'name': u'OVF_STORE', u'id':
u'9ff8b389-5e24-4166-9842-f1d6104b662b'}, u'delta': u'0:00:00.688318',
u'invocation': {u'module_args': {u'warn': False, u'executable': None,
u'_uses_shell': True, u'_raw_params': u"vdsm-client Image prepare
storagepoolID=597f329c-0296-03af-0369-0139
storagedomainID=f708ced4-e339-4d02-a07f-78f1a30fc2a8
imageID=9ff8b389-5e24-4166-9842-f1d6104b662b
volumeID=65fd6c57-033c-4c95-87c1-b16c26e4bc98 | grep path | awk '{ print $2 }'
| xargs -I{} sudo -u vdsm dd if={} | tar -tvf -
ebb09b0e-2d03-40f0-8fa4-c40b18612a54.ovf", u'removes': None, u'argv': None,
u'creates': None, u'chdir': None, u'stdin': None}}, u'stdout_lines': [],
u'stderr': u'20+0 records in\n20+0 records out\n10240 bytes (10 kB) copied,
0.000141645 s, 72.3 MB/s\ntar: ebb09b0e-2d03-40f0-8fa4-c40b18612a54.ovf: Not
found in archive\ntar: Exiting with failure status due to previous errors',
u'_ansible_no_log': False}
[ ERROR ] {u'_ansible_parsed': True, u'stderr_lines': [u'20+0 records in',
u'20+0 records out', u'10240 bytes (10 kB) copied, 0.000140541 s, 72.9 MB/s',
u'tar: ebb09b0e-2d03-40f0-8fa4-c40b18612a54.ovf: Not found in archive', u'tar:
Exiting with failure status due to previous errors'], u'changed': True, u'end':
u'2019-05-08 15:24:01.387469', u'_ansible_item_label': {u'image_id':
u'dacf9ad8-77b9-4205-8ca2-d6877627ad4a', u'name': u'OVF_STORE', u'id':
u'8691076a-8e45-4429-a18a-5faebef866cc'}, u'stdout': u'', u'failed': True,
u'_ansible_item_result': True, u'msg': u'non-zero return code', u'rc': 2,
u'start': u'2019-05-08 15:24:00.660309', u'attempts': 12, u'cmd': u"vdsm-client
Image prepare storagepoolID=597f329c-0296-03af-0369-0139
storagedomainID=f708ced4-e339-4d02-a07f-78f1a30fc2a8
imageID=8691076a-8e45-4429-a18a-5faebef866cc
volumeID=dacf9ad8-77b9-4205-8ca2-d6877627ad4a | grep path | awk '{ print $2 }'
| xargs -I{} sudo -u vdsm dd if={} | tar -tvf - ebb09b0e-2d03-40f0-8fa4-c40
b18612a54.ovf", u'item': {u'image_id':
u'dacf9ad8-77b9-4205-8ca2-d6877627ad4a', u'name': u'OVF_STORE', u'id':
u'8691076a-8e45-4429-a18a-5faebef866cc'}, u'delta': u'0:00:00.727160',
u'invocation': {u'module_args': {u'warn': False, u'executable': None,
u'_uses_shell': True, u'_raw_params': u"vdsm-client Image prepare
storagepoolID=597f329c-0296-03af-0369-0139
storagedomainID=f708ced4-e339-4d02-a07f-78f1a30fc2a8
imageID=8691076a-8e45-4429-a18a-5faebef866cc
volumeID=dacf9ad8-77b9-4205-8ca2-d6877627ad4a | grep path | awk '{ print $2 }'
| xargs -I{} sudo -u vdsm dd if={} | tar -tvf -
ebb09b0e-2d03-40f0-8fa4-c40b18612a54.ovf", u'removes': None, u'argv': None,
u'creates': None, u'chdir': None, u'stdin': None}}, u'stdout_lines': [],
u'stderr': u'20+0 records in\n20+0 records out\n10240 bytes (10 kB) copied,
0.000140541 s, 72.9 MB/s\ntar: ebb09b0e-2d03-40f0-8fa4-c40b18612a54.ovf: Not
found in archive\ntar: Exiting with failure status due to previous errors',
u'_ansible_no_log': False}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing
ansible-playbook
I tried twice. Same result. Should I retry?
Is it safe to use the local hosted engine for starting stopping vms? I'm kind
of headless for some days :-)
Best regards.
[ovirt-users] Re: Storage domain format version 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 like to know, when this will go away. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/OQ3CODAESWZNABAEZADFG2XSVZZV66VF/
[ovirt-users] Re: Upgrading from 4.2.8 to 4.3.3 broke Node NG GlusterFS
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 lucky to have the Engine still on NFS. But anyway... Thanks for your thoughts. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/5NKHRCJWEZGXSBKRMR447RCX6GWAAZV6/
[ovirt-users] Upgrading from 4.2.8 to 4.3.3 broke Node NG GlusterFS
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 GlusterFS - Ceph Cinder storage domain [Node1 and Node3 are upgraded to 4.3.3.1, Node2 is on 4.2.8] Cluster2: 1 node (node06) - only Ceph Cinder storage domain [fully upgraded to 4.3.3.1] Problems started when upgrading Luise/Cluster1 with GlusterFS: (I always waited for GlusterFS to be fully synced before proceeding to the next step) - Upgrade node01 to 4.3.3 -> OK - Upgrade node03 to 4.3.3.1 -> OK - Upgrade node01 to 4.3.3.1 -> GlusterFS became unstable. I now get the error message: VDSM node03.infra.solutions.work command ConnectStoragePoolVDS failed: Cannot find master domain: u'spUUID=f3218bf7-6158-4b2b-b272-51cdc3280376, msdUUID=02a32017-cbe6-4407-b825-4e558b784157' And on node03 there is a problem with Gluster: 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 The directory is available on node01 and node02. The engine is reporting the brick on node03 as down. Node03 and Node06 are shown as NonOperational, because they are not able to access the gluster storage domain. A “gluster peer status” on node1, node2, and node3 shows all peers connected. “gluster volume heal vmstore info” shows for all nodes: gluster volume heal vmstore info Brick node01.infra.solutions.work:/gluster_bricks/vmstore/vmstore Status: Transport endpoint is not connected Number of entries: - Brick node02.infra.solutions.work:/gluster_bricks/vmstore/vmstore /02a32017-cbe6-4407-b825-4e558b784157/dom_md/ids /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.66 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.60 /02a32017-cbe6-4407-b825-4e558b784157/images/a3a10398-9698-4b73-84d9-9735448e3534/6161e310-4ad6-42d9-8117-5a89c5b2b4b6 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.96 /.shard/d66880de-3fa1-4362-8c43-574a173c5f7d.133 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.38 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.67 /__DIRECT_IO_TEST__ /02a32017-cbe6-4407-b825-4e558b784157/images/493188b2-c137-4440-99ee-43a753842a7d/9aa2d139-e3bd-406b-8fe0-b189123eaa73 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.64 /.shard/d66880de-3fa1-4362-8c43-574a173c5f7d.132 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.44 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.9 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.69 /02a32017-cbe6-4407-b825-4e558b784157/images/12e647fb-20aa-4957-b659-05fa75a9215e/f7e4b2a3-ab84-4eb5-a4e7-7208ddad8156 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.35 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.32 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.39 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.34 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.68 Status: Connected Number of entries: 47 Brick node03.infra.solutions.work:/gluster_bricks/vmstore/vmstore /02a32017-cbe6-4407-b825-4e558b784157/images/12e647fb-20aa-4957-b659-05fa75a9215e/f7e4b2a3-ab84-4eb5-a4e7-7208ddad8156 /.shard/d66880de-3fa1-4362-8c43-574a173c5f7d.133 /02a32017-cbe6-4407-b825-4e558b784157/images/493188b2-c137-4440-99ee-43a753842a7d/9aa2d139-e3bd-406b-8fe0-b189123eaa73 /.shard/40948f85-2212-47f9-bd5e-102a8dd632b8.44 /02a32017-cbe6-4407-b825-4e558b784157/dom_md/ids /02a32017-cbe6-4407-b825-4e558b784157/images/a3a10398-9698-4b73-84d9-9735448e3534/6161e310-4ad6-42d9-8117-5a89c5b2b4b6 /.shard/d66880de-3fa1-4362-8c43-574a173c5f7d.132 /__DIRECT_IO_TEST__ Status: Connected Number of entries: 47 On Node03 there are several self healing processes, that seem to be doing nothing. Oh well.. What now? Best regards, - Andreas ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/R5GS6AQXTEQRMUQNMEBDC72YG3A5JFF6/
[ovirt-users] Re: Upgrading from 4.2.8 to 4.3.3 broke Node NG GlusterFS
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 -- Brick node01.infra.solutions.work:/gluster_ bricks/vmstore/vmstore 49157 0 Y 24543 Brick node02.infra.solutions.work:/gluster_ bricks/vmstore/vmstore 49154 0 Y 23795 Brick node03.infra.solutions.work:/gluster_ bricks/vmstore/vmstore 49157 0 Y 1617 Self-heal Daemon on localhost N/A N/AY 32121 Self-heal Daemon on node03.infra.solutions. workN/A N/AY 25798 Self-heal Daemon on node02.infra.solutions. workN/A N/AY 30879 Task Status of Volume vmstore -- There are no active volume tasks Saiph:~ andreas$ ssh node02 gluster volume status vmstore Status of volume: vmstore Gluster process TCP Port RDMA Port Online Pid -- Brick node01.infra.solutions.work:/gluster_ bricks/vmstore/vmstore 49157 0 Y 24543 Brick node02.infra.solutions.work:/gluster_ bricks/vmstore/vmstore 49154 0 Y 23795 Brick node03.infra.solutions.work:/gluster_ bricks/vmstore/vmstore 49157 0 Y 1617 Self-heal Daemon on localhost N/A N/AY 30879 Self-heal Daemon on node03.infra.solutions. workN/A N/AY 25798 Self-heal Daemon on node01.infra.solutions. workN/A N/AY 32121 Task Status of Volume vmstore -- There are no active volume tasks Saiph:~ andreas$ ssh node03 gluster volume status vmstore Status of volume: vmstore Gluster process TCP Port RDMA Port Online Pid -- Brick node01.infra.solutions.work:/gluster_ bricks/vmstore/vmstore 49157 0 Y 24543 Brick node02.infra.solutions.work:/gluster_ bricks/vmstore/vmstore 49154 0 Y 23795 Brick node03.infra.solutions.work:/gluster_ bricks/vmstore/vmstore 49157 0 Y 1617 Self-heal Daemon on localhost N/A N/AY 25798 Self-heal Daemon on node01.infra.solutions. workN/A N/AY 32121 Self-heal Daemon on node02.infra.solutions. workN/A N/AY 30879 Task Status of Volume vmstore -- There are no active volume tasks ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/AAGJ42GF267NOFEQXNJRUQJD7C5UCOM5/
[ovirt-users] Re: Upgrading from 4.2.8 to 4.3.3 broke Node NG GlusterFS
"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 shows bricks on node03 as down. ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/2JMM4UBZ54TNHCFUFYDX2OOVCKEMXFBX/
[ovirt-users] Re: Upgrading from 4.2.8 to 4.3.3 broke Node NG GlusterFS
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 '/rhev/data-center/mnt/glusterSD/node01.infra.solutions.work:_vmstore': Transport endpoint is not connected All Nodes are peering with the other nodes: - Saiph:~ andreas$ ssh node01 gluster peer status Number of Peers: 2 Hostname: node02.infra.solutions.work Uuid: 87fab40a-2395-41ce-857d-0b846e078cdb State: Peer in Cluster (Connected) Hostname: node03.infra.solutions.work Uuid: 49025f81-e7c1-4760-be03-f36e0f403d26 State: Peer in Cluster (Connected) Saiph:~ andreas$ ssh node02 gluster peer status Number of Peers: 2 Hostname: node03.infra.solutions.work Uuid: 49025f81-e7c1-4760-be03-f36e0f403d26 State: Peer in Cluster (Disconnected) Hostname: node01.infra.solutions.work Uuid: f25e6bff-e5e2-465f-a33e-9148bef94633 State: Peer in Cluster (Connected) ssh node03 gluster peer status Number of Peers: 2 Hostname: node02.infra.solutions.work Uuid: 87fab40a-2395-41ce-857d-0b846e078cdb State: Peer in Cluster (Connected) Hostname: node01.infra.solutions.work Uuid: f25e6bff-e5e2-465f-a33e-9148bef94633 State: Peer in Cluster (Connected) ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/DI6AWTLIQIPWNK2M7PBABQ4TAPB4J3S3/
[ovirt-users] Upgrading librbd1 and librados2 for oVirt 4.2.x
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 the oVirt repository. A hint on how to get a more recent versions of the above libraries would be very much appreciated. Thanks, - Andreas ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YA3WNB6O7B4ZRI3PIG46IZCIMDFXSYZL/
[ovirt-users] Re: Upgrading librbd1 and librados2 for oVirt 4.2.x
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 = https://raw.githubusercontent.com/CentOS-Storage-SIG/centos-release-storage-common/master/RPM-GPG-KEY-CentOS-SIG-Storage includepkgs = librados2 librbd1 lttng-ust ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/BW5KVW5UCJDWM4ZSLONZQ547OHYI33Z6/
[ovirt-users] Re: 4.2 / 4.3 : Moving the hosted-engine to another storage
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 up completely: - This backup command is sufficient ? No further switches ? "engine-backup --mode=backup --file=[EngineBackupFile] --log=[LogFILE]" - Do I need to place the node to which I want to deploy engine into maintenance before doing the backup? This is referred in the stated documentation as: "If a hosted-engine host is carrying a virtual load at the time of backup [...] then a host [...] cannot be used to deploy a restored self-hosted engine." This is still true? If yes: all other precautions apply from that documentation? - before creating the new engine on the new storage, the old engine need to be un-deployed on all engine-HA hosts. I am unable to find information about this issue. Just un-deploy via web ui? - I want to deploy on a gluster volume that has been automatically created by the Node setup. The file /etc/gluster/glusterd.vol does not carry "option rpc-auth-allow-insecure on" which is mentioned in the documentation. Do I need to follow the instructions for gluster, or are settings already sufficiently set by the automatic gluster deployment done by oVirt Node setup? I already have some VM images running on that gluster storage anyway. Thanks for your help. - Andreas ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TQNWNUHROMQLO2RSPRCMW3E5J7Y4USJD/
[ovirt-users] 4.2 / 4.3 : Moving the hosted-engine to another storage
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 would prevent a successful move of the engine even with backup/restore. The situation seem to have improved, but I'm not sure. So I ask. We have to move our engine away from our older Cluster with NFS Storage backends (engine, volumes, iso-images). The engine should be restored on our new cluster that has a gluster volume available for the engine. Additionally this 3-node cluster is running Guests from a Cinder/Ceph storage Domain. I want to restore the engine on a different cluster to a different storage domain. Reading the documentation at https://www.ovirt.org/documentation/self-hosted/chap-Backing_up_and_Restoring_an_EL-Based_Self-Hosted_Environment.html I am wondering whether oVirt Nodes (formerly Node-NG) are capable of restoring an engine at all. Do I need EL-based Nodes? We are currently running on oVirt Nodes. - Andreas ___ 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: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/Y7EPAGSARSUFGYRABDX7M7BNAVBRAFHS/
