[ovirt-users] Re: NFS Synology NAS (DSM 7)

[Alex K]

On Fri, Aug 27, 2021, 19:48 Maton, Brett  wrote:

> Hi List,
>
>   I can't get oVirt 4.4.8.5-1.el8 (running on oVirt Node hosts) to connect
> to an NFS share on a Synology NAS.
>
>   I gave up trying to get the hosted engine deployed and put that on an
> iscsi volume instead...
>
>   The directory being exported from NAS is owned by vdsm / kvm (36:36)
> perms I've tried:
>   0750
>   0755
>   0777
>
> Tried auto / v3 / v4_0
>
>   As others have mentioned regarding NFS, if I connect manually from the
> host with
>
>   mount nas.mydomain.com:/volume1/ov_nas
>
>   It connects and works just fine.
>
>   If I try to add the share as a domain in oVirt I get
>
> Operation Cancelled
> Error while executing action Add Storage Connection: Permission settings
> on the specified path do not allow access to the storage.
> Verify permission settings on the specified storage path.
>
> When tailing /var/log/messages on
>
> When tailing /var/log/messages on the oVirt host, I see this message
> appear (I changed the domain name for this post so the dots might be
> transcoded in reality):
>
> Aug 27 17:36:07 ov001 systemd[1]: 
> rhev-data\x2dcenter-mnt-nas.mydomain.com:_volume1_ov__nas.mount:
> Succeeded.
>
>   The NAS is running the 'new' DSM 7, /etc/exports looks like this:
>
> /volume1/ov_nas  x.x.x.x(rw,async,no_root_squash,anonuid=36,anongid=36)
>
Did you try squashing to root?

>
>
> (reloaded with exportfs -ra)
>
>
> Any suggestions appreciated.
>
> Regards,
> Brett
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/Y74ILXTU6L2XEIIQDG5SE6WEQ6DSUOXA/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MM6CLUHHQFIWTXQSIQ7C7EPWFAW3NAOF/

[ovirt-users] Re: Fencing ilo4

[Alex K]

On Fri, Aug 27, 2021, 20:33  wrote:

> Hi
> This thread points to the same thing but there's no solution.
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/CGHM7K2DJH76MQSDYNBNXI4LXUU7IHHS/
> I am seting up a new kvm environment. Oracle linux virtualization manager
> is up, kvm host prepared and I am trying to set up fencing with ilo4.
>
> When adding via gui I get
> ERROR [org.ovirt.engine.core.bll.pm.FenceProxyLocator] (default task-12)
> [62fc5810-5d9a-4baf-b1a7-983da8d039fc] Can not run fence action on host
> 'kvm1', no suitable proxy host was found.
>
I think you need at least two hosts to test power management from UI.

I left options blank but tried privlvl=operator,lanplus=on and nothing.


>
> Test via cli works fine.
> [root@kvm1 lib]# fence_ilo4 -a 192.168.9.98 -l Administrator -p ***-v -o
> status
> 2021-08-27 14:18:56,815 INFO: Executing: /usr/bin/ipmitool -I lanplus -H
> 192.168.9.98 -p 623 -U Administrator -P [set] -L ADMINISTRATOR chassis
> power status
> 2021-08-27 14:18:56,982 DEBUG: 0 Chassis Power is on
> Status: ON
>
> Error message because of that.
> Health check on Host kvm1 indicates that future attempts to Stop this host
> using Power-Management are expected to fail.
>
> Can anyone help?
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/VQVAT254OVIKCFAOC42BB4264FNNVZID/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/U6I7IHGJLHSZKMPGVBMN5FDGMYOEET5U/

[ovirt-users] Re: export VM from oVirt engine 3.5

[Alex K]

On Thu, Jul 8, 2021, 20:19  wrote:

> Hello,
> I am trying to export a bunch o VM from  oVirt version 3.5
> The problem is that there is no OVA support for exporting them. I also
> tryed to export VMs into OVA format using ovirtsdk4 which anyway won't work
> on oVirt 3.5.
> I can successfully export to a NFS partition but for each VM there are
> several qcow v2 files which I suppose to be the VM image and its snapshots.
> How to identify the correct file to represent the current VM status ?
>
When exporting you should get only one image file with the current status
of the vm.

If you want to hack with the vm images, you can commit all the chain of the
snapshot files to your own single qcow2 copy using qemu-img commands.

> You can easily get the disk ID of the current active snapshot (vm ->
snapshots) then you can view the full chain with:
qemu-img info --backing-chain $FILENAME
You need to know what you are doing though to avoid any data loss.

If I delete all the snapshots, will I end up with only one valid qcow v2
> image that I can use ?
>
Yes, you should. You can try if the snapshots are not needed.

> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCCK7HSIVMXAH2D7F2DWLHR4J2XSSTPP/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/4J3HIIWUCVHJBMCL5TP7VR46J42MO2ED/

[ovirt-users] Re: Hosted-Engine vs Standalone Engine

[Alex K]

On Wed, Mar 24, 2021, 23:04 Ian Easter  wrote:

> Hello Folks,
>
> I have had to install a Hosted-Engine a few times in my environment.
> There have been some hardware issues and power issues that left the HE
> unrecoverable.
>
> In this situation, would the Standalone Engine install be more viable and
> less prone to become inoperable due to the previous issues?
>
Usually, having a daily engine backup you are covered even in the rare case
of full engine corruption. In the worst case one can wipe out the
unrecoverable engine, setup a new one and restore its status from the
backup. I had to do this once and it was fine.


> My assumption would be to have a head baremetal server run the Engine to
> control and maintain my blades.
>
> *Thank you,*
> *Ian*
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/CFXFE7M7WMXEBQBU3CJE7JFNLADVXRLO/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VWBRKLPUWUWU2PDMDGL4SFYDIO6MSAVF/

[ovirt-users] Re: Hyperconverged engine high availability?

[Alex K]

On Sat, Mar 20, 2021, 22:15 David White via Users  wrote:

> I just finished deploying oVirt 4.4.5 onto a 3-node hyperconverged cluster
> running on Red Hat 8.3 OS.
>
> Over the course of the setup, I noticed that I had to setup the storage
> for the engine separately from the gluster bricks.
>
> It looks like the engine was installed onto /rhev/data-center/ on the
> first host, whereas the gluster bricks for all 3 hosts are on
> /gluster_bricks/.
>
/rhev/data-center is a mountpoint of the gluster volume which may have its
bricks in /gluster_bricks/. You can provide more info on the gluster setup
to clarify this. gluster volume info 


> I fear that I may already know the answer to this, but:
> Is it possible to make the engine highly available?
>
Yes, one uses 3 servers to achieve HA for the guest VMs and the engine, as
long as the hosts meet the requirements of storage, network and compute.

>
> Also, thinking hypothetically here, what would happen to my VMs that are
> physically on the first server, if the first server crashed? The engine is
> what handles the high availability, correct? So what if a VM was running on
> the first host? There would be nothing to automatically "move" it to one of
> the remaining healthy hosts.
>
> Or am I misunderstanding something here?
>
>
> Sent with ProtonMail  Secure Email.
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/L6MMZSMSGIK7BTUSUECU65VZRMS4N33L/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/76OWWM33ZAEUMVKNWPOYPIQETU3DBPFT/

[ovirt-users] Re: snapshot solution: Existing snapshots that were taken after this one will be erased.

[Alex K]

On Sat, Mar 6, 2021, 09:13 Strahil Nikolov via Users 
wrote:

> Commiting a snapshot means that you want to revert to that state, which
> means that all data afterwards is lost.
> Even if you keep the latest snapshot, it won't be usefull.
> For example you got the following:
>
> Install -> snap1 -> some data -> snap2 -> some data -> snap3 -> some data
> -> Current State
>
> If you revert to snap2 you will have the following:
> Install -> snap1 -> some data -> snap2 -> some data -> Current State
>
> (you always have some extra data generated - for example system logs)
>
> As you can see, you can't use snap3 as you got some data after powering up
> the VM after the restore to snap2 and you will loose that.
>
User usually does not care of loosing such data if intentionally switches
from snapshot to snapshot. I was expecting also the same behavior,  to be
able to switch between intermediate snapshots without loosing the latest
ones. I can do this with internal snapshots in plain KVM and this is very
useful when testing different versions/snapshots of an application.

>
> Best Regards,
> Strahil Nikolov
>
> On Fri, Mar 5, 2021 at 8:32, dhanaraj.ramesh--- via Users
>  wrote:
> Hi Team,
>
> when I want to commit the older snapshots I'm getting warning stating "
> Existing snapshots that were taken after this one will be erased.". is
> there any way we can retain the latest snapshots as is in the chain?
>
> I knew cloning and template export options are there to secure that latest
> snapshot data but these are will consume additional space in storage and
> take time.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/Y5PQGBQXWTJ6O3NI6ZIV2QVEHWML7RVA/
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/I47GULR3I5FPMD2NXJ44EI5IRCUXEDPV/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CZR5U7BE7MMEFEPTBBRWIUUN25SRPWXC/

[ovirt-users] Re: Gluster volume engine stuck in healing with 1 unsynched entry & HostedEngine paused

[Alex K]

On Thu, Mar 4, 2021 at 8:59 PM  wrote:

> Hello again,
> I've tried to heal the brick with latest-mtime, but I get the following:
>
> gluster volume heal engine split-brain latest-mtime
> /80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7
> Healing
> /80f6e393-9718-4738-a14a-64cf43c3d8c2/images/d5de54b6-9f8e-4fba-819b-ebf6780757d2/a48555f4-be23-4467-8a54-400ae7baf9d7
> failed: File not in split-brain.
> Volume heal failed.
>
you can try to run ls at the directory where the file which healing is
pending resides.  This might trigger the healing process of that file.


> Should I try the solution described in this question, where we manually
> remove the conflicting entry, triggering the heal operations?
>
> https://lists.ovirt.org/archives/list/users@ovirt.org/thread/RPYIMSQCBYVQ654HYGBN5NCPRVCGRRYB/#H6EBSPL5XRLBUVZBE7DGSY25YFPIR2KY
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/CCRNM7N3FSUYXDHFP2XDMGAMKSHBMJQQ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/RJO7EVEW2C3P7EYTAIXZVIC7JBSEXM3C/

[ovirt-users] Re: Gluster volume engine stuck in healing with 1 unsynched entry & HostedEngine paused

[Alex K]

On Wed, Mar 3, 2021, 19:13  wrote:

> Hello,
>
> Thank you very much for your reply.
>
> I get the following from the below gluster commands:
>
> [root@ov-no1 ~]# gluster volume heal engine info split-brain
> Brick ov-no1.ariadne-t.local:/gluster_bricks/engine/engine
> Status: Connected
> Number of entries in split-brain: 0
>
> Brick ov-no2.ariadne-t.local:/gluster_bricks/engine/engine
> Status: Connected
> Number of entries in split-brain: 0
>
> Brick ov-no3.ariadne-t.local:/gluster_bricks/engine/engine
> Status: Connected
> Number of entries in split-brain: 0
>
>
> [root@ov-no1 ~]# gluster volume heal engine info summary
> Brick ov-no1.ariadne-t.local:/gluster_bricks/engine/engine
> Status: Connected
> Total Number of entries: 1
> Number of entries in heal pending: 1
> Number of entries in split-brain: 0
> Number of entries possibly healing: 0
>
> Brick ov-no2.ariadne-t.local:/gluster_bricks/engine/engine
> Status: Connected
> Total Number of entries: 1
> Number of entries in heal pending: 1
> Number of entries in split-brain: 0
> Number of entries possibly healing: 0
>
> Brick ov-no3.ariadne-t.local:/gluster_bricks/engine/engine
> Status: Connected
> Total Number of entries: 1
> Number of entries in heal pending: 1
> Number of entries in split-brain: 0
> Number of entries possibly healing: 0
>
>
> [root@ov-no1 ~]# gluster volume info
> Volume Name: data
> Type: Replicate
> Volume ID: 6c7bb2e4-ed35-4826-81f6-34fcd2d0a984
> Status: Started
> Snapshot Count: 0
> Number of Bricks: 1 x (2 + 1) = 3
> Transport-type: tcp
> Bricks:
> Brick1:
> ov-no1.ariadne-t.local:/gluster_bricks/data/data
> Brick2:
> ov-no2.ariadne-t.local:/gluster_bricks/data/data
> Brick3:
> ov-no3.ariadne-t.local:/gluster_bricks/data/data (arbiter)
> Options Reconfigured:
> performance.client-io-threads: on
> nfs.disable: on
> transport.address-family: inet
> performance.strict-o-direct: on
> performance.quick-read: off
> performance.read-ahead: off
> performance.io-cache: off
> performance.low-prio-threads: 32
> network.remote-dio: off
> cluster.eager-lock: enable
> cluster.quorum-type: auto
> cluster.server-quorum-type: server
> cluster.data-self-heal-algorithm: full
> cluster.locking-scheme: granular
> cluster.shd-max-threads: 8
> cluster.shd-wait-qlength: 1
> features.shard: on
> user.cifs: off
> cluster.choose-local: off
> client.event-threads: 4
> server.event-threads: 4
> network.ping-timeout: 30
> storage.owner-uid: 36
> storage.owner-gid: 36
> cluster.granular-entry-heal: enable
>
> Volume Name: engine
> Type: Replicate
> Volume ID: 7173c827-309f-4e84-a0da-6b2b8eb50264
> Status: Started
> Snapshot Count: 0
> Number of Bricks: 1 x 3 = 3
> Transport-type: tcp
> Bricks:
> Brick1:
> ov-no1.ariadne-t.local:/gluster_bricks/engine/engine
> Brick2:
> ov-no2.ariadne-t.local:/gluster_bricks/engine/engine
> Brick3:
> ov-no3.ariadne-t.local:/gluster_bricks/engine/engine
> Options Reconfigured:
> performance.client-io-threads: on
> nfs.disable: on
> transport.address-family: inet
> performance.strict-o-direct: on
> performance.quick-read: off
> performance.read-ahead: off
> performance.io-cache: off
> performance.low-prio-threads: 32
> 

[ovirt-users] Re: Gluster volume engine stuck in healing with 1 unsynched entry & HostedEngine paused

[Alex K]

On Mon, Mar 1, 2021, 15:20  wrote:

> Hello again,
>
> I am back with a brief description of the situation I am in, and questions
> about the recovery.
>
> oVirt environment: 4.3.5.2 Hyperconverged
> GlusterFS: Replica 2 + Arbiter 1
> GlusterFS volumes: data, engine, vmstore
>
> The current situation is the following:
>
> - The Cluster is in Global Maintenance.
>
> - The volume engine is up with comment (in the Web GUI) : Up, unsynched
> entries, needs healing.
>
> - The VM HostedEngine is paused due to a storage I/O error (Web GUI) while
> the output of virsh list --all command shows that the HostedEngine is
> running.
>
> I tried to issue the gluster heal command (gluster volume heal engine) but
> nothing changed.
>
> I have the following questions:
>
> 1. Should I restart the glusterd service? Where from? Is it enough if the
> glusterd is restarted on one host or should it be restarted on the other
> two as well?
>
It sounds as a gluster split brain. I would start from there. Can you check
status by listing split brain entries?

>
> 2. Should the node that was NonResponsive and came back, be rebooted or
> not? It seems alright now and in good health.
>
> 3. Should the HostedEngine be restored with engine-backup or is it not
> necessary?
>
> 4. Could the loss of the DNS server for the oVirt hosts lead to an
> unresponsive host?
> The nsswitch file on the ovirt hosts and engine, has the DNS defined as:
> hosts:  files dns myhostname
>
If you have opted for dns liveliness checks it could be.

>
> 5. How can we recover/rectify the situation above?
>
I would start checking for gluster split brains and ensure that all hosts
have connectivity in the storage domain net (ping, jumbo frames if
enabled). 99% of my similar issues have been caused from gluster split.

The fact that the engine is shown as paused and that you can still access
web ui makes me think you have a split brain issue

>
> Thanks for your help,
> Maria Souvalioti
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/GO6S6GXRJWYZN5NZ5IFTNQ6SGNEB75WQ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZNIFUDLRYHU3YTYC35OLXVVHYKAPNJZI/

[ovirt-users] Re: recovering gluster volumes when moving hosts to a new datacenter

[Alex K]

On Fri, Jan 29, 2021, 12:15 Nathanaël Blanchet  wrote:

> Hi,
>
> I moved 3 hosts (for replica 3 volume) from a previous datacenter to a
> new datacenter.
>
> Those hosts had initially been configured in a gluster cluster and
> managed multiple gluster volume created with ovirt UI.
>
> These hosts are now apart of a new gluster cluster and they see each
> others with cli "gluster peer status" as well as the associated volumes
> "gluter volumes list".
>
> But I can't make gluster volumes visible in the usually "volume" tab, so
> ovirt doesn't seem to see them.
>
> Is there a way to import pre existing gluster volume so as to ovirt be
> able to manage them ?
>
Have you enabled gluster under cluster options?

>
> Thanks.
>
> --
> Nathanaël Blanchet
>
> Supervision réseau
> SIRE
> 227 avenue Professeur-Jean-Louis-Viala
> 34193 MONTPELLIER CEDEX 5
> Tél. 33 (0)4 67 54 84 55
> Fax  33 (0)4 67 54 84 14
> blanc...@abes.fr
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/OW27PE5P7GXXBWJWAYQGZCFUCERYVVLY/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/N45YODHDC7JDZGCIQKMELCI62VFNWGRG/

[ovirt-users] Re: oVirt Engine no longer Starting

[Alex K]

On Sat, Jan 16, 2021, 16:08 penguin pages  wrote:

>
> Thanks for help following below.
>
> 1) Auth to Libvirtd and show VM "hosted engine"  but also now that I
> manually registered "ns01" per above
> [root@medusa ~]# vdsm-client Host getVMList
> [
> {
> "status": "Down",
> "statusTime": "2218288798",
> "vmId": "69ab4f82-1a53-42c8-afca-210a3a2715f1"
> }
> ]
> [root@medusa ~]# virsh -c
> qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf
> Welcome to virsh, the virtualization interactive terminal.
>
> Type:  'help' for help with commands
>'quit' to quit
>
> virsh # list --all
>  Id   NameState
> 
>  -HostedEngineshut off
>  -HostedEngineLocal   shut off
>  -ns01shut off
>
> 2) Start VM  but seems network is needed first
> virsh # start HostedEngine
> error: Failed to start domain HostedEngine
> error: Network not found: no network with matching name 'vdsm-ovirtmgmt'
>
> virsh # start HostedEngineLocal
> error: Failed to start domain HostedEngineLocal
> error: Requested operation is not valid: network 'default' is not active
>
> 3) Start Networks:  This is "next next" HCI+Gluster build so it called it
> "ovirtmgmt"
> virsh # net-list
>  Name  StateAutostart   Persistent
> 
>  ;vdsmdummy;   active   no  no
> virsh # net-autostart --network default
> Network default marked as autostarted
> virsh # net-start default
> Network default started
> virsh # start HostedEngineLocal
> error: Failed to start domain HostedEngineLocal
> error: Cannot access storage file '/var/tmp/localvmn4khg_ak/seed.iso': No
> such file or directory
>
> <<<>>
>
> virsh # dumpxml HostedEngineLocal
> 
>   HostedEngineLocal
>   bb2006ce-838b-47a3-a049-7e3e5c7bb049
>   
> http://libosinfo.org/xmlns/libvirt/domain/1.0;>
>   http://redhat.com/rhel/8.0"/>
> 
>   
>   16777216
>   16777216
>   4
>   
> hvm
> 
> 
>   
>   
> 
> 
>   
>   
>   
> 
>   
>   destroy
>   restart
>   destroy
>   
> 
> 
>   
>   
> /usr/libexec/qemu-kvm
> 
>   
>file='/var/tmp/localvmn4khg_ak/images/e2e4d97c-3430-4880-888e-84c283a80052/0f78b6f7-7755-4fe5-90e3-d41df791a645'/>
>   
>function='0x0'/>
> 
> 
>   
>   
>   
>   
>   
> 
> 
> 
>function='0x2'/>
> 
> 
> 
>   
>   
>function='0x0' multifunction='on'/>
> 
> 
>   
>   
>function='0x1'/>
> 
> 
>   
>   
>function='0x2'/>
> 
> 
>   
>   
>function='0x3'/>
> 
> 
>   
>   
>function='0x4'/>
> 
> 
>function='0x0'/>
> 
> 
>   
>   
>   
>function='0x0'/>
> 
> 
>   
> 
>   
> 
> 
>   
> 
> 
>   
>   
> 
> 
> 
> 
>   
> 
> 
>   
>function='0x0'/>
> 
> 
> 
>   /dev/random
>function='0x0'/>
> 
>   
> 
>
> virsh #
>
> ##So not sure what hosted engine needs an ISO image.  Can I remove this?
> virsh # change-media HostedEngineLocal /var/tmp/localvmn4khg_ak/seed.iso
> --eject
> Successfully ejected media.
>
> virsh # start HostedEngineLocal
> error: Failed to start domain HostedEngineLocal
> error: Cannot access storage file
> '/var/tmp/localvmn4khg_ak/images/e2e4d97c-3430-4880-888e-84c283a80052/0f78b6f7-7755-4fe5-90e3-d41df791a645'
> (as uid:107, gid:107): No such file or directory
> [root@medusa 3afc47ba-afb9-413f-8de5-8d9a2f45ecde]# tree |grep
> e2e4d97c-3430-4880-888e-84c283a80052/0f78b6f7-7755-4fe5-90e3-d41df791a645
> [root@medusa 3afc47ba-afb9-413f-8de5-8d9a2f45ecde]# pwd
> /gluster_bricks/engine/engine/3afc47ba-afb9-413f-8de5-8d9a2f45ecde
> [root@medusa 3afc47ba-afb9-413f-8de5-8d9a2f45ecde]# tree
> .
> ├── dom_md
> │   ├── ids
> │   ├── inbox
> │   ├── leases
> │   ├── metadata
> │   ├── outbox
> │   └── xleases
> ├── ha_agent
> │   ├── hosted-engine.lockspace ->
> /run/vdsm/storage/3afc47ba-afb9-413f-8de5-8d9a2f45ecde/6023f2b1-ea6e-485b-9ac2-8decd5f7820d/b38a5e37-fac4-4c23-a0c4-7359adff619c
> │   └── hosted-engine.metadata ->
> /run/vdsm/storage/3afc47ba-afb9-413f-8de5-8d9a2f45ecde/77082dd8-7cb5-41cc-a69f-0f4c0380db23/38d552c5-689d-47b7-9eea-adb308da8027
> ├── images
> │   ├── 1dc69552-dcc6-484d-8149-86c93ff4b8cc
> │   │   ├── e4e26573-09a5-43fa-91ec-37d12de46480
> │   │   ├── e4e26573-09a5-43fa-91ec-37d12de46480.lease
> │   │   └── e4e26573-09a5-43fa-91ec-37d12de46480.meta
> │   ├── 375d2483-ee83-4cad-b421-a5a70ec06ba6
> │   │   ├── f936d4be-15e3-4983-8bf0-9ba5b97e638a
> │   │   ├── f936d4be-15e3-4983-8bf0-9ba5b97e638a.lease
> │   │   └── f936d4be-15e3-4983-8bf0-9ba5b97e638a.meta
> │   ├── 6023f2b1-ea6e-485b-9ac2-8decd5f7820d
> │   │   ├── b38a5e37-fac4-4c23-a0c4-7359adff619c
> │   │   ├── 

[ovirt-users] Re: oVirt Engine no longer Starting

[Alex K]

On Fri, Jan 15, 2021, 22:04 penguin pages  wrote:

>
> Thanks for replies.
>
> Here is where it is at:
>
> # Two nodes think no VMs exist
> [root@odin ~]# vdsm-client Host getVMList
> []
>
> #One showing one VM but down
> [root@medusa ~]# vdsm-client Host getVMList
> [
> {
> "status": "Down",
> "statusTime": "2153886148",
> "vmId": "69ab4f82-1a53-42c8-afca-210a3a2715f1"
> }
> ]
> [root@medusa ~]# vdsm-client Host getAllVmStats
> [
> {
> "exitCode": 1,
> "exitMessage": "VM terminated with error",
> "exitReason": 1,
> "status": "Down",
> "statusTime": "2153916276",
> "vmId": "69ab4f82-1a53-42c8-afca-210a3a2715f1"
> }
> ]
> [root@medusa ~]# vdsm-client VM cont
> vmID="69ab4f82-1a53-42c8-afca-210a3a2715f1"
> vdsm-client: Command VM.cont with args {'vmID':
> '69ab4f82-1a53-42c8-afca-210a3a2715f1'} failed:
> (code=16, message=Unexpected exception)
>
>
> # Assuming that ID represents the hosted-engine I tried to start it
> [root@medusa ~]# hosted-engine --vm-start
> The hosted engine configuration has not been retrieved from shared
> storage. Please ensure that ovirt-ha-agent is running and the storage
> server is reachable.
>
> # Back to ovirt-ha-agent being fubar and stoping things.
>
> I have about 8 or so VMs on the cluster. Two are my IDM nodes which has
> DNS and other core services.. which is what I am really trying to get up ..
> even if manual until I figure out oVirt issue.  I think you are correct.
> "engine" volume is for just the engine.  Data is where the other VMs are
>
> [root@medusa images]# tree
> .
> ├── 335c6b1a-d8a5-4664-9a9c-39744d511af8
> │   ├── 579323ad-bf7b-479b-b682-6e1e234a7908
> │   ├── 579323ad-bf7b-479b-b682-6e1e234a7908.lease
> │   └── 579323ad-bf7b-479b-b682-6e1e234a7908.meta
> ├── d318cb8f-743a-461b-b246-75ffcde6bc5a
> │   ├── c16877d0-eb23-42ef-a06e-a3221ea915fc
> │   ├── c16877d0-eb23-42ef-a06e-a3221ea915fc.lease
> │   └── c16877d0-eb23-42ef-a06e-a3221ea915fc.meta
> └── junk
> ├── 296163f2-846d-4a2c-9a4e-83a58640b907
> │   ├── 376b895f-e0f2-4387-b038-fbef4705fbcc
> │   ├── 376b895f-e0f2-4387-b038-fbef4705fbcc.lease
> │   └── 376b895f-e0f2-4387-b038-fbef4705fbcc.meta
> ├── 45a478d7-4c1b-43e8-b106-7acc75f066fa
> │   ├── b5249e6c-0ba6-4302-8e53-b74d2b919d20
> │   ├── b5249e6c-0ba6-4302-8e53-b74d2b919d20.lease
> │   └── b5249e6c-0ba6-4302-8e53-b74d2b919d20.meta
> ├── d8b708c1-5762-4215-ae1f-0e57444c99ad
> │   ├── 2536ca6d-3254-4cdc-bbd8-349ec1b8a0e9
> │   ├── 2536ca6d-3254-4cdc-bbd8-349ec1b8a0e9.lease
> │   └── 2536ca6d-3254-4cdc-bbd8-349ec1b8a0e9.meta
> └── eaf12f3c-301f-4b61-b5a1-0c6d0b0a7f7b
> ├── fbf3bf59-a23a-4c6f-b66e-71369053b406
> ├── fbf3bf59-a23a-4c6f-b66e-71369053b406.lease
> └── fbf3bf59-a23a-4c6f-b66e-71369053b406.meta
>
> 7 directories, 18 files
> [root@medusa images]# cd /media/engine/
> [root@medusa engine]# ls
> 3afc47ba-afb9-413f-8de5-8d9a2f45ecde
> [root@medusa engine]# tree
> .
> └── 3afc47ba-afb9-413f-8de5-8d9a2f45ecde
> ├── dom_md
> │   ├── ids
> │   ├── inbox
> │   ├── leases
> │   ├── metadata
> │   ├── outbox
> │   └── xleases
> ├── ha_agent
> ├── images
> │   ├── 1dc69552-dcc6-484d-8149-86c93ff4b8cc
> │   │   ├── e4e26573-09a5-43fa-91ec-37d12de46480
> │   │   ├── e4e26573-09a5-43fa-91ec-37d12de46480.lease
> │   │   └── e4e26573-09a5-43fa-91ec-37d12de46480.meta
> │   ├── 375d2483-ee83-4cad-b421-a5a70ec06ba6
> │   │   ├── f936d4be-15e3-4983-8bf0-9ba5b97e638a
> │   │   ├── f936d4be-15e3-4983-8bf0-9ba5b97e638a.lease
> │   │   └── f936d4be-15e3-4983-8bf0-9ba5b97e638a.meta
> │   ├── 6023f2b1-ea6e-485b-9ac2-8decd5f7820d
> │   │   ├── b38a5e37-fac4-4c23-a0c4-7359adff619c
> │   │   ├── b38a5e37-fac4-4c23-a0c4-7359adff619c.lease
> │   │   └── b38a5e37-fac4-4c23-a0c4-7359adff619c.meta
> │   ├── 685309b1-1ae9-45f3-90c3-d719a594482d
> │   │   ├── 9eddcf51-fd15-4de5-a4b6-a83a9082dee0
> │   │   ├── 9eddcf51-fd15-4de5-a4b6-a83a9082dee0.lease
> │   │   └── 9eddcf51-fd15-4de5-a4b6-a83a9082dee0.meta
> │   ├── 74f1b2e7-2483-4e4d-8301-819bcd99129e
> │   │   ├── c1888b6a-c48e-46ce-9677-02e172ef07af
> │   │   ├── c1888b6a-c48e-46ce-9677-02e172ef07af.lease
> │   │   └── c1888b6a-c48e-46ce-9677-02e172ef07af.meta
> │   └── 77082dd8-7cb5-41cc-a69f-0f4c0380db23
> │   ├── 38d552c5-689d-47b7-9eea-adb308da8027
> │   ├── 38d552c5-689d-47b7-9eea-adb308da8027.lease
> │   └── 38d552c5-689d-47b7-9eea-adb308da8027.meta
> └── master
> ├── tasks
> │   ├── 150927c5-bae6-45e4-842c-a7ba229fc3ba
> │   │   └── 150927c5-bae6-45e4-842c-a7ba229fc3ba.job.0
> │   ├── 21bba697-26e6-4fd8-ac7c-76f86b458368.temp
> │   ├── 26c580b8-cdb2-4d21-9bea-96e0788025e6.temp
> │   ├── 2e0e347c-fd01-404f-9459-ef175c82c354.backup
> │   │   └── 

[ovirt-users] Re: oVirt Engine no longer Starting

[Alex K]

On Fri, Jan 15, 2021, 20:20 Strahil Nikolov via Users 
wrote:

>
> >
> > Questions:
> > 1) I have two important VMs that have snapshots that I need to boot
> > up.  Is their a means with an HCI configuration to manually start the
> > VMs without oVirt engine being up?
> What it worked for me was:
> 1) Start a VM via "virsh"
> define a virsh alias:
> alias virsh='virsh -c qemu:///system?authfile=/etc/ovirt-hosted-
> engine/virsh_auth.conf'
> Check the host's vdsm.log ,where the VM was last started - you will
> find the VM's xml inside .
> Copy the whole xml and use virsh to define the VM "virsh define
> myVM.xml && virsh start myVM"
>
If you cannot find the xml file of the vm then you van use virt install as
if you were running in plain KVM.


> 2) vdsm-client most probably can start VMs even when the engine is down
> > 2) Is their a means to debug what is going on with the engine failing
> > to start to repair (I hate reloading as the only fix for systems)
> You can use "hosted-engine" to start the HostedEngine VM in paused mode
> . Then you can connect over spice/vnc and then unpause the VM. Booting
> the HostedEngine VM from DVD is a little bit harder. You will need to
> get the HE's xml and edit it to point to the DVD. Once you got the
> altered HE config , you can define and start.
> > 3) Is their a means to re-deploy HCI setup wizard, but use the
> > "engine" volume and so retain the VMs and templates?
> You are not expected to mix HostedEngine and other VMs on the same
> storage domain (gluster volume).
>
> Best Regards,
> Strahil Nikolov
> >
> >
> >
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/privacy-policy.html
> > oVirt Code of Conduct:
> > https://www.ovirt.org/community/about/community-guidelines/
> > List Archives:
> >
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/KPURBXOULJ7NPFS7LTTXQI3O5QRVHHY3/
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/U5ZKGRY63OZSEIQVSZAKTFX4EX4EJOI3/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5DYQCR2SRXIRQELJ6VFMUGG7IRKZ2GE5/

[ovirt-users] Re: potential split-brain after upgrading Gluster version and rebooting one of three storage nodes

[Alex K]

On Mon, Jan 11, 2021, 20:51 Jayme  wrote:

> Correct me if I'm wrong but according to the docs, there might be a more
> elegant way of doing something similar with gluster cli ex: gluster volume
> heal  split-brain latest-mtime  -- although I have never
> tried it myself.
>
This is the usual way I resolve split brains.


> On Mon, Jan 11, 2021 at 1:50 PM Strahil Nikolov via Users 
> wrote:
>
>>
>> > Is this a split brain situation and how can I solve this? I would be
>> > very grateful for any help.
>> I've seen it before. Just check on the nodes which brick contains the
>> newest file (there is a timestamp inside it) and then rsync that file
>> from the node with newest version to the rest.
>> If gluster keeps showing that the file is still needing heal - just
>> "cat" it from the FUSE client (the mountpoint in /rhev/).
>>
>> Best Regards,
>> Strahil Nikolov
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/2GLJIZQLFUZFSIVAVFFNG4CJZHNY7HFP/
>>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/DRZ76K554HN24ZVSVR7D2LGCUAICQCLR/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/46S3DOQHR6HEZYHXNKCQDZCFZY3BA6QN/

[ovirt-users] Re: 2021 first ovirt network question

[Alex K]

On Thu, Jan 7, 2021, 16:14  wrote:

> Thanks for advice.
> Here is the iperf3 test results
>
> Connecting to host xyz.example.com, port 6000
> [  4] local XXX.XXX.XXX.XXX port 36140 connected to XYZ.XYZ.XYZ.XYZ port
> 6000
> [ ID] Interval   Transfer Bandwidth   Retr  Cwnd
> [  4]   0.00-1.00   sec  81.9 MBytes   687 Mbits/sec0352 KBytes
>
> [  4]   1.00-2.00   sec  80.5 MBytes   676 Mbits/sec0352 KBytes
>
> [  4]   2.00-3.00   sec  80.5 MBytes   676 Mbits/sec0362 KBytes
>
> [  4]   3.00-4.00   sec  79.8 MBytes   669 Mbits/sec0362 KBytes
>
> [  4]   4.00-5.00   sec  80.6 MBytes   676 Mbits/sec0362 KBytes
>
> [  4]   5.00-6.00   sec  82.0 MBytes   688 Mbits/sec0362 KBytes
>
> [  4]   6.00-7.00   sec  81.3 MBytes   682 Mbits/sec0362 KBytes
>
> [  4]   7.00-8.00   sec  80.5 MBytes   676 Mbits/sec0362 KBytes
>
> [  4]   8.00-9.00   sec  80.5 MBytes   676 Mbits/sec0362 KBytes
>
> [  4]   9.00-10.00  sec  79.8 MBytes   669 Mbits/sec0362 KBytes
>
Assuming xyz.example.com is in the display network you need to find out
what is throttling you at these values.

>
> Actually, what i was trying to ask is is there any reletion between
> "default route" and "display" network on oVirt network.
>
No, they should not be related

Because, if there is, it might be the source of the problem.
> As i wrote above, my "ovirtmanagement" and "default route"  network on the
> 1Gb port
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/TPQXDGMQOVCO2FFBOW2S5G4AVPSIZ2ZB/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/F77JSYHOKXTZCZFFMNN2IZTHLCNHC4HP/

[ovirt-users] Re: CentOS Stream support

[Alex K]

On Fri, Jun 5, 2020, 11:36 Michal Skrivanek 
wrote:

> Hi all,
> we would like to ask about interest in community about oVirt moving to
> CentOS Stream.
> There were some requests before but it’s hard to see how many people would
> really like to see that.
>
> With CentOS releases lagging behind RHEL for months it’s interesting to
> consider moving to CentOS Stream as it is much more up to date and allows
> us to fix bugs faster, with less workarounds and overhead for maintaining
> old code. E.g. our current integration tests do not really pass on CentOS
> 8.1 and we can’t really do much about that other than wait for more up to
> date packages. It would also bring us closer to make oVirt run smoothly on
> RHEL as that is also much closer to Stream than it is to outdated CentOS.
>
> So..would you like us to support CentOS Stream?
>
The answer is yes, though I do not see any other option, if I'm not
mistaken.

We don’t really have capacity to run 3 different platforms, would you still
> want oVirt to support CentOS Stream if it means “less support” for regular
> CentOS?
> There are some concerns about Stream being a bit less stable, do you share
> those concerns?
>
> Thank you for your comments,
> michal
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/3B5MJKO7BS2DMQL3XOXPNO4BU3YDL52T/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XRDC2S6RKJ2BW7MJCTMLPD6Z5RSPODPX/

[ovirt-users] Re: fence_xvm for testing

[Alex K]

On Thu, Dec 17, 2020, 14:43 Strahil Nikolov  wrote:

> Sadly no. I have used it on test Clusters with KVM VMs.
>
You mean clusters managed with pacemaker?

>
> If you manage to use oVirt as a nested setup, fencing works quite well
> with ovirt.
>
I have setup nested ovirt 4.3 on top a KVM host running centos 8 stream.

>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В четвъртък, 17 декември 2020 г., 11:16:47 Гринуич+2, Alex K <
> rightkickt...@gmail.com> написа:
>
>
>
>
>
> Hi Strahil,
>
> Do you have a working setup with fence_xvm for ovirt 4.3?
>
> On Mon, Dec 14, 2020 at 8:59 PM Strahil Nikolov 
> wrote:
> > Fence_xvm requires a key is deployed on both the Host and the VMs in
> order to succeed. What is happening when you use the cli on any of the VMs ?
> > Also, the VMs require an open tcp port to receive the necessary output
> of each request.
> >
> > Best Regards,
> > Strahil Nikolov
> >
> >
> >
> >
> >
> >
> > В понеделник, 14 декември 2020 г., 10:57:11 Гринуич+2, Alex K <
> rightkickt...@gmail.com> написа:
> >
> >
> >
> >
> >
> > Hi friends,
> >
> > I was wondering what is needed to setup fence_xvm in order to use for
> power management in virtual nested environments for testing purposes.
> >
> > I have followed the following steps:
> > https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
> >
> > I tried also engine-config -s
> CustomFenceAgentMapping="fence_xvm=_fence_xvm"
> > From command line all seems fine and I can get the status of the host
> VMs, but I was not able to find what is needed to set this up at engine UI:
> >
> >
> > At username and pass I just filled dummy values as they should not be
> needed for fence_xvm.
> > I always get an error at GUI while engine logs give:
> >
> >
> > 2020-12-14 08:53:48,343Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> kvm0.lab.local.Internal JSON-RPC error
> > 2020-12-14 08:53:48,343Z INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
> message='Internal JSON-RPC error'}, log id: 2437b13c
> > 2020-12-14 08:53:48,400Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
> and Fence Agent fence_xvm:225.0.0.12 failed.
> > 2020-12-14 08:53:48,400Z WARN
>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
> [07c1d540-6d8d-419c-affb-181495d75759] Fence action failed using proxy host
> 'kvm1.lab.local', trying another proxy
> > 2020-12-14 08:53:48,485Z ERROR 
> > [org.ovirt.engine.core.bll.pm.FenceProxyLocator]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] Can not run fence
> action on host 'kvm0.lab.local', no suitable proxy host was found.
> > 2020-12-14 08:53:48,486Z WARN
>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
> [07c1d540-6d8d-419c-affb-181495d75759] Failed to find another proxy to
> re-run failed fence action, retrying with the same proxy 'kvm1.lab.local'
> > 2020-12-14 08:53:48,582Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> kvm0.lab.local.Internal JSON-RPC error
> > 2020-12-14 08:53:48,582Z INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
> message='Internal JSON-RPC error'}, log id: 8607bc9
> > 2020-12-14 08:53:48,637Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
> and Fence Agent fence_xvm:225.0.0.12 failed.
> >
> >
> > Any idea?
> >
> > Thanx,
> > Alex
> >
> >
> 

[ovirt-users] Re: fence_xvm for testing

[Alex K]

Hi Strahil,

Do you have a working setup with fence_xvm for ovirt 4.3?

On Mon, Dec 14, 2020 at 8:59 PM Strahil Nikolov 
wrote:

> Fence_xvm requires a key is deployed on both the Host and the VMs in order
> to succeed. What is happening when you use the cli on any of the VMs ?
> Also, the VMs require an open tcp port to receive the necessary output of
> each request.
>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В понеделник, 14 декември 2020 г., 10:57:11 Гринуич+2, Alex K <
> rightkickt...@gmail.com> написа:
>
>
>
>
>
> Hi friends,
>
> I was wondering what is needed to setup fence_xvm in order to use for
> power management in virtual nested environments for testing purposes.
>
> I have followed the following steps:
> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
>
> I tried also engine-config -s
> CustomFenceAgentMapping="fence_xvm=_fence_xvm"
> From command line all seems fine and I can get the status of the host VMs,
> but I was not able to find what is needed to set this up at engine UI:
>
>
> At username and pass I just filled dummy values as they should not be
> needed for fence_xvm.
> I always get an error at GUI while engine logs give:
>
>
> 2020-12-14 08:53:48,343Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> kvm0.lab.local.Internal JSON-RPC error
> 2020-12-14 08:53:48,343Z INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
> message='Internal JSON-RPC error'}, log id: 2437b13c
> 2020-12-14 08:53:48,400Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
> and Fence Agent fence_xvm:225.0.0.12 failed.
> 2020-12-14 08:53:48,400Z WARN
>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
> [07c1d540-6d8d-419c-affb-181495d75759] Fence action failed using proxy host
> 'kvm1.lab.local', trying another proxy
> 2020-12-14 08:53:48,485Z ERROR 
> [org.ovirt.engine.core.bll.pm.FenceProxyLocator]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] Can not run fence
> action on host 'kvm0.lab.local', no suitable proxy host was found.
> 2020-12-14 08:53:48,486Z WARN
>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
> [07c1d540-6d8d-419c-affb-181495d75759] Failed to find another proxy to
> re-run failed fence action, retrying with the same proxy 'kvm1.lab.local'
> 2020-12-14 08:53:48,582Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> kvm0.lab.local.Internal JSON-RPC error
> 2020-12-14 08:53:48,582Z INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
> message='Internal JSON-RPC error'}, log id: 8607bc9
> 2020-12-14 08:53:48,637Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
> and Fence Agent fence_xvm:225.0.0.12 failed.
>
>
> Any idea?
>
> Thanx,
> Alex
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/B7IHC4MYY5LJFJMEJMLRRFSTMD7IK23I/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/2DRBMQPDNN3KJL2CPODXVAJBA5X5OJ4J/

[ovirt-users] Re: fence_xvm for testing

[Alex K]

On Tue, Dec 15, 2020 at 1:43 PM emesika  wrote:

> The problem is that the custom fencing configuration is not defined well
>
> Please follow [1] and retry
>
> [1]
> https://www.ovirt.org/develop/developer-guide/engine/custom-fencing.html
>
Yes, I followed that.
I cannot see what I am missing:

[root@manager ~]# engine-config -g CustomVdsFenceType
CustomVdsFenceType: fence_xvm version: general
[root@manager ~]# engine-config -g CustomFenceAgentMapping
CustomFenceAgentMapping: fence_xvm=xvm version: general
[root@manager ~]# engine-config -g CustomVdsFenceOptionMapping
CustomVdsFenceOptionMapping: fence_xvm: version: general


>
> On Tue, Dec 15, 2020 at 12:56 PM Alex K  wrote:
>
>>
>>
>> On Tue, Dec 15, 2020 at 12:34 PM Martin Perina 
>> wrote:
>>
>>>
>>>
>>> On Tue, Dec 15, 2020 at 11:18 AM Alex K  wrote:
>>>
>>>>
>>>>
>>>> On Tue, Dec 15, 2020 at 11:59 AM Martin Perina 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> could you please provide engine.log? And also vdsm.log from a host
>>>>> which was acting as a fence proxy?
>>>>>
>>>>
>>>> At proxy host (kvm1) I see the following vdsm.log:
>>>>
>>>> 2020-12-15 10:13:03,933+ INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer]
>>>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
>>>> 2020-12-15 10:13:04,376+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer]
>>>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
>>>>
>>>
>>> Isn't there stdout and stderr content of fence_xvm execution a few lines
>>> above, which should reveal the exact error? If not, then could you please
>>> turn on debug logging using below command:
>>>
>>> vdsm-client Host setLogLevel level=DEBUG
>>>
>>> This should be executed on the host which acts as a fence proxy (if you 
>>> have multiple hosts, then you would need to turn on debug on all, because 
>>> the fence proxy is selected randomly).
>>>
>>> Once we will have vdsm.log with fence_xvm execution details, then you can 
>>> change log level to INFO again by running:
>>>
>>> I had to set engine-config -s CustomFenceAgentMapping="fence_xvm=xvm"
>> at engine, as it seems the host prepends fence_.
>> After that I got the following at the proxy host with DEBUG enabled:
>>
>> 2020-12-15 10:51:57,891+ DEBUG (jsonrpc/7) [jsonrpc.JsonRpcServer]
>> Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
>> u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
>> u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
>> 2020-12-15 10:51:57,892+ DEBUG (jsonrpc/7) [root] /usr/bin/taskset
>> --cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
>> 2020-12-15 10:51:57,911+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer]
>> RPC call Host.fenceNode failed (error 1) in 0.02 seconds (__init__:312)
>> 2020-12-15 10:51:58,339+ DEBUG (jsonrpc/5) [jsonrpc.JsonRpcServer]
>> Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
>> u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
>> u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
>> 2020-12-15 10:51:58,340+ DEBUG (jsonrpc/5) [root] /usr/bin/taskset
>> --cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
>> 2020-12-15 10:51:58,356+ INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer]
>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312
>>
>> while at engine at got:
>> 2020-12-15 10:51:57,873Z INFO
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
>> FENCE_OPERATION_USING_AGENT_AND_PROXY_STARTED(9,020), Executing power
>> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
>> and Fence Agent xvm:225.0.0.12.
>> 2020-12-15 10:51:57,888Z INFO
>>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
>> task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] START,
>> FenceVdsVDSCommand(HostName = kvm1.lab.local,
>> FenceVdsVDSCommandParameters:{hostId='91c81bbe-5933-4ed0-b9c5-2c8c277e44c7',
>> targetVdsId='b5e8fe3d-cbea-44cb-835a-f88d6d70c163', action='STATUS',
>> agent='FenceAgent:{id='null', hostId='null', order='1', type='xvm',
>> ip='225.0.0.12', port='0', user='root', password='***',
>> encryptOptions='false', options='port=o

[ovirt-users] Re: fence_xvm for testing

[Alex K]

On Tue, Dec 15, 2020 at 12:34 PM Martin Perina  wrote:

>
>
> On Tue, Dec 15, 2020 at 11:18 AM Alex K  wrote:
>
>>
>>
>> On Tue, Dec 15, 2020 at 11:59 AM Martin Perina 
>> wrote:
>>
>>> Hi,
>>>
>>> could you please provide engine.log? And also vdsm.log from a host which
>>> was acting as a fence proxy?
>>>
>>
>> At proxy host (kvm1) I see the following vdsm.log:
>>
>> 2020-12-15 10:13:03,933+ INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer]
>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
>> 2020-12-15 10:13:04,376+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer]
>> RPC call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312)
>>
>
> Isn't there stdout and stderr content of fence_xvm execution a few lines
> above, which should reveal the exact error? If not, then could you please
> turn on debug logging using below command:
>
> vdsm-client Host setLogLevel level=DEBUG
>
> This should be executed on the host which acts as a fence proxy (if you have 
> multiple hosts, then you would need to turn on debug on all, because the 
> fence proxy is selected randomly).
>
> Once we will have vdsm.log with fence_xvm execution details, then you can 
> change log level to INFO again by running:
>
> I had to set engine-config -s CustomFenceAgentMapping="fence_xvm=xvm" at
engine, as it seems the host prepends fence_.
After that I got the following at the proxy host with DEBUG enabled:

2020-12-15 10:51:57,891+ DEBUG (jsonrpc/7) [jsonrpc.JsonRpcServer]
Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
2020-12-15 10:51:57,892+ DEBUG (jsonrpc/7) [root] /usr/bin/taskset
--cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
2020-12-15 10:51:57,911+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC
call Host.fenceNode failed (error 1) in 0.02 seconds (__init__:312)
2020-12-15 10:51:58,339+ DEBUG (jsonrpc/5) [jsonrpc.JsonRpcServer]
Calling 'Host.fenceNode' in bridge with {u'username': u'root', u'addr':
u'225.0.0.12', u'agent': u'xvm', u'options': u'port=ovirt-node0',
u'action': u'status', u'password': '', u'port': u'0'} (__init__:329)
2020-12-15 10:51:58,340+ DEBUG (jsonrpc/5) [root] /usr/bin/taskset
--cpu-list 0-3 /usr/sbin/fence_xvm (cwd None) (commands:198)
2020-12-15 10:51:58,356+ INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer] RPC
call Host.fenceNode failed (error 1) in 0.01 seconds (__init__:312

while at engine at got:
2020-12-15 10:51:57,873Z INFO
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
FENCE_OPERATION_USING_AGENT_AND_PROXY_STARTED(9,020), Executing power
management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
and Fence Agent xvm:225.0.0.12.
2020-12-15 10:51:57,888Z INFO
 [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] START,
FenceVdsVDSCommand(HostName = kvm1.lab.local,
FenceVdsVDSCommandParameters:{hostId='91c81bbe-5933-4ed0-b9c5-2c8c277e44c7',
targetVdsId='b5e8fe3d-cbea-44cb-835a-f88d6d70c163', action='STATUS',
agent='FenceAgent:{id='null', hostId='null', order='1', type='xvm',
ip='225.0.0.12', port='0', user='root', password='***',
encryptOptions='false', options='port=ovirt-node0'}', policy='null'}), log
id: e6d3e8c
2020-12-15 10:51:58,008Z WARN
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
kvm0.lab.local.Internal JSON-RPC error
2020-12-15 10:51:58,008Z INFO
 [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] FINISH, FenceVdsVDSCommand,
return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
message='Internal JSON-RPC error'}, log id: e6d3e8c
2020-12-15 10:51:58,133Z WARN
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-5) [a4f30921-37a9-45c1-97e5-26152f844d72] EVENT_ID:
FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
and Fence Agent xvm:225.0.0.12 failed.
2020-12-15 10:51:58,134Z WARN
 [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-5)
[a4f30921-37a9-45c1-97e5-26152f844d72] Fence action failed using proxy host
'kvm1.lab.local', trying another proxy
2020-12-15 10:51:58,258Z ERROR
[org.ovirt.engine.core.bll.pm.FenceProxyLocator] (default task-5)
[a4f30921-37a9-45c1-97e5-26152f844d72] Can not run fence action on host
'kvm0.lab.local', no 

[ovirt-users] Re: fence_xvm for testing

[Alex K]

09:57,695Z WARN
 [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-13)
[fa61ae72-bc0c-4487-aeec-2b847877b6b5] Failed to find another proxy to
re-run failed fence action, retrying with the same proxy 'kvm1.lab.local'
2020-12-15 10:09:57,695Z ERROR
[org.ovirt.engine.core.utils.pm.VdsFenceOptions] (default task-13)
[fa61ae72-bc0c-4487-aeec-2b847877b6b5] Cannot find fence agent named
'fence_xvm' in fence option mapping
2020-12-15 10:09:57,815Z WARN
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-13) [fa61ae72-bc0c-4487-aeec-2b847877b6b5] EVENT_ID:
VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
kvm0.lab.local.Internal JSON-RPC error
2020-12-15 10:09:57,816Z INFO
 [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
task-13) [fa61ae72-bc0c-4487-aeec-2b847877b6b5] FINISH, FenceVdsVDSCommand,
return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
message='Internal JSON-RPC error'}, log id: 4b58ec5e
2020-12-15 10:09:57,895Z WARN
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-13) [fa61ae72-bc0c-4487-aeec-2b847877b6b5] EVENT_ID:
FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
and Fence Agent fence_xvm:225.0.0.12 failed.

At engine I had set the fence agent mapping as below (and have restarted
ovirt-engine service):

engine-config -g CustomFenceAgentMapping
CustomFenceAgentMapping: fence_xvm=fence_xvm version: general

Let me know if you need more logs.
I am running ovirt 4.3.10.


> Thanks,
> Martin
>
>
> On Tue, Dec 15, 2020 at 10:23 AM Alex K  wrote:
>
>>
>>
>> On Tue, Dec 15, 2020 at 11:07 AM Alex K  wrote:
>>
>>>
>>>
>>> On Mon, Dec 14, 2020 at 8:59 PM Strahil Nikolov 
>>> wrote:
>>>
>>>> Fence_xvm requires a key is deployed on both the Host and the VMs in
>>>> order to succeed. What is happening when you use the cli on any of the VMs 
>>>> ?
>>>> Also, the VMs require an open tcp port to receive the necessary output
>>>> of each request.I
>>>
>>> I deployed keys at the physical host and virtual hosts, as per
>>> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
>>> I can get the VM status from the virtual hosts:
>>>
>>> [root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k
>>> /etc/cluster/fence_xvm.key -H ovirt-node0 -o status
>>> Status: ON
>>> You have new mail in /var/spool/mail/root
>>> [root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k
>>> /etc/cluster/fence_xvm.key -H ovirt-node1 -o status
>>> Status: ON
>>>
>>> kvm0 and kvm1 are the hostnames of each virtual host, while ovirt-node0
>>> and ovirt-node1 are the domain names of the same virtual hosts as defined
>>> at virsh.
>>>
>>
>> I am passing also the port/domain option at GUI, but from logs it seems
>> it is being ignored as it is not being logged from engine.
>>
>> [image: image.png]
>> tried also domain=ovirt-node0 with same results.
>>
>>
>>
>>>> Best Regards,
>>>> Strahil Nikolov
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> В понеделник, 14 декември 2020 г., 10:57:11 Гринуич+2, Alex K <
>>>> rightkickt...@gmail.com> написа:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi friends,
>>>>
>>>> I was wondering what is needed to setup fence_xvm in order to use for
>>>> power management in virtual nested environments for testing purposes.
>>>>
>>>> I have followed the following steps:
>>>> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
>>>>
>>>> I tried also engine-config -s
>>>> CustomFenceAgentMapping="fence_xvm=_fence_xvm"
>>>> From command line all seems fine and I can get the status of the host
>>>> VMs, but I was not able to find what is needed to set this up at engine UI:
>>>>
>>>>
>>>> At username and pass I just filled dummy values as they should not be
>>>> needed for fence_xvm.
>>>> I always get an error at GUI while engine logs give:
>>>>
>>>>
>>>> 2020-12-14 08:53:48,343Z WARN
>>>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>>>> VDS_ALERT_FENCE_TEST_FAI

[ovirt-users] Re: fence_xvm for testing

[Alex K]

On Tue, Dec 15, 2020 at 11:07 AM Alex K  wrote:

>
>
> On Mon, Dec 14, 2020 at 8:59 PM Strahil Nikolov 
> wrote:
>
>> Fence_xvm requires a key is deployed on both the Host and the VMs in
>> order to succeed. What is happening when you use the cli on any of the VMs ?
>> Also, the VMs require an open tcp port to receive the necessary output of
>> each request.I
>
> I deployed keys at the physical host and virtual hosts, as per
> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
> I can get the VM status from the virtual hosts:
>
> [root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k
> /etc/cluster/fence_xvm.key -H ovirt-node0 -o status
> Status: ON
> You have new mail in /var/spool/mail/root
> [root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k
> /etc/cluster/fence_xvm.key -H ovirt-node1 -o status
> Status: ON
>
> kvm0 and kvm1 are the hostnames of each virtual host, while ovirt-node0
> and ovirt-node1 are the domain names of the same virtual hosts as defined
> at virsh.
>

I am passing also the port/domain option at GUI, but from logs it seems it
is being ignored as it is not being logged from engine.

[image: image.png]
tried also domain=ovirt-node0 with same results.



>> Best Regards,
>> Strahil Nikolov
>>
>>
>>
>>
>>
>>
>> В понеделник, 14 декември 2020 г., 10:57:11 Гринуич+2, Alex K <
>> rightkickt...@gmail.com> написа:
>>
>>
>>
>>
>>
>> Hi friends,
>>
>> I was wondering what is needed to setup fence_xvm in order to use for
>> power management in virtual nested environments for testing purposes.
>>
>> I have followed the following steps:
>> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
>>
>> I tried also engine-config -s
>> CustomFenceAgentMapping="fence_xvm=_fence_xvm"
>> From command line all seems fine and I can get the status of the host
>> VMs, but I was not able to find what is needed to set this up at engine UI:
>>
>>
>> At username and pass I just filled dummy values as they should not be
>> needed for fence_xvm.
>> I always get an error at GUI while engine logs give:
>>
>>
>> 2020-12-14 08:53:48,343Z WARN
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
>> kvm0.lab.local.Internal JSON-RPC error
>> 2020-12-14 08:53:48,343Z INFO
>>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
>> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
>> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
>> message='Internal JSON-RPC error'}, log id: 2437b13c
>> 2020-12-14 08:53:48,400Z WARN
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
>> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
>> and Fence Agent fence_xvm:225.0.0.12 failed.
>> 2020-12-14 08:53:48,400Z WARN
>>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
>> [07c1d540-6d8d-419c-affb-181495d75759] Fence action failed using proxy host
>> 'kvm1.lab.local', trying another proxy
>> 2020-12-14 08:53:48,485Z ERROR 
>> [org.ovirt.engine.core.bll.pm.FenceProxyLocator]
>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] Can not run fence
>> action on host 'kvm0.lab.local', no suitable proxy host was found.
>> 2020-12-14 08:53:48,486Z WARN
>>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
>> [07c1d540-6d8d-419c-affb-181495d75759] Failed to find another proxy to
>> re-run failed fence action, retrying with the same proxy 'kvm1.lab.local'
>> 2020-12-14 08:53:48,582Z WARN
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
>> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
>> kvm0.lab.local.Internal JSON-RPC error
>> 2020-12-14 08:53:48,582Z INFO
>>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
>> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
>> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
>> message='Internal JSON-RPC error'}, log id: 8607bc9
>> 2020-12-14 08:53:48,637Z WARN
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghan

[ovirt-users] Re: fence_xvm for testing

[Alex K]

On Mon, Dec 14, 2020 at 8:59 PM Strahil Nikolov 
wrote:

> Fence_xvm requires a key is deployed on both the Host and the VMs in order
> to succeed. What is happening when you use the cli on any of the VMs ?
> Also, the VMs require an open tcp port to receive the necessary output of
> each request.I

I deployed keys at the physical host and virtual hosts, as per
https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
I can get the VM status from the virtual hosts:

[root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k /etc/cluster/fence_xvm.key
-H ovirt-node0 -o status
Status: ON
You have new mail in /var/spool/mail/root
[root@kvm1 cluster]# fence_xvm -a 225.0.0.12 -k /etc/cluster/fence_xvm.key
-H ovirt-node1 -o status
Status: ON

kvm0 and kvm1 are the hostnames of each virtual host, while ovirt-node0 and
ovirt-node1 are the domain names of the same virtual hosts as defined at
virsh.

>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В понеделник, 14 декември 2020 г., 10:57:11 Гринуич+2, Alex K <
> rightkickt...@gmail.com> написа:
>
>
>
>
>
> Hi friends,
>
> I was wondering what is needed to setup fence_xvm in order to use for
> power management in virtual nested environments for testing purposes.
>
> I have followed the following steps:
> https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md
>
> I tried also engine-config -s
> CustomFenceAgentMapping="fence_xvm=_fence_xvm"
> From command line all seems fine and I can get the status of the host VMs,
> but I was not able to find what is needed to set this up at engine UI:
>
>
> At username and pass I just filled dummy values as they should not be
> needed for fence_xvm.
> I always get an error at GUI while engine logs give:
>
>
> 2020-12-14 08:53:48,343Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> kvm0.lab.local.Internal JSON-RPC error
> 2020-12-14 08:53:48,343Z INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
> message='Internal JSON-RPC error'}, log id: 2437b13c
> 2020-12-14 08:53:48,400Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
> and Fence Agent fence_xvm:225.0.0.12 failed.
> 2020-12-14 08:53:48,400Z WARN
>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
> [07c1d540-6d8d-419c-affb-181495d75759] Fence action failed using proxy host
> 'kvm1.lab.local', trying another proxy
> 2020-12-14 08:53:48,485Z ERROR 
> [org.ovirt.engine.core.bll.pm.FenceProxyLocator]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] Can not run fence
> action on host 'kvm0.lab.local', no suitable proxy host was found.
> 2020-12-14 08:53:48,486Z WARN
>  [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
> [07c1d540-6d8d-419c-affb-181495d75759] Failed to find another proxy to
> re-run failed fence action, retrying with the same proxy 'kvm1.lab.local'
> 2020-12-14 08:53:48,582Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
> kvm0.lab.local.Internal JSON-RPC error
> 2020-12-14 08:53:48,582Z INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
> task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
> return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
> message='Internal JSON-RPC error'}, log id: 8607bc9
> 2020-12-14 08:53:48,637Z WARN
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
> FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
> management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
> and Fence Agent fence_xvm:225.0.0.12 failed.
>
>
> Any idea?
>
> Thanx,
> Alex
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-gu

[ovirt-users] fence_xvm for testing

[Alex K]

Hi friends,

I was wondering what is needed to setup fence_xvm in order to use for power
management in virtual nested environments for testing purposes.

I have followed the following steps:
https://github.com/rightkick/Notes/blob/master/Ovirt-fence_xmv.md

I tried also

engine-config -s CustomFenceAgentMapping="fence_xvm=_fence_xvm"

>From command line all seems fine and I can get the status of the host VMs,
but I was not able to find what is needed to set this up at engine UI:

[image: image.png]
At username and pass I just filled dummy values as they should not be
needed for fence_xvm.
I always get an error at GUI while engine logs give:


2020-12-14 08:53:48,343Z WARN
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
kvm0.lab.local.Internal JSON-RPC error
2020-12-14 08:53:48,343Z INFO
 [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
message='Internal JSON-RPC error'}, log id: 2437b13c
2020-12-14 08:53:48,400Z WARN
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
and Fence Agent fence_xvm:225.0.0.12 failed.
2020-12-14 08:53:48,400Z WARN
 [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
[07c1d540-6d8d-419c-affb-181495d75759] Fence action failed using proxy host
'kvm1.lab.local', trying another proxy
2020-12-14 08:53:48,485Z ERROR
[org.ovirt.engine.core.bll.pm.FenceProxyLocator] (default task-4)
[07c1d540-6d8d-419c-affb-181495d75759] Can not run fence action on host
'kvm0.lab.local', no suitable proxy host was found.
2020-12-14 08:53:48,486Z WARN
 [org.ovirt.engine.core.bll.pm.FenceAgentExecutor] (default task-4)
[07c1d540-6d8d-419c-affb-181495d75759] Failed to find another proxy to
re-run failed fence action, retrying with the same proxy 'kvm1.lab.local'
2020-12-14 08:53:48,582Z WARN
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
VDS_ALERT_FENCE_TEST_FAILED(9,001), Power Management test failed for Host
kvm0.lab.local.Internal JSON-RPC error
2020-12-14 08:53:48,582Z INFO
 [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default
task-4) [07c1d540-6d8d-419c-affb-181495d75759] FINISH, FenceVdsVDSCommand,
return: FenceOperationResult:{status='ERROR', powerStatus='UNKNOWN',
message='Internal JSON-RPC error'}, log id: 8607bc9
2020-12-14 08:53:48,637Z WARN
 [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-4) [07c1d540-6d8d-419c-affb-181495d75759] EVENT_ID:
FENCE_OPERATION_USING_AGENT_AND_PROXY_FAILED(9,021), Execution of power
management status on Host kvm0.lab.local using Proxy Host kvm1.lab.local
and Fence Agent fence_xvm:225.0.0.12 failed.


Any idea?

Thanx,
Alex
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/B7IHC4MYY5LJFJMEJMLRRFSTMD7IK23I/

[ovirt-users] Re: OPNsense / FreeBSD 12.1

[Alex K]

On Sat, Dec 12, 2020, 03:37 Jorge Visentini 
wrote:

> Hi Alex, thank you for your reply.
>
> So ... I didn't see any error messages.
> I attached the log output and some prints to get an idea of what I'm
> talking about.
>
I see you have defined the guest to be of OS type RHEL. can you try to set
it general Linux? I don't remember now if there is a bsd/freebsd type that
you can set at os type for guest.

>
> Thank you again.
>
> Em sex., 11 de dez. de 2020 às 17:19, Alex K 
> escreveu:
>
>>
>>
>> On Fri, Dec 11, 2020, 20:39 Jorge Visentini 
>> wrote:
>>
>>> Hi all.
>>>
>>> I tried to install OPNsense 20.7.6 (FreeBSD 12.1) and it was not
>>> possible to detect the NICs.
>>>
>>> I tried both the virtio driver and the e1000. Virtio does not detect and
>>> e1000 crashes at startup.
>>> In pure KVM, it works, so I believe there is some incompatibility with
>>> oVirt 4.4.4.
>>>
>>> Any tips?
>>>
>> Please check/share the error message you observe at vdsm logs when
>> starting the VM.
>>
>>>
>>> --
>>> Att,
>>> Jorge Visentini
>>> +55 55 98432-9868
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/7EX6TQPUSZ5M6VUJO23W7FTE2XO23Y66/
>>>
>>
>
> --
> Att,
> Jorge Visentini
> +55 55 98432-9868
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BHZA6VJPA3VUUPX732HRPTDSC24WWHVS/

[ovirt-users] Re: OPNsense / FreeBSD 12.1

[Alex K]

On Fri, Dec 11, 2020, 20:39 Jorge Visentini 
wrote:

> Hi all.
>
> I tried to install OPNsense 20.7.6 (FreeBSD 12.1) and it was not possible
> to detect the NICs.
>
> I tried both the virtio driver and the e1000. Virtio does not detect and
> e1000 crashes at startup.
> In pure KVM, it works, so I believe there is some incompatibility with
> oVirt 4.4.4.
>
> Any tips?
>
Please check/share the error message you observe at vdsm logs when starting
the VM.

>
> --
> Att,
> Jorge Visentini
> +55 55 98432-9868
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/7EX6TQPUSZ5M6VUJO23W7FTE2XO23Y66/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/J5FX4SOV5I5CDYWTR4VOGUK5HT4KIZFB/

[ovirt-users] Re: Can not connect to gluster storage

[Alex K]

On Fri, Nov 27, 2020, 15:02 Stefan Wolf  wrote:

> Hello,
> I ve a host that can not connet to gluster storage.
> It has worked since I ve set up the environment, and today it stoped
> working
>
> this are the error messages in the webui
> The error message for connection kvm380.durchhalten.intern:/data returned
> by VDSM was: Failed to fetch Gluster Volume List
> Failed to connect Host kvm380.durchhalten.intern to the Storage Domains
> data.
> Failed to connect Host kvm380.durchhalten.intern to the Storage Domains
> hosted_storage.
>
>
> and here the vdsm.log
>
> StorageDomainDoesNotExist: Storage domain does not exist:
> (u'36663740-576a-4498-b28e-0a402628c6a7',)
> 2020-11-27 12:59:07,665+ INFO  (jsonrpc/2) [storage.TaskManager.Task]
> (Task='8bed48b8-0696-4d3f-966a-119219f3b013') aborting: Task is aborted:
> "Storage domain does not exist: (u'36663740-576a-4498-b28e-0a402628c6a7',)"
> - code 358 (task:1181)
> 2020-11-27 12:59:07,665+ ERROR (jsonrpc/2) [storage.Dispatcher] FINISH
> getStorageDomainInfo error=Storage domain does not exist:
> (u'36663740-576a-4498-b28e-0a402628c6a7',) (dispatcher:83)
> 2020-11-27 12:59:07,666+ INFO  (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC
> call StorageDomain.getInfo failed (error 358) in 0.38 seconds (__init__:312)
> 2020-11-27 12:59:07,698+ INFO  (jsonrpc/7) [vdsm.api] START
> connectStorageServer(domType=7,
> spUUID=u'----', conList=[{u'id':
> u'e29cf818-5ee5-46e1-85c1-8aeefa33e95d', u'vfs_type': u'glusterfs',
> u'connection': u'kvm380.durchhalten.intern:/engine', u'user': u'kvm'}],
> options=None) from=::1,40964, task_id=3a3eeb80-50ef-4710-a4f4-9d35da2ff281
> (api:48)
> 2020-11-27 12:59:07,871+ ERROR (jsonrpc/7) [storage.HSM] Could not
> connect to storageServer (hsm:2420)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 2417,
> in connectStorageServer
> conObj.connect()
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py",
> line 167, in connect
> self.validate()
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py",
> line 297, in validate
> if not self.volinfo:
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py",
> line 284, in volinfo
> self._volinfo = self._get_gluster_volinfo()
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py",
> line 329, in _get_gluster_volinfo
> self._volfileserver)
>   File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line
> 56, in __call__
> return callMethod()
>   File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line
> 54, in 
> **kwargs)
>   File "", line 2, in glusterVolumeInfo
>   File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in
> _callmethod
> raise convert_to_error(kind, result)
> GlusterVolumesListFailedException: Volume list failed: rc=30806 out=()
> err=['Volume does not exist']
> 2020-11-27 12:59:07,871+ INFO  (jsonrpc/7) [vdsm.api] FINISH
> connectStorageServer return={'statuslist': [{'status': 4149, 'id':
> u'e29cf818-5ee5-46e1-85c1-8aeefa33e95d'}]} from=::1,40964,
> task_id=3a3eeb80-50ef-4710-a4f4-9d35da2ff281 (api:54)
> 2020-11-27 12:59:07,871+ INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC
> call StoragePool.connectStorageServer succeeded in 0.18 seconds
> (__init__:312)
> 2020-11-27 12:59:08,474+ INFO  (Reactor thread)
> [ProtocolDetector.AcceptorImpl] Accepted connection from ::1:40966
> (protocoldetector:61)
> 2020-11-27 12:59:08,484+ INFO  (Reactor thread)
> [ProtocolDetector.Detector] Detected protocol stomp from ::1:40966
> (protocoldetector:125)
> 2020-11-27 12:59:08,484+ INFO  (Reactor thread) [Broker.StompAdapter]
> Processing CONNECT request (stompserver:95)
> 2020-11-27 12:59:08,485+ INFO  (JsonRpc (StompReactor))
> [Broker.StompAdapter] Subscribe command received (stompserver:124)
> 2020-11-27 12:59:08,525+ INFO  (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC
> call Host.ping2 succeeded in 0.00 seconds (__init__:312)
> 2020-11-27 12:59:08,529+ INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC
> call Host.ping2 succeeded in 0.00 seconds (__init__:312)
> 2020-11-27 12:59:08,533+ INFO  (jsonrpc/6) [vdsm.api] START
> getStorageDomainInfo(sdUUID=u'36663740-576a-4498-b28e-0a402628c6a7',
> options=None) from=::1,40966, task_id=ee3ac98e-6a93-4cb2-a626-5533c8fb78ad
> (api:48)
> 2020-11-27 12:59:08,909+ INFO  (jsonrpc/6) [vdsm.api] FINISH
> getStorageDomainInfo error=Storage domain does not exist:
> (u'36663740-576a-4498-b28e-0a402628c6a7',) from=::1,40966,
> task_id=ee3ac98e-6a93-4cb2-a626-5533c8fb78ad (api:52)
> 2020-11-27 12:59:08,910+ ERROR (jsonrpc/6) [storage.TaskManager.Task]
> (Task='ee3ac98e-6a93-4cb2-a626-5533c8fb78ad') Unexpected error (task:875)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882,
> in _run
> return fn(*args, **kargs)
>   

[ovirt-users] Re: Connecting OVN network to physical network

[Alex K]

Seems that this is not supported when the switch type of cluster is "Linux
bridge".
I will need to use a new cluster with OVS type of switch.

Below the paragraph from [1]:
1.2. Physical Networks

It is possible to connect the OVN logical networks to a physical network,
akin to OpenStack’s physnet
<https://ovirt.org/develop/release-management/features/network/provider-physical-network.html>.
The traffic on the physical external network can optionally be VLAN tagged.
Connecting to external networks is *limited* to oVirt clusters configured
to use *Open vSwitch* switch type, which is currently in tech-preview.


[1]:
https://github.com/oVirt/ovirt-provider-ovn/blob/master/docs/provider_api_description.adoc#security

On Wed, Nov 25, 2020 at 9:47 PM Alex K  wrote:

> Hi all,
>
> I have created some logical switches at the OVN network provider (the
> default provider that is configured during engine-setup). This is working
> fine.
>
> I would like though to be able to connect a logical OVN switch to a
> physical network at which the hosts have access, so as to give access to
> guest VMs to this network. When connecting such switch to a physical
> network the guest VMs do not have access to the physical network:
>
> [image: image.png]
> It seems that this should be supported from ovirt. Am I missing something?
>
> P.S. I know I can provide such connectivity through standard networking,
> though was wondering if this can be done with OVN.
>
> Many thanx,
> Alex
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MYM3HZLNJV7O5QU2SPH5IJTBLGWG2MCW/

[ovirt-users] Connecting OVN network to physical network

[Alex K]

Hi all,

I have created some logical switches at the OVN network provider (the
default provider that is configured during engine-setup). This is working
fine.

I would like though to be able to connect a logical OVN switch to a
physical network at which the hosts have access, so as to give access to
guest VMs to this network. When connecting such switch to a physical
network the guest VMs do not have access to the physical network:

[image: image.png]
It seems that this should be supported from ovirt. Am I missing something?

P.S. I know I can provide such connectivity through standard networking,
though was wondering if this can be done with OVN.

Many thanx,
Alex
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/WGSXE6ALQE3XHLIIVQCYKZFDV4L4DPGL/

[ovirt-users] Re: ovirt 4.3 - locked image vm - unable to remove a failed deploy of a guest dom

[Alex K]

On Wed, Nov 25, 2020 at 8:05 PM <3c.moni...@gruppofilippetti.it> wrote:

> Hi,
> it seems not work...
>
> bash-4.2$ psql
> psql (10.6)
> Type "help" for help.
>
> postgres=# SELECT vm_name from vms where vm_guid = (SELECT vm_guid FROM
> vm_images_view where imagestatus = 2);
> ERROR:  relation "vms" does not exist
> LINE 1: SELECT vm_name from vms where vm_guid = (SELECT vm_guid FROM...
>
seems you did not connect at engine DB.

At ovirt 4.3, do the following:

1. ssh at engine
2. su - postgres -c 'scl enable rh-postgresql10 -- psql'
3. \c engine
4. SELECT vm_name from vms where vm_guid = (SELECT vm_guid FROM
vm_images_view where imagestatus = 2);
5. SELECT image_guid from vm_images_view where imagestatus=2;
6. update images SET imagestatus=1 where image_guid = {The guid which
returned in the last query}



^
> postgres=#
>
> Thanks a lot anyway.
> M.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/KWGD5PB7ACRAJ7VQRFSYFZE2SQDZTIPY/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GT4NWMLI4M6OYTCQFGDFXGNTLENEMWSR/

[ovirt-users] Re: ovirt 4.3 - locked image vm - unable to remove a failed deploy of a guest dom

[Alex K]

On Tue, Nov 17, 2020, 18:42 <3c.moni...@gruppofilippetti.it> wrote:

> Hi.
> taskcleaner and unlock_entity are just 2 items of reported rhel solution
> I've used , but didn't worked.
> Locked Image still there!
>
I would try also to unlock it at db. Some steps from version 3.x. should be
same for 4.x:


log into the DB and perform the following


SELECT vm_name frim vms where vm_guid = (SELECT vm_guid FROM
vm_images_view where imagestatus = 2);

See if you get the VM which the disk is locked on it.

If so do:
SELECT image_guid from vm_images_view where imagestatus=2;
# Get the guid returned and then
Update images SET imagestatus=1 where image_guid = {The guid which
returned in the last query}


Thanks.
> M.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/74QMVFTM356GHFIHWPUKMIZLIRDOPYHT/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HV2ZJ34JWFGGSGFBH6ULJ46R4FCQICAJ/

[ovirt-users] Re: ovirt 4.3 cannot upload ISO to data domain

[Alex K]

On Tue, Nov 24, 2020 at 12:44 PM Facundo Badaracco 
wrote:

> hi alex!
>
> imageio-proxy isnt installed. Only ovirt-imageio service is running.
> (ovirt 4.4 now, i made the update)
>
If I run the following I get:
[root@engine ~]# systemctl | grep image
  ovirt-imageio-proxy.service
Then checking the status of the service I confirm it is up:
  systemctl status ovirt-imageio-proxy.service
If the service is up and ok then you need to check the certificate issue. I
had noticed some times that importing the cert form GUI had not resolved
the issue. You may try to manually get the CA cert from engine
(/etc/pki/ovirt-engine/ca.pem) and import it at your browser. Clean cache
at browser and try again. The browser should indicate the connection is
trusted and secure. Also, you might need to remove the already imported
cert from your browser.


> when i connecto to the web UI, it say the certificate is not valid. with a
> red warning. but, i have already added the certificate to chrome
>
> El mar, 24 de nov. de 2020 a la(s) 07:22, Alex K (rightkickt...@gmail.com)
> escribió:
>
>>
>>
>> On Mon, Nov 23, 2020 at 4:43 PM Facundo Badaracco 
>> wrote:
>>
>>> Hi everyone.
>>>
>>> Im trying to upload a ISO to my data domain, the GUI gives me this error
>>> "Connection to ovirt-imageio service has failed. Ensure that ovirt-engine
>>> certificate
>>> <https://192.168.2.27/ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA>
>>>  is
>>> registered as a valid CA in the browser.".
>>>
>> is the imageio service running ok?  At engine: systemctl status
>> ovirt-imageio-proxy
>> Also, when connecting at the engine web UI, is the browser happy with the
>> certificate of the UI?
>>
>>>
>>> the image fails whne trying to upload.
>>>
>>> i have added the certificate in chrome, but inst working.
>>>
>>> Some help? any other way to upload?
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/47YYPUF3NA2SHO2ZL4JAPKULUCMH6JK4/
>>>
>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KOO32KJSJCCQEQKA2TLFZ5G26C3TO6WC/

[ovirt-users] Re: Fix corrupt self-hosted engine

[Alex K]

On Mon, Nov 23, 2020 at 10:09 AM Yedidyah Bar David  wrote:

> On Mon, Nov 23, 2020 at 9:54 AM Alex K  wrote:
> >
> >
> >
> > On Sun, Nov 22, 2020 at 8:57 AM Yedidyah Bar David 
> wrote:
> >>
> >> On Thu, Nov 19, 2020 at 9:43 PM Alex K  wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Nov 19, 2020 at 5:31 PM Alex K 
> wrote:
> >>>>
> >>>> Hi Didi,
> >>>>
> >>>> On Thu, Nov 19, 2020 at 5:13 PM Yedidyah Bar David 
> wrote:
> >>>>>
> >>>>> On Thu, Nov 19, 2020 at 4:37 PM Alex K 
> wrote:
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I have a corrupt self-hosted engine (with several file system
> errors, postgres not able to start) and thus it does not give access to the
> web UI. This happened following an unlucky split brain resolution (I am
> running 2 nodes). The two hosts are running VMs also which I would like to
> keep running as they are needed.
> >>>>>>
> >>>>>> When trying to boot into rescue mode (using
> systemd.unit=emergency.target boot parameter) I get a cursor and nothing
> else.
> >>>>>
> >>>>>
> >>>>> This means that more than just the DB is corrupt...
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> I have backups of engine files with scope all (using the
> engine-backup tool).
> >>>>>> What is the best approach to try and fix the engine or redeploy.
> >>>>>
> >>>>>
> >>>>> If you are careful, and know what you are doing, you can try
> something like the following. I am not giving many details, hopefully you
> can find on the net tutorials about how to use the things I suggest:
> >>>>>
> >>>>> 1. Move to global maintenance
> >>>>>
> >>>>> 2. Stop the current dead vm (if needed)
> >>>>>
> >>>>> 3. Find current vm conf, edit it to boot from a rescue iso image of
> your preference or from net/PXE etc., and start the vm with '--vm-conf'
> pointing to your edited file.
> >>>>>
> >>>>> 4. Connect a console (hosted-engine --console, or 'virsh console',
> or use '--add-console-password' and remote viewer, if needed)
> >>>>>
> >>>>> 5. Clean the disk and install the OS, oVirt, etc.
> >>>>>
> >>>>> 6. Copy your backup into the vm and restore with engine-backup
> >>>>>
> >>>>> 7. Then cleanly stop the machine, exit global maint, and let HA
> start it (or start it yourself with --vm-start).
> >>>>>
> >>>>> At the time, we had a bug [1] to document this. The result is [2].
> It does not detail how to boot/reinstall os/etc., only restore (if e.g. db
> is dead but fs is ok).
> >>>>> For something somewhat similar to what you want, see also [3], which
> uses guestfish. Might be useful, depending on how badly your disk is
> corrupted.
> >>>>
> >>>> I went with the guestfish approach. It has fixed some fs issues and
> now the yum etc seem fine apart from postgres.
> >>>> I had tried previously to uninstall/install packages so I ended
> installing them again with yum install ovirt\*setup\*.
> >>>> Now I think I have to run engine-setup but I get the error:
> >>>>
> >>>>  Failed to execute stage 'Environment setup': Cannot connect to
> Engine database using existing credentials: engine@localhost:5432
> >>>
> >>> Seems that I need to have psql running to be able to run engine-backup
> --mode=restore. Are there any steps how one could manually prepare pgsql
> for ovirt so as to attempt restoration?
> >>
> >>
> >> Replying again, also to conclude this part of your episode: Generally
> speaking, that's not needed. restore --provision-all-databases should do
> that for you.
> >
> > Seems that when pgsql is down nothing can be done. You need at least
> pgsql up and running (e clean state will do) so as to be able to proceed
> with restoration.
>
> Do you still have logs from this? Both engine-backup's (default to
> /var/log/ovirt-engine-backup/something if you do not pass --log) and
> ovirt-engine-provisiondb which it runs (at
> /var/log/ovirt-engine/setup).
>
I was using --provision-all-databases flag when trying to restore. I might
retest to double check. When the pg

[ovirt-users] Re: ovirt 4.3 cannot upload ISO to data domain

[Alex K]

On Mon, Nov 23, 2020 at 4:43 PM Facundo Badaracco 
wrote:

> Hi everyone.
>
> Im trying to upload a ISO to my data domain, the GUI gives me this error 
> "Connection
> to ovirt-imageio service has failed. Ensure that ovirt-engine certificate
> 
>  is
> registered as a valid CA in the browser.".
>
is the imageio service running ok?  At engine: systemctl status
ovirt-imageio-proxy
Also, when connecting at the engine web UI, is the browser happy with the
certificate of the UI?

>
> the image fails whne trying to upload.
>
> i have added the certificate in chrome, but inst working.
>
> Some help? any other way to upload?
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/47YYPUF3NA2SHO2ZL4JAPKULUCMH6JK4/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YZGGJMCM76MLESWAQRD6BZDTTQV6BLGZ/

[ovirt-users] Re: bond or different networks for frontend and backend

[Alex K]

On Tue, Nov 24, 2020 at 10:40 AM jb  wrote:

> Hello,
>
> here in the description
> (
> https://www.ovirt.org/documentation/gluster-hyperconverged/chap-Single_node_hyperconverged.html)
>
> it says that we should have at least 2 interfaces to separate frontend
> and backend traffic.
>
> How is this when I have 4 nics and I make with all one bond interface,
> is this not better in terms of performance? What is your recommendation
> with 4 x 1Gbit nics?
>
In terms of performance and stability, it is better to assign one NIC for
ovirtmgmt (frontend web, management net) + 3 nics in bond for the gluster
storage network. You could also assign the migration network at same bond.
Though I personally prefer to not mix gluster net with migration.

>
> Best regards
>
> Jonathan
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/P5ZLQLG2TZN56IWZ5HC4ZDST66H5DHLO/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5RHYMKE4JSMZF4U4GK2JWUAIBYYCLM2C/

[ovirt-users] Re: Replacing ovirt certificates issue

[Alex K]

On Mon, Nov 23, 2020 at 4:54 PM Alex K  wrote:

>
>
> On Mon, Nov 23, 2020 at 9:42 AM Alex K  wrote:
>
>>
>>
>> On Mon, Nov 23, 2020 at 9:35 AM Dominik Holler 
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 20, 2020 at 12:38 PM Alex K  wrote:
>>>
>>>> Following the above, I was seeing that OVN provider connectivity test
>>>> was failing due to some certificate issue and had to do the following to
>>>> fix it:
>>>>
>>>> names="ovirt-provider-ovn"
>>>>
>>>> subject="$(\
>>>> openssl x509 \
>>>> -in /etc/pki/ovirt-engine/certs/apache.cer \
>>>> -noout \
>>>> -subject | \
>>>> sed \
>>>> 's;subject= \(.*\);\1;'
>>>>   )"
>>>>
>>>> . /usr/share/ovirt-engine/bin/engine-prolog.sh
>>>>
>>>> for name in $names; do
>>>> /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
>>>> --name="${name}" \
>>>> --password=mypass \
>>>> --subject="${subject}" \
>>>> --keep-key \
>>>> --san=DNS:"${ENGINE_FQDN}"
>>>> done
>>>>
>>>> Having fixed the above, when trying to connect two VMs on some OVN
>>>> logical switches it seems they are not able to reach each other.
>>>> I had previously added such logical switched at engine by running:
>>>>
>>>> ovn-nbctl ls-add ovn-net0
>>>> ovn-nbctl ls-add ovn-net1
>>>> etc
>>>>
>>>>
>>> Not related: Please use ovirt-provider-ovn to create and manage ovn
>>> entities.
>>>
>>>
>>>> Checking the logs at the host /var/log/openvswitch/ovsdb-server.log I
>>>> see:
>>>> reconnect|WARN|unix#45: connection dropped (Connection reset by peer)
>>>>
>>>>
>>> /var/log/openvswitch/ovn-controller.log might contain the reason.
>>>
>>>
>>>> Also systemctl status ovirt-provider-ovn.service at engine shows:
>>>> /usr/lib/python2.7/site-packages/urllib3/connection.py:344:
>>>> SubjectAltNameWarning:...
>>>>
>>>>
>>> Looks not good, do tou know which connection this warning referes to?
>>>
>>>
>>>> I have restarted at engine both engine and ovn services:
>>>> systemctl restart ovirt-engine
>>>> systemctl status ovirt-provider-ovn.service
>>>>
>>>> I have also restarted the relevant service at each host:
>>>> systemctl restart ovn-controller.service
>>>>
>>>> When running at host the following it stucks and does not give any
>>>> output:
>>>> ovn-sbctl show
>>>>
>>>>
>>> This is expected, the ovn southbound and northbound db exists only on
>>> the ovn-central, which is places on the same machine as oVirt Engine.
>>> Only the ovn-controller, which controls openvswitch, and openvswitch,
>>> which is implementing the data plane, is placed on the ovn-chassis / oVirt
>>> host.
>>>
>>>
>>>> I see that the certificate is imported at key-store as it has the same
>>>> fingerprint with the previous root CA:
>>>>
>>>> keytool -list -alias ovirt-provider-ovn -keystore
>>>> /var/lib/ovirt-engine/external_truststore
>>>>
>>>>
>>> This is only relevant for the connection from oVirt Engine to
>>> ovirt-provider-ovn.
>>>
>>>
>>>> At this same cluster, I had previously changed the domain name of each
>>>> host and engine using the rename tool.
>>>> And now replaced the certificates as per previous described so as to
>>>> fix the imageio cert issue and ovn issue.
>>>>
>>>> It seems that OVN is not happy with the status of certificates.
>>>> When testing connection at engine GUI i get a prompt to trust the cert,
>>>> and when pressing ok i get a green confirmation of successful connection.
>>>>
>>>>
>>> This is only relevant for the connection from oVirt Engine to
>>> ovirt-provider-ovn. The prompt to trust the certificate might be redundant.
>>> If you get the green confirmation, oVirt Engine is happy and the
>>> certificate of the REST API of ovirt-provider-ovn is fine.
>>>
>>>
>>>> Is there anything else t

[ovirt-users] Re: Replacing ovirt certificates issue

[Alex K]

On Mon, Nov 23, 2020 at 9:42 AM Alex K  wrote:

>
>
> On Mon, Nov 23, 2020 at 9:35 AM Dominik Holler  wrote:
>
>>
>>
>> On Fri, Nov 20, 2020 at 12:38 PM Alex K  wrote:
>>
>>> Following the above, I was seeing that OVN provider connectivity test
>>> was failing due to some certificate issue and had to do the following to
>>> fix it:
>>>
>>> names="ovirt-provider-ovn"
>>>
>>> subject="$(\
>>> openssl x509 \
>>> -in /etc/pki/ovirt-engine/certs/apache.cer \
>>> -noout \
>>> -subject | \
>>> sed \
>>> 's;subject= \(.*\);\1;'
>>>   )"
>>>
>>> . /usr/share/ovirt-engine/bin/engine-prolog.sh
>>>
>>> for name in $names; do
>>> /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
>>> --name="${name}" \
>>> --password=mypass \
>>> --subject="${subject}" \
>>> --keep-key \
>>> --san=DNS:"${ENGINE_FQDN}"
>>> done
>>>
>>> Having fixed the above, when trying to connect two VMs on some OVN
>>> logical switches it seems they are not able to reach each other.
>>> I had previously added such logical switched at engine by running:
>>>
>>> ovn-nbctl ls-add ovn-net0
>>> ovn-nbctl ls-add ovn-net1
>>> etc
>>>
>>>
>> Not related: Please use ovirt-provider-ovn to create and manage ovn
>> entities.
>>
>>
>>> Checking the logs at the host /var/log/openvswitch/ovsdb-server.log I
>>> see:
>>> reconnect|WARN|unix#45: connection dropped (Connection reset by peer)
>>>
>>>
>> /var/log/openvswitch/ovn-controller.log might contain the reason.
>>
>>
>>> Also systemctl status ovirt-provider-ovn.service at engine shows:
>>> /usr/lib/python2.7/site-packages/urllib3/connection.py:344:
>>> SubjectAltNameWarning:...
>>>
>>>
>> Looks not good, do tou know which connection this warning referes to?
>>
>>
>>> I have restarted at engine both engine and ovn services:
>>> systemctl restart ovirt-engine
>>> systemctl status ovirt-provider-ovn.service
>>>
>>> I have also restarted the relevant service at each host:
>>> systemctl restart ovn-controller.service
>>>
>>> When running at host the following it stucks and does not give any
>>> output:
>>> ovn-sbctl show
>>>
>>>
>> This is expected, the ovn southbound and northbound db exists only on the
>> ovn-central, which is places on the same machine as oVirt Engine.
>> Only the ovn-controller, which controls openvswitch, and openvswitch,
>> which is implementing the data plane, is placed on the ovn-chassis / oVirt
>> host.
>>
>>
>>> I see that the certificate is imported at key-store as it has the same
>>> fingerprint with the previous root CA:
>>>
>>> keytool -list -alias ovirt-provider-ovn -keystore
>>> /var/lib/ovirt-engine/external_truststore
>>>
>>>
>> This is only relevant for the connection from oVirt Engine to
>> ovirt-provider-ovn.
>>
>>
>>> At this same cluster, I had previously changed the domain name of each
>>> host and engine using the rename tool.
>>> And now replaced the certificates as per previous described so as to fix
>>> the imageio cert issue and ovn issue.
>>>
>>> It seems that OVN is not happy with the status of certificates.
>>> When testing connection at engine GUI i get a prompt to trust the cert,
>>> and when pressing ok i get a green confirmation of successful connection.
>>>
>>>
>> This is only relevant for the connection from oVirt Engine to
>> ovirt-provider-ovn. The prompt to trust the certificate might be redundant.
>> If you get the green confirmation, oVirt Engine is happy and the
>> certificate of the REST API of ovirt-provider-ovn is fine.
>>
>>
>>> Is there anything else that can be done to fix OVN functionality?
>>>
>>
>> Please try to understand what is wrong in the connection between
>> ovn-controller and ovn south bound db.
>> /var/log/openvswitch/ovn-controller.log should be helpful and might
>> contain the reason.
>>
> Will run the steps again to see. Do you think I need to take additional
> steps when fixing the OVN certs issue due to domain change that this
> cluster has undergone?
>
This time was not able to make OVN provide

[ovirt-users] Re: Replacing ovirt certificates issue

[Alex K]

On Mon, Nov 23, 2020 at 9:35 AM Dominik Holler  wrote:

>
>
> On Fri, Nov 20, 2020 at 12:38 PM Alex K  wrote:
>
>> Following the above, I was seeing that OVN provider connectivity test was
>> failing due to some certificate issue and had to do the following to fix
>> it:
>>
>> names="ovirt-provider-ovn"
>>
>> subject="$(\
>> openssl x509 \
>> -in /etc/pki/ovirt-engine/certs/apache.cer \
>> -noout \
>> -subject | \
>> sed \
>> 's;subject= \(.*\);\1;'
>>   )"
>>
>> . /usr/share/ovirt-engine/bin/engine-prolog.sh
>>
>> for name in $names; do
>> /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
>> --name="${name}" \
>> --password=mypass \
>> --subject="${subject}" \
>> --keep-key \
>> --san=DNS:"${ENGINE_FQDN}"
>> done
>>
>> Having fixed the above, when trying to connect two VMs on some OVN
>> logical switches it seems they are not able to reach each other.
>> I had previously added such logical switched at engine by running:
>>
>> ovn-nbctl ls-add ovn-net0
>> ovn-nbctl ls-add ovn-net1
>> etc
>>
>>
> Not related: Please use ovirt-provider-ovn to create and manage ovn
> entities.
>
>
>> Checking the logs at the host /var/log/openvswitch/ovsdb-server.log I
>> see:
>> reconnect|WARN|unix#45: connection dropped (Connection reset by peer)
>>
>>
> /var/log/openvswitch/ovn-controller.log might contain the reason.
>
>
>> Also systemctl status ovirt-provider-ovn.service at engine shows:
>> /usr/lib/python2.7/site-packages/urllib3/connection.py:344:
>> SubjectAltNameWarning:...
>>
>>
> Looks not good, do tou know which connection this warning referes to?
>
>
>> I have restarted at engine both engine and ovn services:
>> systemctl restart ovirt-engine
>> systemctl status ovirt-provider-ovn.service
>>
>> I have also restarted the relevant service at each host:
>> systemctl restart ovn-controller.service
>>
>> When running at host the following it stucks and does not give any output:
>> ovn-sbctl show
>>
>>
> This is expected, the ovn southbound and northbound db exists only on the
> ovn-central, which is places on the same machine as oVirt Engine.
> Only the ovn-controller, which controls openvswitch, and openvswitch,
> which is implementing the data plane, is placed on the ovn-chassis / oVirt
> host.
>
>
>> I see that the certificate is imported at key-store as it has the same
>> fingerprint with the previous root CA:
>>
>> keytool -list -alias ovirt-provider-ovn -keystore
>> /var/lib/ovirt-engine/external_truststore
>>
>>
> This is only relevant for the connection from oVirt Engine to
> ovirt-provider-ovn.
>
>
>> At this same cluster, I had previously changed the domain name of each
>> host and engine using the rename tool.
>> And now replaced the certificates as per previous described so as to fix
>> the imageio cert issue and ovn issue.
>>
>> It seems that OVN is not happy with the status of certificates.
>> When testing connection at engine GUI i get a prompt to trust the cert,
>> and when pressing ok i get a green confirmation of successful connection.
>>
>>
> This is only relevant for the connection from oVirt Engine to
> ovirt-provider-ovn. The prompt to trust the certificate might be redundant.
> If you get the green confirmation, oVirt Engine is happy and the
> certificate of the REST API of ovirt-provider-ovn is fine.
>
>
>> Is there anything else that can be done to fix OVN functionality?
>>
>
> Please try to understand what is wrong in the connection between
> ovn-controller and ovn south bound db.
> /var/log/openvswitch/ovn-controller.log should be helpful and might
> contain the reason.
>
Will run the steps again to see. Do you think I need to take additional
steps when fixing the OVN certs issue due to domain change that this
cluster has undergone?

>
>
>
>> Thanx
>> Alex
>>
>>
>>
>>
>>
>> On Thu, Nov 19, 2020 at 9:00 AM Alex K  wrote:
>>
>>> Seems that all services (imageio, ovn, web socket) are fine after
>>> following the above and importing the new self signed CA certificate.
>>> DId run also engine-setup as I was trying to fix the imageio cert issue,
>>> though seems that that was only fixed after importing the CA cert at
>>> browser and engine-setup might not be needed.
>>>
>>> On Wed, Nov 1

[ovirt-users] Re: Fix corrupt self-hosted engine

[Alex K]

On Sun, Nov 22, 2020 at 8:57 AM Yedidyah Bar David  wrote:

> On Thu, Nov 19, 2020 at 9:43 PM Alex K  wrote:
>
>>
>>
>> On Thu, Nov 19, 2020 at 5:31 PM Alex K  wrote:
>>
>>> Hi Didi,
>>>
>>> On Thu, Nov 19, 2020 at 5:13 PM Yedidyah Bar David 
>>> wrote:
>>>
>>>> On Thu, Nov 19, 2020 at 4:37 PM Alex K  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have a corrupt self-hosted engine (with several file system errors,
>>>>> postgres not able to start) and thus it does not give access to the web 
>>>>> UI.
>>>>> This happened following an unlucky split brain resolution (I am running 2
>>>>> nodes). The two hosts are running VMs also which I would like to keep
>>>>> running as they are needed.
>>>>>
>>>>> When trying to boot into rescue mode (using
>>>>> systemd.unit=emergency.target boot parameter) I get a cursor and nothing
>>>>> else.
>>>>>
>>>>
>>>> This means that more than just the DB is corrupt...
>>>>
>>>>
>>>>>
>>>>> I have backups of engine files with scope all (using the engine-backup
>>>>> tool).
>>>>> What is the best approach to try and fix the engine or redeploy.
>>>>>
>>>>
>>>> If you are careful, and know what you are doing, you can try something
>>>> like the following. I am not giving many details, hopefully you can find on
>>>> the net tutorials about how to use the things I suggest:
>>>>
>>>> 1. Move to global maintenance
>>>>
>>>> 2. Stop the current dead vm (if needed)
>>>>
>>>> 3. Find current vm conf, edit it to boot from a rescue iso image of
>>>> your preference or from net/PXE etc., and start the vm with '--vm-conf'
>>>> pointing to your edited file.
>>>>
>>>> 4. Connect a console (hosted-engine --console, or 'virsh console', or
>>>> use '--add-console-password' and remote viewer, if needed)
>>>>
>>>> 5. Clean the disk and install the OS, oVirt, etc.
>>>>
>>>> 6. Copy your backup into the vm and restore with engine-backup
>>>>
>>>> 7. Then cleanly stop the machine, exit global maint, and let HA start
>>>> it (or start it yourself with --vm-start).
>>>>
>>>> At the time, we had a bug [1] to document this. The result is [2]. It
>>>> does not detail how to boot/reinstall os/etc., only restore (if e.g. db is
>>>> dead but fs is ok).
>>>> For something somewhat similar to what you want, see also [3], which
>>>> uses guestfish. Might be useful, depending on how badly your disk is
>>>> corrupted.
>>>>
>>> I went with the guestfish approach. It has fixed some fs issues and now
>>> the yum etc seem fine apart from postgres.
>>> I had tried previously to uninstall/install packages so I ended
>>> installing them again with yum install ovirt\*setup\*.
>>> Now I think I have to run engine-setup but I get the error:
>>>
>>>  Failed to execute stage 'Environment setup': Cannot connect to Engine
>>> database using existing credentials: engine@localhost:5432
>>>
>> Seems that I need to have psql running to be able to run engine-backup
>> --mode=restore. Are there any steps how one could manually prepare pgsql
>> for ovirt so as to attempt restoration?
>>
>
> Replying again, also to conclude this part of your episode: Generally
> speaking, that's not needed. restore --provision-all-databases should do
> that for you.
>
Seems that when pgsql is down nothing can be done. You need at least pgsql
up and running (e clean state will do) so as to be able to proceed with
restoration.

>
> I replied to all your interim emails in private, since you replied in
> private.
>
Did not notice I was replying in private :)

>
> Thanks for the final message to the list.
>
> It would be nice if you send another summary of the main obstacles you ran
> into, what worked and didn't work, and especially what ideas you can think
> of to improve the code/doc for the next time something similar happens
> (also to you :-) ).
>
> If you feel like that, and have time, it sounds like a nice opportunity
> for a blog post :-) (I know I (almost?) never wrote any myself, sorry, but
> I like reading them - and they are much more approachable and useful, over
> the long run, compared to just posting to the list)

[ovirt-users] Re: Replacing ovirt certificates issue

[Alex K]

On Sun, Nov 22, 2020 at 9:11 AM Yedidyah Bar David  wrote:

> On Fri, Nov 20, 2020 at 1:37 PM Alex K  wrote:
>
>> Following the above, I was seeing that OVN provider connectivity test was
>> failing due to some certificate issue and had to do the following to fix
>> it:
>>
>
> Is this on the same systems of "[ovirt-users] Fix corrupt self-hosted
> engine", or unrelated?
>
Yes, it is the same one.

>
>
>>
>> names="ovirt-provider-ovn"
>>
>> subject="$(\
>> openssl x509 \
>> -in /etc/pki/ovirt-engine/certs/apache.cer \
>> -noout \
>> -subject | \
>> sed \
>> 's;subject= \(.*\);\1;'
>>   )"
>>
>> . /usr/share/ovirt-engine/bin/engine-prolog.sh
>>
>> for name in $names; do
>> /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
>> --name="${name}" \
>> --password=mypass \
>> --subject="${subject}" \
>> --keep-key \
>> --san=DNS:"${ENGINE_FQDN}"
>> done
>>
>> Having fixed the above, when trying to connect two VMs on some OVN
>> logical switches it seems they are not able to reach each other.
>> I had previously added such logical switched at engine by running:
>>
>> ovn-nbctl ls-add ovn-net0
>> ovn-nbctl ls-add ovn-net1
>> etc
>>
>> Checking the logs at the host /var/log/openvswitch/ovsdb-server.log I
>> see:
>> reconnect|WARN|unix#45: connection dropped (Connection reset by peer)
>>
>> Also systemctl status ovirt-provider-ovn.service at engine shows:
>> /usr/lib/python2.7/site-packages/urllib3/connection.py:344:
>> SubjectAltNameWarning:...
>>
>> I have restarted at engine both engine and ovn services:
>> systemctl restart ovirt-engine
>> systemctl status ovirt-provider-ovn.service
>>
>> I have also restarted the relevant service at each host:
>> systemctl restart ovn-controller.service
>>
>> When running at host the following it stucks and does not give any output:
>> ovn-sbctl show
>>
>> I see that the certificate is imported at key-store as it has the same
>> fingerprint with the previous root CA:
>>
>> keytool -list -alias ovirt-provider-ovn -keystore
>> /var/lib/ovirt-engine/external_truststore
>>
>> At this same cluster, I had previously changed the domain name of each
>> host and engine using the rename tool.
>>
>
> After that, did ovn still work well?
>
No. When clicking at the "test" button, I am prompted to accept self signed
cert and then I receive a green check confirmation that all is good but
when attaching two guest net ports on same OVN logicat switch the VMs are
not able to communicate and was observing some SSL issues at  OVN logs
referring to subjAltName issues.

>
>
>> And now replaced the certificates as per previous described so as to fix
>> the imageio cert issue and ovn issue.
>>
>> It seems that OVN is not happy with the status of certificates.
>> When testing connection at engine GUI i get a prompt to trust the cert,
>> and when pressing ok i get a green confirmation of successful connection.
>>
>> Is there anything else that can be done to fix OVN functionality?
>>
>
> No idea, adding Dominik.
>
The cluster I am trying to fix was renamed at a previous point. I had to
change the domain where the hosts and the engine belonged. Did that, with
few hurdles (using the rename tool available at 4.3). That procedure left
out the omageio and OVN certs which I want to resolve now as I need OVN to
be able to setup test environment.

I checked also https://bugzilla.redhat.com/show_bug.cgi?id=1501798, and
proceeded to generate new certs for ovn-ndb and ovn-sdb. Following this,
and after running engine-setup I observed that the host had to be
re-installed as per web UI prompt. I tried to, but host installation was
not being completed due to "General SSLEngine problem". Tried also to renew
the vdsm certs at the host, using same vdsm key and the new CA cert, but
without luck. At that point I was receiving "Get Host Capabilities failed:
Received fatal alert: unknown_ca" and the other host also became
no-responsive. Generally I tried several things (even renewing at engine
the engine.cer cert using the engine_id_rsa key at engine) but the host was
refusing to install. So it seems that when a domain change is involved in
the scenario, I have to include some additional steps to make the setup
happy.

I had to roll-back the pki at its previous state so as to recover one host
and re-install the other, as the site is production.

I have read that this the engine rename tool at 

[ovirt-users] Re: Replacing ovirt certificates issue

[Alex K]

Following the above, I was seeing that OVN provider connectivity test was
failing due to some certificate issue and had to do the following to fix
it:

names="ovirt-provider-ovn"

subject="$(\
openssl x509 \
-in /etc/pki/ovirt-engine/certs/apache.cer \
-noout \
-subject | \
sed \
's;subject= \(.*\);\1;'
  )"

. /usr/share/ovirt-engine/bin/engine-prolog.sh

for name in $names; do
/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
--name="${name}" \
--password=mypass \
--subject="${subject}" \
--keep-key \
--san=DNS:"${ENGINE_FQDN}"
done

Having fixed the above, when trying to connect two VMs on some OVN logical
switches it seems they are not able to reach each other.
I had previously added such logical switched at engine by running:

ovn-nbctl ls-add ovn-net0
ovn-nbctl ls-add ovn-net1
etc

Checking the logs at the host /var/log/openvswitch/ovsdb-server.log I see:
reconnect|WARN|unix#45: connection dropped (Connection reset by peer)

Also systemctl status ovirt-provider-ovn.service at engine shows:
/usr/lib/python2.7/site-packages/urllib3/connection.py:344:
SubjectAltNameWarning:...

I have restarted at engine both engine and ovn services:
systemctl restart ovirt-engine
systemctl status ovirt-provider-ovn.service

I have also restarted the relevant service at each host:
systemctl restart ovn-controller.service

When running at host the following it stucks and does not give any output:
ovn-sbctl show

I see that the certificate is imported at key-store as it has the same
fingerprint with the previous root CA:

keytool -list -alias ovirt-provider-ovn -keystore
/var/lib/ovirt-engine/external_truststore

At this same cluster, I had previously changed the domain name of each host
and engine using the rename tool.
And now replaced the certificates as per previous described so as to fix
the imageio cert issue and ovn issue.

It seems that OVN is not happy with the status of certificates.
When testing connection at engine GUI i get a prompt to trust the cert, and
when pressing ok i get a green confirmation of successful connection.

Is there anything else that can be done to fix OVN functionality?
Thanx
Alex





On Thu, Nov 19, 2020 at 9:00 AM Alex K  wrote:

> Seems that all services (imageio, ovn, web socket) are fine after
> following the above and importing the new self signed CA certificate.
> DId run also engine-setup as I was trying to fix the imageio cert issue,
> though seems that that was only fixed after importing the CA cert at
> browser and engine-setup might not be needed.
>
> On Wed, Nov 18, 2020 at 3:07 PM Alex K  wrote:
>
>> Seems I had a typo at
>> /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf.
>> I will repeat the test to verify that all services are functional
>> following this process.
>>
>> On Wed, Nov 18, 2020 at 10:24 AM Alex K  wrote:
>>
>>> Hi all,
>>>
>>> I am trying to replace the ovirt certificate at ovirt 4.3 following
>>> this:
>>>
>>>
>>> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl
>>>
>>> I am doing the following:
>>> I have engine FQDN: manager.lab.local
>>>
>>> 1. Create root CA private key:
>>> openssl genrsa -des3 -out root.key 2048
>>>
>>> 2. Generate root certificate: (enter passphrase of root key)
>>> openssl req -x509 -new -nodes -key root.key -sha256 -days 3650 -out
>>> root.pem
>>> cp root.pem /tmp
>>>
>>> 3. Create key and CSR for engine:
>>> openssl genrsa -out manager.lab.local.key 2048
>>> openssl req -new -out manager.lab.local.csr -key manager.lab.local.key
>>>
>>> 4. Generate a certificate for engine and sign with the root CA key:
>>>
>>> openssl x509 -req -in manager.lab.local.csr \
>>> -CA root.pem \
>>> -CAkey root.key \
>>> -CAcreateserial \
>>> -out manager.lab.local.crt \
>>> -days 3650 \
>>> -sha256 \
>>> -extensions v3_req
>>>
>>> 5. Verify the trust chain and check the certificate details:
>>> openssl verify -CAfile root.pem manager.lab.local.crt
>>> openssl x509 -text -noout -in  manager.lab.local.crt  | head -15
>>>
>>> 6. Generate a P12 container: (with empty password)
>>> openssl pkcs12 -export -out /tmp/apache.p12 \
>>> -inkey manager.lab.local.key \
>>> -in manager.lab.local.crt
>>>
>>> 8. Export key and cert:
>>> openssl pkcs12 -in apache.p12 -nocerts -nodes > /tmp/apache.key
>>> openssl pkcs12 -in apache.p12 -nokeys > /tmp/apach

[ovirt-users] Re: Fix corrupt self-hosted engine

[Alex K]

For the records,

After having fixed the major fs issues with guestfish and since the DB was
not starting up, I removed everything from DB data dir and recreated it as
below:

rm -rf /var/opt/rh/rh-postgresql10/lib/pgsql/data/*
/opt/rh/rh-postgresql10/root/usr/bin/postgresql-setup --initdb
systemctl restart rh-postgresql10-postgresql.service

Then proceeded with the restoration, where I requested to provision all
missing databases:
engine-backup --mode=restore --file=engine-backup.gz
--provision-all-databases \
--log=restore.log --restore-permissions

Following this, ran engine-setup, as instructed from the restore operation.
Gained engine web access and saw the same running VMs were shown as up
without issues.
I only observed one VM not able to start due to illegal volume, but that's
another story.


On Thu, Nov 19, 2020 at 9:42 PM Alex K  wrote:

>
>
> On Thu, Nov 19, 2020 at 5:31 PM Alex K  wrote:
>
>> Hi Didi,
>>
>> On Thu, Nov 19, 2020 at 5:13 PM Yedidyah Bar David 
>> wrote:
>>
>>> On Thu, Nov 19, 2020 at 4:37 PM Alex K  wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have a corrupt self-hosted engine (with several file system errors,
>>>> postgres not able to start) and thus it does not give access to the web UI.
>>>> This happened following an unlucky split brain resolution (I am running 2
>>>> nodes). The two hosts are running VMs also which I would like to keep
>>>> running as they are needed.
>>>>
>>>> When trying to boot into rescue mode (using
>>>> systemd.unit=emergency.target boot parameter) I get a cursor and nothing
>>>> else.
>>>>
>>>
>>> This means that more than just the DB is corrupt...
>>>
>>>
>>>>
>>>> I have backups of engine files with scope all (using the engine-backup
>>>> tool).
>>>> What is the best approach to try and fix the engine or redeploy.
>>>>
>>>
>>> If you are careful, and know what you are doing, you can try something
>>> like the following. I am not giving many details, hopefully you can find on
>>> the net tutorials about how to use the things I suggest:
>>>
>>> 1. Move to global maintenance
>>>
>>> 2. Stop the current dead vm (if needed)
>>>
>>> 3. Find current vm conf, edit it to boot from a rescue iso image of your
>>> preference or from net/PXE etc., and start the vm with '--vm-conf' pointing
>>> to your edited file.
>>>
>>> 4. Connect a console (hosted-engine --console, or 'virsh console', or
>>> use '--add-console-password' and remote viewer, if needed)
>>>
>>> 5. Clean the disk and install the OS, oVirt, etc.
>>>
>>> 6. Copy your backup into the vm and restore with engine-backup
>>>
>>> 7. Then cleanly stop the machine, exit global maint, and let HA start it
>>> (or start it yourself with --vm-start).
>>>
>>> At the time, we had a bug [1] to document this. The result is [2]. It
>>> does not detail how to boot/reinstall os/etc., only restore (if e.g. db is
>>> dead but fs is ok).
>>> For something somewhat similar to what you want, see also [3], which
>>> uses guestfish. Might be useful, depending on how badly your disk is
>>> corrupted.
>>>
>> I went with the guestfish approach. It has fixed some fs issues and now
>> the yum etc seem fine apart from postgres.
>> I had tried previously to uninstall/install packages so I ended
>> installing them again with yum install ovirt\*setup\*.
>> Now I think I have to run engine-setup but I get the error:
>>
>>  Failed to execute stage 'Environment setup': Cannot connect to Engine
>> database using existing credentials: engine@localhost:5432
>>
> Seems that I need to have psql running to be able to run engine-backup
> --mode=restore. Are there any steps how one could manually prepare pgsql
> for ovirt so as to attempt restoration?
>
>>
>> So I guess I need to follow [2]. What do you think?
>>
>>
>>> How did you run into a split brain? There is a lock on the shared
>>> storage that should prevent this.
>>>
>>> Good luck and best regards,
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1482710
>>> [2]
>>> https://www.ovirt.org/documentation/administration_guide/#Overwriting_a_Self-Hosted_Engine
>>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1569827#c4
>>> --
>>> Didi
>>>
>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SU6V565Y5GAZ67FF5MUDGFLEJ2L2LZV7/

[ovirt-users] Fix corrupt self-hosted engine

[Alex K]

Hi all,

I have a corrupt self-hosted engine (with several file system errors,
postgres not able to start) and thus it does not give access to the web UI.
This happened following an unlucky split brain resolution (I am running 2
nodes). The two hosts are running VMs also which I would like to keep
running as they are needed.

When trying to boot into rescue mode (using systemd.unit=emergency.target
boot parameter) I get a cursor and nothing else.

I have backups of engine files with scope all (using the engine-backup
tool).
What is the best approach to try and fix the engine or redeploy.

Thanks for any help.
Alex
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/76ZY4BMBKGA5HFLLNDKACFD2EIBI3WVZ/

[ovirt-users] Re: Replacing ovirt certificates issue

[Alex K]

Seems that all services (imageio, ovn, web socket) are fine after following
the above and importing the new self signed CA certificate.
DId run also engine-setup as I was trying to fix the imageio cert issue,
though seems that that was only fixed after importing the CA cert at
browser and engine-setup might not be needed.

On Wed, Nov 18, 2020 at 3:07 PM Alex K  wrote:

> Seems I had a typo at
> /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf.
> I will repeat the test to verify that all services are functional
> following this process.
>
> On Wed, Nov 18, 2020 at 10:24 AM Alex K  wrote:
>
>> Hi all,
>>
>> I am trying to replace the ovirt certificate at ovirt 4.3 following this:
>>
>>
>> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl
>>
>> I am doing the following:
>> I have engine FQDN: manager.lab.local
>>
>> 1. Create root CA private key:
>> openssl genrsa -des3 -out root.key 2048
>>
>> 2. Generate root certificate: (enter passphrase of root key)
>> openssl req -x509 -new -nodes -key root.key -sha256 -days 3650 -out
>> root.pem
>> cp root.pem /tmp
>>
>> 3. Create key and CSR for engine:
>> openssl genrsa -out manager.lab.local.key 2048
>> openssl req -new -out manager.lab.local.csr -key manager.lab.local.key
>>
>> 4. Generate a certificate for engine and sign with the root CA key:
>>
>> openssl x509 -req -in manager.lab.local.csr \
>> -CA root.pem \
>> -CAkey root.key \
>> -CAcreateserial \
>> -out manager.lab.local.crt \
>> -days 3650 \
>> -sha256 \
>> -extensions v3_req
>>
>> 5. Verify the trust chain and check the certificate details:
>> openssl verify -CAfile root.pem manager.lab.local.crt
>> openssl x509 -text -noout -in  manager.lab.local.crt  | head -15
>>
>> 6. Generate a P12 container: (with empty password)
>> openssl pkcs12 -export -out /tmp/apache.p12 \
>> -inkey manager.lab.local.key \
>> -in manager.lab.local.crt
>>
>> 8. Export key and cert:
>> openssl pkcs12 -in apache.p12 -nocerts -nodes > /tmp/apache.key
>> openssl pkcs12 -in apache.p12 -nokeys > /tmp/apache.cer
>>
>> From the above steps we should have the following:
>>
>> /tmp/root.pem
>> /tmp/apache.p12
>> /tmp/apache.key
>> /tmp/apache.cer
>>
>> 9. Place the certificates:
>> hosted-engine --set-maintenance --mode=global
>> cp -p /etc/pki/ovirt-engine/keys/apache.p12 /tmp/apache.p12.bck
>> cp /tmp/apache.p12 /etc/pki/ovirt-engine/keys/apache.p12
>> cp /tmp/root.pem /etc/pki/ca-trust/source/anchors
>> update-ca-trust
>> rm /etc/pki/ovirt-engine/apache-ca.pem
>> cp /tmp/root.pem /etc/pki/ovirt-engine/apache-ca.pem
>>
>> Backup existing key and cert:
>> cp /etc/pki/ovirt-engine/keys/apache.key.nopass
>> /etc/pki/ovirt-engine/keys/apache.key.nopass.bck
>> cp /etc/pki/ovirt-engine/certs/apache.cer
>> /etc/pki/ovirt-engine/certs/apache.cer.bck
>> cp /tmp/apache.key /etc/pki/ovirt-engine/keys/apache.key.nopass
>> cp /tmp/apache.cer /etc/pki/ovirt-engine/certs/apache.cer
>> chown root:ovirt /etc/pki/ovirt-engine/keys/apache.key.nopass
>> chmod 640 /etc/pki/ovirt-engine/keys/apache.key.nopass
>> systemctl restart httpd.service
>>
>> 10. Create a new trust store configuration file:
>> vi /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf
>>
>> ENGINE_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts"
>> ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD=""
>>
>> 11. Edit /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf :
>> vi /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf
>>
>> SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
>> SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass
>>
>> 12. Edit /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf:
>> vi /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf
>>
>> # Key file for SSL connections
>> ssl_key_file = /etc/pki/ovirt-engine/keys/apache.key.nopass
>> # Certificate file for SSL connections
>> ssl_cert_file = /etc/pki/ovirt-engine/certs/apache.cer
>>
>> 13. Import the certificate at system-wide  java trust store
>>
>> update-ca-trust extract
>> keytool -list -alias ovirt -keystore /etc/pki/java/cacerts
>>
>> 14. Restart services:
>> systemctl restart httpd.service
>> systemctl restart ovirt-provider-ovn.service
>> systemctl restart ovirt-imageio-proxy
>> systemctl restart ovirt-webs

[ovirt-users] Re: How to create a backup in event of hardware failure of a single hosted engine?

[Alex K]

On Wed, Nov 18, 2020 at 1:40 PM  wrote:

> Hello Alex,
> How do i prepare the gluster volume as the gluster volume is also hosted
> on the 1st baremetal, can you elaborate this setup?
> just reading the docs of gluster must consists of 3 node either 3 gluster
> nodes or 2 gluster nodes + 1 arbiter on a replica set
>
Indeed, for production use, you need replica 3 gluster setup (either
replica 3 or 2 + 1 arbiter). In your case, you may go temporarily with a
replica 2 (two hosts) setup. In this case, it is best practise to dedicate
a separate network for the gluster traffic. Lets assume gluster0 and
gluster1 are the hostnames of each host at the gluster storage network and
the bricks are at /gluster/engine/brick. Then you need to run from gluster0
host:

gluster peer probe gluster1

gluster volume add-brick engine replica 2 gluster1:/gluster/engine/brick

In that case though you need to adjust quorum:

gluster volume set engine cluster.server-quorum-type none
gluster volume set engine cluster.quorum-type fixed
gluster volume set engine cluster.quorum-count 1

Repeat for each volume and wait for heal (sync to complete).
Check heal status of each volume:

gluster volume heal  info

I do not include all details here. I assume the existing gluster volumes
are already configured with the appropriate settings. As soon as you have
the replica 2 setup in place, you then can proceed with a replica 3 setup
with the same approach. Remember to enable quorum at each volume.
Hope that helps.

> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/MV2H6DNLD5JAKIEBFRQ4VROUYRHI2DMZ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OK7GRCKTT6T7XKJ5YGEIVBERYR5KZAAW/

[ovirt-users] Re: Replacing ovirt certificates issue

[Alex K]

Seems I had a typo at
/etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf.
I will repeat the test to verify that all services are functional following
this process.

On Wed, Nov 18, 2020 at 10:24 AM Alex K  wrote:

> Hi all,
>
> I am trying to replace the ovirt certificate at ovirt 4.3 following this:
>
>
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl
>
> I am doing the following:
> I have engine FQDN: manager.lab.local
>
> 1. Create root CA private key:
> openssl genrsa -des3 -out root.key 2048
>
> 2. Generate root certificate: (enter passphrase of root key)
> openssl req -x509 -new -nodes -key root.key -sha256 -days 3650 -out
> root.pem
> cp root.pem /tmp
>
> 3. Create key and CSR for engine:
> openssl genrsa -out manager.lab.local.key 2048
> openssl req -new -out manager.lab.local.csr -key manager.lab.local.key
>
> 4. Generate a certificate for engine and sign with the root CA key:
>
> openssl x509 -req -in manager.lab.local.csr \
> -CA root.pem \
> -CAkey root.key \
> -CAcreateserial \
> -out manager.lab.local.crt \
> -days 3650 \
> -sha256 \
> -extensions v3_req
>
> 5. Verify the trust chain and check the certificate details:
> openssl verify -CAfile root.pem manager.lab.local.crt
> openssl x509 -text -noout -in  manager.lab.local.crt  | head -15
>
> 6. Generate a P12 container: (with empty password)
> openssl pkcs12 -export -out /tmp/apache.p12 \
> -inkey manager.lab.local.key \
> -in manager.lab.local.crt
>
> 8. Export key and cert:
> openssl pkcs12 -in apache.p12 -nocerts -nodes > /tmp/apache.key
> openssl pkcs12 -in apache.p12 -nokeys > /tmp/apache.cer
>
> From the above steps we should have the following:
>
> /tmp/root.pem
> /tmp/apache.p12
> /tmp/apache.key
> /tmp/apache.cer
>
> 9. Place the certificates:
> hosted-engine --set-maintenance --mode=global
> cp -p /etc/pki/ovirt-engine/keys/apache.p12 /tmp/apache.p12.bck
> cp /tmp/apache.p12 /etc/pki/ovirt-engine/keys/apache.p12
> cp /tmp/root.pem /etc/pki/ca-trust/source/anchors
> update-ca-trust
> rm /etc/pki/ovirt-engine/apache-ca.pem
> cp /tmp/root.pem /etc/pki/ovirt-engine/apache-ca.pem
>
> Backup existing key and cert:
> cp /etc/pki/ovirt-engine/keys/apache.key.nopass
> /etc/pki/ovirt-engine/keys/apache.key.nopass.bck
> cp /etc/pki/ovirt-engine/certs/apache.cer
> /etc/pki/ovirt-engine/certs/apache.cer.bck
> cp /tmp/apache.key /etc/pki/ovirt-engine/keys/apache.key.nopass
> cp /tmp/apache.cer /etc/pki/ovirt-engine/certs/apache.cer
> chown root:ovirt /etc/pki/ovirt-engine/keys/apache.key.nopass
> chmod 640 /etc/pki/ovirt-engine/keys/apache.key.nopass
> systemctl restart httpd.service
>
> 10. Create a new trust store configuration file:
> vi /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf
>
> ENGINE_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts"
> ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD=""
>
> 11. Edit /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf :
> vi /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf
>
> SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
> SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass
>
> 12. Edit /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf:
> vi /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf
>
> # Key file for SSL connections
> ssl_key_file = /etc/pki/ovirt-engine/keys/apache.key.nopass
> # Certificate file for SSL connections
> ssl_cert_file = /etc/pki/ovirt-engine/certs/apache.cer
>
> 13. Import the certificate at system-wide  java trust store
>
> update-ca-trust extract
> keytool -list -alias ovirt -keystore /etc/pki/java/cacerts
>
> 14. Restart services:
> systemctl restart httpd.service
> systemctl restart ovirt-provider-ovn.service
> systemctl restart ovirt-imageio-proxy
> systemctl restart ovirt-websocket-proxy
> systemctl restart ovirt-engine.service
>
> Following the above I get at engine GUI:
>
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
>
> I have tried also to run engine-setup in case it could fix anything (it
> renewed the cert due to missing subjectAltName), and the above error still
> persists.
> I have tried several other suggestions from similar issues reported at
> this list without any luck.
> I have run out of ideas. Am I missing anything?
> Thanx for any suggestions.
> Alex
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NADGNIZR53ETECWMNTYN33DQJMOENHS7/

[ovirt-users] Replacing ovirt certificates issue

[Alex K]

Hi all,

I am trying to replace the ovirt certificate at ovirt 4.3 following this:

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl

I am doing the following:
I have engine FQDN: manager.lab.local

1. Create root CA private key:
openssl genrsa -des3 -out root.key 2048

2. Generate root certificate: (enter passphrase of root key)
openssl req -x509 -new -nodes -key root.key -sha256 -days 3650 -out root.pem
cp root.pem /tmp

3. Create key and CSR for engine:
openssl genrsa -out manager.lab.local.key 2048
openssl req -new -out manager.lab.local.csr -key manager.lab.local.key

4. Generate a certificate for engine and sign with the root CA key:

openssl x509 -req -in manager.lab.local.csr \
-CA root.pem \
-CAkey root.key \
-CAcreateserial \
-out manager.lab.local.crt \
-days 3650 \
-sha256 \
-extensions v3_req

5. Verify the trust chain and check the certificate details:
openssl verify -CAfile root.pem manager.lab.local.crt
openssl x509 -text -noout -in  manager.lab.local.crt  | head -15

6. Generate a P12 container: (with empty password)
openssl pkcs12 -export -out /tmp/apache.p12 \
-inkey manager.lab.local.key \
-in manager.lab.local.crt

8. Export key and cert:
openssl pkcs12 -in apache.p12 -nocerts -nodes > /tmp/apache.key
openssl pkcs12 -in apache.p12 -nokeys > /tmp/apache.cer

>From the above steps we should have the following:

/tmp/root.pem
/tmp/apache.p12
/tmp/apache.key
/tmp/apache.cer

9. Place the certificates:
hosted-engine --set-maintenance --mode=global
cp -p /etc/pki/ovirt-engine/keys/apache.p12 /tmp/apache.p12.bck
cp /tmp/apache.p12 /etc/pki/ovirt-engine/keys/apache.p12
cp /tmp/root.pem /etc/pki/ca-trust/source/anchors
update-ca-trust
rm /etc/pki/ovirt-engine/apache-ca.pem
cp /tmp/root.pem /etc/pki/ovirt-engine/apache-ca.pem

Backup existing key and cert:
cp /etc/pki/ovirt-engine/keys/apache.key.nopass
/etc/pki/ovirt-engine/keys/apache.key.nopass.bck
cp /etc/pki/ovirt-engine/certs/apache.cer
/etc/pki/ovirt-engine/certs/apache.cer.bck
cp /tmp/apache.key /etc/pki/ovirt-engine/keys/apache.key.nopass
cp /tmp/apache.cer /etc/pki/ovirt-engine/certs/apache.cer
chown root:ovirt /etc/pki/ovirt-engine/keys/apache.key.nopass
chmod 640 /etc/pki/ovirt-engine/keys/apache.key.nopass
systemctl restart httpd.service

10. Create a new trust store configuration file:
vi /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf

ENGINE_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts"
ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD=""

11. Edit /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf :
vi /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf

SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass

12. Edit /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf:
vi /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf

# Key file for SSL connections
ssl_key_file = /etc/pki/ovirt-engine/keys/apache.key.nopass
# Certificate file for SSL connections
ssl_cert_file = /etc/pki/ovirt-engine/certs/apache.cer

13. Import the certificate at system-wide  java trust store

update-ca-trust extract
keytool -list -alias ovirt -keystore /etc/pki/java/cacerts

14. Restart services:
systemctl restart httpd.service
systemctl restart ovirt-provider-ovn.service
systemctl restart ovirt-imageio-proxy
systemctl restart ovirt-websocket-proxy
systemctl restart ovirt-engine.service

Following the above I get at engine GUI:

sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target

I have tried also to run engine-setup in case it could fix anything (it
renewed the cert due to missing subjectAltName), and the above error still
persists.
I have tried several other suggestions from similar issues reported at this
list without any luck.
I have run out of ideas. Am I missing anything?
Thanx for any suggestions.
Alex
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/FSIKZJWMW6KKBLCHGZWWXVGQYLPMW7PJ/

[ovirt-users] Re: How to create a backup in event of hardware failure of a single hosted engine?

[Alex K]

On Tue, Nov 17, 2020, 11:08  wrote:

> Hello everyone,
> Currently we have a single bare metal that hosts oVirt and glusterFS which
> later on to be converted to a 3 nodes for HCI, currently another bare metal
> is coming this week and was planning to  initially create it as a backup.
>
> is it possible to deploy a new hosted engine then create a gluster volume
> for 1st one as a backup domain then attach it to the new one if hardware
> failure occurred, or there is another kind of setup that can be done?
>
I would add the new server as an additional host, first preparing the
gluster volumes under the hood. In this way you achieve HA for engine and
guest VMs. When third server arrives, repeat and have a proper 3 node
replica self hosted engine setup.

> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/EYOW4WNUACRCTWLG2IRXEGISYFKBWAU7/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KZ5L3E6UXPHY56WGERVGNEGFGTLQB7RS/

[ovirt-users] Re: ovirt 4.3 - locked image vm - unable to remove a failed deploy of a guest dom

[Alex K]

On Tue, Nov 17, 2020, 16:12 <3c.moni...@gruppofilippetti.it> wrote:

> Hi all.
> I've deployed a VM from a corrupted template (it's disk is missing, but
> I've checked it later...).
> My Software Version is:4.3
> Now, I have an unmanaged VM in inventory and unable to remove it too.
> It's reference is "locked image".
> I've restarted ovirt-engine many times on self-hosted engine and hosts
> too, but no benefits.
> So, what's now?
> I've also consulted: https://access.redhat.com/solutions/396753
> but still no results.
> No tasks or items results to be "locked"...
> Any other ideas?
>
You might try using some of the tools mentioned at
https://www.ovirt.org/develop/developer-guide/db-issues/helperutilities.html
There is an unlock tool.

> Thanks a lot.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/7IK2IAJTEMNR7IM4FJYVHJRJQTQZD537/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LNT3SXR62FVCBAW4FKC273BA23HO74PV/

[ovirt-users] Re: Upgrade OVIRT from 3.6 to 4.3

[Alex K]

On Wed, Nov 11, 2020, 17:03 Miguel Angel Costas 
wrote:

> Hi Guys!
>
> I need to upgrade from 3.6 to 4.3 and I have a doubt.
> Do I need to restard VMs for each upgrade (DC Compatibilty 1° 4.0  - 2°
> 4.1 - 3° 4.2 and 4° 4.3) or can modify the compatibilty  from 3.6 to 4.2
> and restart the vms in this only step.
>
I would restart to complete each step at a time.

>
> Best regards
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/DAXCGYEQM4BM3KWMRAY4HMGE2YAHDB2H/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/J573QMSFII62CBPC47CJJ73AITZETWMI/

[ovirt-users] Re: VM's gone to unknown state

[Alex K]

Hi Hariharan,

On Tue, Nov 10, 2020 at 11:36 AM  wrote:

> Dear Alex,
>
> Thanks for your kind response! So its mandatory to enable power
> management? Is that a good way to enable power management in running hosts
> or already installed hosts in Ovirt? If possible, let me know the benifits
> of using power management;

Yes, you need power management and it can be configured at any time. It is
needed so as the highly available VMs to be restarted at another host, when
one host fails and avoid having zombie VMs in unresponsive state as you
faced. Power management is means for the hosts to ensure the state of each
other and is a must for high availability.

>
> Thanks in advance!
>
> Best Regards,
> Hariharan
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/NRM5JY5TAPGFYNYYP7OQ372X27FA56F7/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LSEJBQAUVPUFLI5J7VI7URH6IGLM7W5R/

[ovirt-users] Re: VM with illegal snapshots

[Alex K]

On Fri, Oct 9, 2020, 12:59 Giorgio Biacchi  wrote:

> Hi,
> due to a bug in our Ovirt integrated backup system now we have some VMs
> with snapshots in illegal state.
>
> It seems that there's an inconsistency between the db and the real
> status of images on disk.
>
> Let me show an example:
>
> engine=# select
>
> image_guid,parentid,imagestatus,vm_snapshot_id,volume_type,volume_format,active
> from images where image_group_id='e34f77cb-54d5-40d0-b539-e0a5fd512d2d';
>   image_guid  |   parentid  |
> imagestatus |vm_snapshot_id| volume_type |
> volume_format | active
>
> --+--+-+--+-+---+
>  a107b6c4-842e-4b40-9215-c965431a0c0f |
> ---- |   4 |
> d19d6ca3-1989-4c67-8ee7-c0c43b3e6d74 |   2 | 4 | f
>  a4c86a68-9123-454c-b417-1b15038a4bf2 |
> a107b6c4-842e-4b40-9215-c965431a0c0f |   1 |
> e7a405ee-8fd4-4733-ae9c-5252bf07c9d3 |   2 | 4 | f
>  f6a61f2e-26bd-4b63-97c6-d66913ce48c5 |
> a4c86a68-9123-454c-b417-1b15038a4bf2 |   1 |
> 9d0958b9-4995-4e11-a027-a32d4bac52e4 |   2 | 4 | t
> (3 rows)
>
>
> [root@host02 ~]#  lvs -o+lv_tags |grep
> e34f77cb-54d5-40d0-b539-e0a5fd512d2d
>   a107b6c4-842e-4b40-9215-c965431a0c0f
> 459011cf-ebb6-46ff-831d-8ccfafd82c8a -wi---  149.50g
>
> IU_e34f77cb-54d5-40d0-b539-e0a5fd512d2d,MD_68,PU_----
>   f6a61f2e-26bd-4b63-97c6-d66913ce48c5
> 459011cf-ebb6-46ff-831d-8ccfafd82c8a -wi---   10.00g
>
> IU_e34f77cb-54d5-40d0-b539-e0a5fd512d2d,MD_348,PU_a107b6c4-842e-4b40-9215-c965431a0c0f
>
> so image guid a4c86a68-9123-454c-b417-1b15038a4bf2 is not present on
> disk, i think that the image was correctly merged but not removed from
> the database.
>
> Any suggestion on how to fix the database to reflect the real situation
> on disk??
>
In those cases I delete the entry from engine DB to reflect the status of
the image chain.

>
> TIA
> --
> gb
>
> PGP Key: http://pgp.mit.edu/
> Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/OF4NTAC6BPGRP4YJZRWBXQCNBWLERL72/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VVQNIERW6XFUEA5NIPQJQHEHCQEIK6QY/

[ovirt-users] Re: VM's gone to unknown state

[Alex K]

On Mon, Nov 9, 2020, 19:12  wrote:

> Dear Strahil Nikolov,
>
> Thank you so much for your kind response and immediate help! The issue got
> resolved and now the hosts got up and running. There was a multiple
> problems in Hosts and again and again I got same issue. Then finally I
> rebooted the hosts thrice and also in Ovirt, I confirmed the reboot option.
> Then it was working fine.
>
This indicates that perhaps you have not configured power management. You
need to have that to avoid these issues.

>
> Nikolov, I ping you back for last issue regarding gluster storage space
> issue in Ovirt4.4. cause that issue still not get resolved.
>
> Thanks once again!
>
>
> Best Regards,
> Hariharan
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/NLIMYZJYENSM7B5YZ2QNKMOWMBCSLUPG/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CVP3PSBQQEYDRABNVWSHE6R6XCL2RJGW/

[ovirt-users] Re: Fence Agent in Virtual Environment

[Alex K]

On Thu, Nov 5, 2020, 18:20 Strahil Nikolov via Users 
wrote:

> This is just a guess , but you might be able to install fence_xvm on all
> Virtualized Hosts .
>
Did not know fence_xvm. Interesting to check it.

>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В четвъртък, 5 ноември 2020 г., 16:00:40 Гринуич+2, jb 
> написа:
>
>
>
>
>
> Hello,
>
> I would like to build a hyperconverged gluster with hosted engine in a
> virtual environment, on Fedora 33 with KVM.
>
> The setup is for testing purposes, specially for test upgrades before
> running them on the real physical Servers. But I want to have the setup
> as close as possible to the real environment, so the only thing is
> missing is a fence agent.
>
> Is there a way to simulate power management in a virtual environment?
>
>
> Jonathan
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/V5SHGKNLTK24DQ3G7ZX6AGKIHLNCFS2J/
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZY2RQ2F7FIC2Y2JCBPBPOJZTMQQ25WA5/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BPKZBINJF7HX4P7AXXCWXZF7UHMW2WHW/

[ovirt-users] Re: Fence Agent in Virtual Environment

[Alex K]

On Thu, Nov 5, 2020, 16:00 jb  wrote:

> Hello,
>
> I would like to build a hyperconverged gluster with hosted engine in a
> virtual environment, on Fedora 33 with KVM.
>
> The setup is for testing purposes, specially for test upgrades before
> running them on the real physical Servers. But I want to have the setup
> as close as possible to the real environment, so the only thing is
> missing is a fence agent.
>
> Is there a way to simulate power management in a virtual environment?
>

I had successfully used the following approach not much time ago:

# Setup power management for VMs:
at hardware host install:
```
yum install python-pip -y
yum install -y zeromq-devel
yum install -y gcc python-devel libvirt-devel
firewall-cmd --permanent --zone=public --add-port=623-624/udp
firewall-cmd --reload
vbmc add CentOS7-ovirt0 --username root --password yourpass --port 623
vbmc add CentOS7-ovirt1 --username root --password yourpass --port 624
[root@baremetal ~]# vbmc list
+++-+--+
| Domain name | Status | Address | Port |
+++-+--+
| CentOS7-ovirt0 | down | :: | 623 |
| CentOS7-ovirt1 | down | :: | 624 |
+++-+--+
[root@v2 ~]# vbmc start CentOS7-ovirt0
2019-10-16 18:44:57,397.397 26596 INFO VirtualBMC [-] Started vBMC instance
for domain CentOS7-ovirt0
[root@v2 ~]# vbmc start CentOS7-ovirt1
2019-10-16 18:45:38,056.056 26596 INFO VirtualBMC [-] Started vBMC instance
for domain CentOS7-ovirt1
[root@v2 ~]# vbmc list
++-+-+--+
| Domain name | Status | Address | Port |
++-+-+--+
| CentOS7-ovirt0 | running | :: | 623 |
| CentOS7-ovirt1 | running | :: | 624 |
++-+-+--+
at node0 host (VM) check:
ipmitool -I lanplus -U root -P yourpass -H  power status
(default port is 623)
ipmitool -I lanplus -U root -P yourpass -H  power status
-p 624
at ovirt GUI you need lanplus=1,-p623 and lanplus=1,-p624 options for each
host.
```

>
>
> Jonathan
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/V5SHGKNLTK24DQ3G7ZX6AGKIHLNCFS2J/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UI2X2GGWNJGXVKW3GKGY43ZC6DU5HXSU/

[ovirt-users] Re: Question about OVN MTU

[Alex K]

On Tue, Oct 27, 2020, 02:49 Strahil Nikolov via Users 
wrote:

> Hello All,
>
> I would like to learn more about OVN and especially the maximum MTU that I
> can use in my environment.
>
> Current Setup 4.3.10
> Network was created via UI -> MTU Custom -> 8976 -> Create on External
> Provider -> Connect to Physical Network
>
> So my physical connection is MTU 9000 and I have read that Geneve uses 24
> bits (maybe that's wrong ?) , thus I have reduced the MTU to 8976.
>
>From the internet draft it seems that the tunnel header + reserved bits
comprise 64 bits. A common practice for Geneve implementations  is to use
8900 mtu for VMs when having 9000 mtu physical network.

The draft:
https://tools.ietf.org/html/draft-ietf-nvo3-geneve-08

>
> I did some testing on the VMs and ping with payload of '8914' was the
> maximum I could pass without fragmenting and thus the MTU on the VMs was
> set to 8942.
>
> Did I correctly configure the test network's MTU and am I understanding it
> correctly that we need extra 34 bits inside the network for encapsulation ?
>
> I have checked
> https://www.ovirt.org/develop/release-management/features/network/managed_mtu_for_vm_networks.html
> but I don't see any refference how to calculate the max MTU.
>
>
> Best Regards,
> Strahil Nikolov
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/CKNS5T5KE2W5EIXBTGQDU3URKHQDVAM4/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VIDP3MLYHWG2WXQ6JB6EHK66J5WBOMVT/

[ovirt-users] Re: Storage Domain Data (Master)

[Alex K]

On Fri, Oct 23, 2020, 19:33  wrote:

> When data (Master) is down the others Domains data are down too?
>
> What is the best practice when a problem ocurres to the Data Master?
>
You try to avoid problems with master data store by adding high
availability at the design. At HCI approach with glusterfs you have enough
nodes (at least 3, in replica 3) to provide the shared storage domain.

>
> Thansk
>
> --
> --
> Jose Ferradeira
> http://www.logicworks.pt
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/2SKXORAPJV4X2MCHSCFIE6EVUJNHKIZL/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/RJVWJMW6S226THU6IBO5JEQYU3YOXZYD/

[ovirt-users] Re: Cannot access Engine VM

[Alex K]

On Tue, Aug 18, 2020, 09:14 Steven Bach via Users  wrote:

> Hello All,
>
> I installed Ovirt node 4.4.1.5 from the ovirt ISO, IP 192.168.1.53/24
> I setup the self hosted engine by logging into the web interface,
> configured it for 192.168.1.55/24 IP on the default generated bridge
> interface and setup a FQDN that is resolvable via DNS.
>
> Setup NFS storage, and all seems good.
>
> The Engine VM is running, but I cannot access it at all outside the node.
> SSH'd in the node I can ping the engine, anything else on that same subnet
> cannot SSH or even ping it (Again, DNS is resolving correctly to the IP
> Address). I am able to SSH into the engine from the node.
>
Sounds like networking or firewall issue. Do a packet trace. If they pass
through the node then check firewall. I would try also forwarding through
ssh to confirm engine health.

>
> While SSH'd into the Engine from the node, I can only ping the Node and
> nothing beyond that, not able to install ovirt repo, nothing.
>
> Any ideas are greatly appreciated, thank you,
>
> --
> Steven Bach
> sb...@bachnetworks.com
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/PDMV3R6ODIAPHRRU6E4RUCU6QOKMRD4T/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XL76ABWNPGDD6QNPN5QHMY4BEE7GLK73/

[ovirt-users] Re: Help needed - Not able to find Windows Guest agent in 4.4.1.10-1.el8 Hosted Engine

[Alex K]

On Fri, Aug 14, 2020, 06:12 dhanaraj.ramesh--- via Users 
wrote:

> Hi Team,
>
> unable to locate Windows guest agant iso in 4.4.1.10-1.el8 Hosted Engine
> version. please share us where can i get the iso?
>
Usually I grab them from here: https://resources.ovirt.org/pub/
I was not able to find a 4.4 version, but 4.3 will do just fine.

>
> there is no /usr/share/oVirt-guest-tools-iso/oVirt-tools-setup.iso
> available in 4.4.1 HE
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/BAHAWSDM5BRMJGUFIM337PP7NL5WPGX3/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/U57AMBSVXWFOKFHGTQMWX72Y76HOIG6R/

[ovirt-users] Re: Migration not working

[Alex K]

On Fri, Aug 14, 2020, 16:16 Juan Pablo Lorier  wrote:

> Hi,
>
> I'm having issues with migration to some hosts. I have a 4 node cluster
> and I tried updating to see if it fixes but it's still failing. The reason
> is nos clear in the engine log.
>
>
> 2020-08-14 09:45:32,322-03 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-429) [364e] EVENT_ID: VM_MIGRATION_START_SYSTEM_INITIAT
> ED(67), Migration initiated by system (VM: medialist2-videoteca, Source:
> virt2.tnu.com.uy, Destination: virt3.tnu.com.uy, Reason: ).
> 2020-08-14 09:45:32,336-03 INFO
> [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (default task-429)
> [535a8bdb] Lock Acquired to object 'EngineLock:{exclusiveLocks='[aac7468
> 5-c969-4761-923f-043400176edf=VM]', sharedLocks=''}'
> 2020-08-14 09:45:32,355-03 INFO
> [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (default task-429)
> [535a8bdb] Running command: MigrateVmToServerCommand internal: true. Ent
> ities affected :  ID: aac74685-c969-4761-923f-043400176edf Type: VMAction
> group MIGRATE_VM with role type USER
> 2020-08-14 09:45:32,383-03 INFO
> [org.ovirt.engine.core.vdsbroker.MigrateVDSCommand] (default task-429)
> [535a8bdb] START, MigrateVDSCommand( MigrateVDSCommandParameters:{hostId=
> '634f3f64-8945-470c-b31c-b8d4c73109e6',
> vmId='aac74685-c969-4761-923f-043400176edf', srcHost='virt2.tnu.com.uy',
> dstVdsId='f9e441a0-a4e6-4548-8c6f-83a958120f02', dstHost='virt4.
> tnu.com.uy:54321', migrationMethod='ONLINE', tunnelMigration='false',
> migrationDowntime='0', autoConverge='true', migrateCompressed='false',
> consoleAddress='null', maxBandwidth=
> '125', enableGuestEvents='true', maxIncomingMigrations='2',
> maxOutgoingMigrations='2', convergenceSchedule='[init=[{name=setDowntime,
> params=[100]}], stalling=[{limit=1, action=
> {name=setDowntime, params=[150]}}, {limit=2, action={name=setDowntime,
> params=[200]}}, {limit=3, action={name=setDowntime, params=[300]}},
> {limit=4, action={name=setDowntime, pa
> rams=[400]}}, {limit=6, action={name=setDowntime, params=[500]}},
> {limit=-1, action={name=abort, params=[]}}]]', dstQemu='172.16.100.45'}),
> log id: 1db80717
> 2020-08-14 09:45:32,385-03 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateBrokerVDSCommand]
> (default task-429) [535a8bdb] START, MigrateBrokerVDSCommand(HostName = virt
> 2.tnu.com.uy,
> MigrateVDSCommandParameters:{hostId='634f3f64-8945-470c-b31c-b8d4c73109e6',
> vmId='aac74685-c969-4761-923f-043400176edf', srcHost='virt2.tnu.com.uy',
> dstVdsId='f9e4
> 41a0-a4e6-4548-8c6f-83a958120f02', dstHost='virt4.tnu.com.uy:54321',
> migrationMethod='ONLINE', tunnelMigration='false', migrationDowntime='0',
> autoConverge='true', migrateCompre
> ssed='false', consoleAddress='null', maxBandwidth='125',
> enableGuestEvents='true', maxIncomingMigrations='2',
> maxOutgoingMigrations='2', convergenceSchedule='[init=[{name=setDow
> ntime, params=[100]}], stalling=[{limit=1, action={name=setDowntime,
> params=[150]}}, {limit=2, action={name=setDowntime, params=[200]}},
> {limit=3, action={name=setDowntime, para
> ms=[300]}}, {limit=4, action={name=setDowntime, params=[400]}}, {limit=6,
> action={name=setDowntime, params=[500]}}, {limit=-1, action={name=abort,
> params=[]}}]]', dstQemu='172.1
> 6.100.45'}), log id: 4085b503
> 2020-08-14 09:45:32,433-03 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateBrokerVDSCommand]
> (default task-429) [535a8bdb] FINISH, MigrateBrokerVDSCommand, return: , log
>  id: 4085b503
> 2020-08-14 09:45:32,437-03 INFO
> [org.ovirt.engine.core.vdsbroker.MigrateVDSCommand] (default task-429)
> [535a8bdb] FINISH, MigrateVDSCommand, return: MigratingFrom, log id: 1db8
> 0717
> 2020-08-14 09:45:32,446-03 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-429) [535a8bdb] EVENT_ID: VM_MIGRATION_START_SYSTEM_INITIAT
> ED(67), Migration initiated by system (VM: reverse_proxy, Source:
> virt2.tnu.com.uy, Destination: virt4.tnu.com.uy, Reason: ).
> 2020-08-14 09:45:32,462-03 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-429) [535a8bdb] EVENT_ID:
> USER_VDS_MAINTENANCE_WITHOUT_REASON(620), Host virt2.tnu.com.uy was
> switched to Maintenance mode by jplor...@tnu.com.uy.
> 2020-08-14 09:45:32,681-03 INFO
> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback]
> (EE-ManagedThreadFactory-engineScheduled-Thread-14)
> [7667d149-886e-406b-9cd6-9b7472fa9944] Command 'MaintenanceNumberOfVdss'
> id: 'db97a747-115b-4f01-aa3d-6277080e6a44' child commands '[]' executions
> were completed, status 'SUCCEEDED'
> 2020-08-14 09:45:33,024-03 INFO
> [org.ovirt.engine.core.vdsbroker.VdsManager]
> (EE-ManagedThreadFactory-engineScheduled-Thread-62) [] Received first
> domain report for host virt2.tnu.com.uy
> 2020-08-14 09:45:33,686-03 INFO
> [org.ovirt.engine.core.bll.MaintenanceNumberOfVdssCommand]
> (EE-ManagedThreadFactory-engineScheduled-Thread-88)
> 

[ovirt-users] Re: Re-creating ISO Storage Domain after Manager Rebuild

[Alex K]

On Fri, Aug 14, 2020, 16:50 Bob Franzke via Users  wrote:

> OK thanks for the reply. As you can perhaps tell I am a complete noob with
> Ovirt. The fact its working now at all is a complete miracle.
>
> >>> I see 2 approaches on fixing the broken storage domain:
> >>> - log to engine, switch to postgresql and start searching in the DB
> for the uuid.
>
> I am not sure what is meant here by 'switch to postgresql'. Can you
> clarify?
>
> >>> Then create the share, create the dir inside and then oVirt should be
> happy.
> >>> Yet it will start complaining for the ISOs that are also missing (and
> also unique uuids)
> >>> - Another approach is to try to remove the ISO domain. Have you tried
> to set the domain in maintenance first and then to remove it ?
>
> I am not sure how this is done. I don’t seem to have any options in the
> Ovirt admin portal to do anything other than destroy the domain. I don’t
> see a maintenance mode option in the Admin UI.
>
>  Check your VMs , if any has an ISO attached to it.
>
> We have templates that were created by someone else. All the VMs seem to
> be built off of those templates, which I assume were built initially  by
> booting off DVD ISOs and installing the OS's for the template VMs. Maybe I
> am missing how VMs get OS's on them in Ovirt. I think the only thing the
> iso domain did was allow us to use the virtio drivers for booting off of
> ISO images. I am not sure if that’s accurate or makes sense here. I
> understood that when the ISO domain is created that those VirtIO drivers
> for CD booting are created as part of the ISO domain creation.

When an iso domain is created it is empty. The virtio iso images are not
automatically created, need to be uploaded.

> This would then give you an option of attaching an uploaded ISO as a
> CD-ROM which you can use to boot a VM off of. I have a CentOS VM which has
> a corrupted XFS filesystem that I would like to boot off of a Rescue CD to
> repair the FS. The only way I know this can be done is by having the rescue
> disk ISO uploaded to an ISO domain. Perhaps there is a different way to do
> that. In any case, it would be good to get the ISO domain working. Right
> now when I try and attach a CD to a VM for booting, there are no options to
> choose and I am assuming its because the VirtIO drivers needed to do such a
> thing are missing because the ISO domain is broken. Sound right?
>
>  Also,  you can upload  an ISO to a data domain and use that to
> install VMs.
>
> Can this be used to boot off a CD in a situation where I need to boot off
> a CD ISO like you would need to do to boot off a CentOS rescue CD?
>
Yes

>
> Thanks very much for the help. This was a system I inherited from someone
> else and I have really no idea what I am doing with it (I am not a
> virtualization expert and have a Network Engineering background).
>
Since you lost the isos, I would destroy the domain and either upload isos
directly at the data storage domain or recreate the iso domain from
scratch.

>
> -Original Message-
> From: hunter86...@yahoo.com (Strahil Nikolov) 
> Sent: Friday, August 14, 2020 4:25 AM
> To: bob.fran...@mdaemon.com; users@ovirt.org
> Subject: Re: [ovirt-users] Re-creating ISO Storage Domain after Manager
> Rebuild
>
> When oVirt creates a storage domain , it assigns an unique id (in the
> engine DB) and a single directory, named as the uuid , is created there.
>
> As you lost the dir, your storage domain is gone but as it's an iso domain
> - it shouldn't be critical.
>
> I see 2 approaches on fixing the broken storage domain:
> - log to engine, switch to postgresql and start searching in the DB for
> the uuid.
> Then create the share, create the dir inside and then oVirt should be
> happy.
> Yet it will start complaining for the ISOs that are also missing (and also
> unique uuids)
> - Another approach is to try to remove the ISO domain. Have you tried to
> set the domain in maintenance first and then to remove it ?
>
> Check your VMs , if any has an ISO attached to it.
>
> Also,  you can upload  an ISO to a data domain and use that to install VMs.
>
> Best  Regards,
> Strahil Nikolov
>
> На 13 август 2020 г. 22:21:10 GMT+03:00, "bob.franzke--- via Users" <
> users@ovirt.org> написа:
> >Hi All,
> >
> >Late last year I had a disk issue with my Ovirt Manager Server that
> >required I rebuild it and restored from backups. While this worked
> >mostly, one thing that did not get put back correctly was the physical
> >storage location of an ISO domain on the manager server. I believe this
> >was previously set up as an NFS share being hosted on the Manager
> >Server itself. The physical disk path and filesystem were not
> >re-created on the manager server's local disk. So after the restore,
> >the ISO domain shows up in the Ovirt Admin portal but shows the as
> >down, and inactive. If I go into the domain, the 'Manage Domain' and
> >'Remove' buttons are not available. The only option I have for this is
> >'Destroy'. 

[ovirt-users] Re: 4.2.8 and yum update

[Alex K]

On Thu, Aug 6, 2020 at 6:42 PM carl langlois  wrote:

> Hi,
>
> Thanks for the suggestion. I will try it.
> But at one point I will need to update the OS past 7.6 as 4.3.9 needs 7.7
> or later.
>
At that point you just switch back your repos at their previous state,
install 4.3 repo, and proceed with your major upgrade. In this way centos
will upgrade also to latest (7.8.2003) Upon completion of the major
upgrade, you remove 4.2 repo.

>
> Regards
> Carl
>
>
>
> On Thu, Aug 6, 2020 at 9:49 AM Alex K  wrote:
>
>> Hi
>>
>> On Thu, Aug 6, 2020 at 3:45 PM carl langlois 
>> wrote:
>>
>>> Hi all,
>>>
>>> I am in the process of upgrading our cluster to 4.3. But first i need to
>>> update everything to 4.2.8 and update the os to the latest 7.x. I was able
>>> to update the self-hosted engine to the latest 4.2.8 and centos 7.8. But
>>> when i tried to update the host yum update got broken gluster packages.
>>> The current host that i'm trying to update is on 7.5. If i look at the
>>> release note i can see that ovirt 4.2.8 needs 7.6. Not sure how to resolve
>>> this.
>>> Any suggestions?.
>>>
>> you need to amend  /etc/yum.repos.d/ovirt-4.2-dependencies.repo and edit
>> the repos that contain the name ovirt-4.2 as following:
>>
>> from: *mirror.centos.org/centos/7 <http://mirror.centos.org/centos/7>*
>> to: *vault.centos.org/centos/7.6.1810
>> <http://vault.centos.org/centos/7.6.1810>*
>>
>> You will need to amend also base repo to avoid centos going to 7.8, as
>> you will face dependency issues with 4.2.  You can point base repo at
>> 7.6.1810, yum update, then follow upgrade to 4.3.
>> For the base repo you need to comment out mirrorlist lines, uncomment
>> baseurl and replace mirror.centos.org/centos/$releasever with
>> *vault.centos.org/centos/7.6.1810
>> <http://vault.centos.org/centos/7.6.1810>. *
>> Just followed this path the previous days and managed to complete the
>> upgrade from 4.2 to 4.3.
>> Good luck.
>>
>>>
>>> Carl
>>> ___
>>> Users mailing list -- users@ovirt.org
>>> To unsubscribe send an email to users-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/QTPJBNLETMHMDHBJXCGTIHRY53UTBJFK/
>>>
>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5QPGHL6KIAX32O7KTW3LIBU5GCAU4P64/

[ovirt-users] Re: 4.2.8 and yum update

[Alex K]

Hi

On Thu, Aug 6, 2020 at 3:45 PM carl langlois  wrote:

> Hi all,
>
> I am in the process of upgrading our cluster to 4.3. But first i need to
> update everything to 4.2.8 and update the os to the latest 7.x. I was able
> to update the self-hosted engine to the latest 4.2.8 and centos 7.8. But
> when i tried to update the host yum update got broken gluster packages.
> The current host that i'm trying to update is on 7.5. If i look at the
> release note i can see that ovirt 4.2.8 needs 7.6. Not sure how to resolve
> this.
> Any suggestions?.
>
you need to amend  /etc/yum.repos.d/ovirt-4.2-dependencies.repo and edit
the repos that contain the name ovirt-4.2 as following:

from: *mirror.centos.org/centos/7 *
to: *vault.centos.org/centos/7.6.1810
*

You will need to amend also base repo to avoid centos going to 7.8, as you
will face dependency issues with 4.2.  You can point base repo at 7.6.1810,
yum update, then follow upgrade to 4.3.
For the base repo you need to comment out mirrorlist lines, uncomment
baseurl and replace mirror.centos.org/centos/$releasever with
*vault.centos.org/centos/7.6.1810
. *
Just followed this path the previous days and managed to complete the
upgrade from 4.2 to 4.3.
Good luck.

>
> Carl
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/QTPJBNLETMHMDHBJXCGTIHRY53UTBJFK/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/FWTNCPRIPY6XONQG32WIGROOQKGENLQC/

[ovirt-users] Re: Changing FQDN

[Alex K]

On Fri, Jul 31, 2020, 21:00 Alex K  wrote:

>
>
> On Fri, Jul 31, 2020, 18:26 Dominik Holler  wrote:
>
>>
>>
>> On Fri, Jul 31, 2020 at 4:00 PM Alex K  wrote:
>>
>>>
>>>
>>> On Fri, Jul 31, 2020 at 4:50 PM Dominik Holler 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jul 31, 2020 at 2:44 PM Alex K  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am running ovirt 4.2.8
>>>>> I did change ovirt engine FQDN using ovirt-engine-rename tool following
>>>>>
>>>>>
>>>>> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/administration_guide/chap-Utilities#Updating_SSL_Certificates
>>>>>
>>>>> Hosts FQDN is also changed and all seem fine apart from OVN connection
>>>>> and ImageIO proxy.
>>>>>
>>>>> About OVN, i just configured OVN and when I test connection I get:
>>>>>
>>>>> Failed with error Certificate for  doesn't match any of the
>>>>> subject alternative names: [old fqdn] and code 5050)
>>>>>
>>>>
>>>>
>>>> Can you please replace all occurrences of the old fqdn by the new fqdn
>>>> in
>>>> /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
>>>> and
>>>> systemctl restart ovirt-provider-ovn
>>>> and let us know if this solves the problem?
>>>>
>>> DId it and the same error is reported.
>>> Then tried to engine-setup and still same issue.
>>>
>>
>> Can you please check if adjusting both URLs of the ovirt-provider-ovn
>> external network provider in oVirt Engine in the
>> oVirt Administration Portal -> Administration -> Providers ->
>> ovirt-provider-ovn -> Edit
>> solves the issue?
>>
> Forgot to mention that I had already changed that to reflect new fqdn.
> Both url and hostname.
>
I think that the issue lies at the ca subject still referring to previous
fqdn.

>
>>
>>
>>>
>>>> This step is not yet automated by ovirt-engine-rename in oVirt-4.2. ,
>>>> please find more details in
>>>> https://bugzilla.redhat.com/1501798
>>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1501798>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> about Imageio proxy when I test the connection I do get nothing. No
>>>>> error at engine.log or at GUI.
>>>>>
>>>>> Thus it seems that I have to generate/replace new certs.
>>>>> Is there a way I can fix this until I switch to 4.3 and eventually to
>>>>> 4.4 where it seems that this is handled from the rename tool?
>>>>>
>>>>> Thanks for any assistance.
>>>>> Alex.
>>>>>
>>>>> ___
>>>>> Users mailing list -- users@ovirt.org
>>>>> To unsubscribe send an email to users-le...@ovirt.org
>>>>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>>>>> oVirt Code of Conduct:
>>>>> https://www.ovirt.org/community/about/community-guidelines/
>>>>> List Archives:
>>>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/XKOUI5FPDDUY3FGGOEBHTX5JQDMZ4DY6/
>>>>>
>>>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CCLGFMIIRUSH3SWKLT2A2RULKNOPVA76/

[ovirt-users] Changing FQDN

[Alex K]

Hi all,

I am running ovirt 4.2.8
I did change ovirt engine FQDN using ovirt-engine-rename tool following

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/administration_guide/chap-Utilities#Updating_SSL_Certificates

Hosts FQDN is also changed and all seem fine apart from OVN connection and
ImageIO proxy.

About OVN, i just configured OVN and when I test connection I get:

Failed with error Certificate for  doesn't match any of the
subject alternative names: [old fqdn] and code 5050)

about Imageio proxy when I test the connection I do get nothing. No error
at engine.log or at GUI.

Thus it seems that I have to generate/replace new certs.
Is there a way I can fix this until I switch to 4.3 and eventually to 4.4
where it seems that this is handled from the rename tool?

Thanks for any assistance.
Alex.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XKOUI5FPDDUY3FGGOEBHTX5JQDMZ4DY6/

[ovirt-users] Re: Guest VM snapshots are not retained when importing data storage domain

[Alex K]

On Fri, Jul 31, 2020 at 12:30 PM Strahil Nikolov 
wrote:

> Theoretically, all the data for the snapshot is both in the Engine's DB
> and on storage (OVF file).
>
> I was afraid to migrate from 4.3  to  4.4  ,  as I was planning  to  wipe
> the engine  and  just import the VMs..., but  I was  not sure  about the
> snapshots.
>
I did not check the actual backing chain of the VM disk image. I reset my
test env and will need to repeat some time to check it. In case there is
still a chain of images referring to the child image then it could be that
we need engine DB informed about this, thus wiping out engine seems not a
viable option. There should be some engine DB import type that could
restore those images and make them visible (again, if they really exist
under the hood which is still to be checked).

>
> Most probably this is a bug.
>
> @Sandro,
>
> can you assist with this one  ?
>
> Best Regards,
> Strahil Nikolov
>
> На 31 юли 2020 г. 10:01:17 GMT+03:00, Alex K 
> написа:
> >Has anyone been able to import a storage domain and still have access
> >to VM
> >snapshots or this might be a missing feature/bug that needs to be
> >reported?
> >Reading the redhat docs about the storage domain import it seems there
> >is
> >no mention of VM snapshots if they should be accessible following the
> >import.
> >Thanx
> >
> >On Thu, Jul 30, 2020 at 3:58 PM Alex K  wrote:
> >
> >> Hi all,
> >>
> >> I have a dual node self hosted cluster v4.3 using gluster as storage
> >so as
> >> to test an actual scenario which will need to be followed at
> >production.
> >> The purpose is to rename the cluster FQDN to a new one, wiping out
> >any
> >> reference to the old previous FQDN. I was not successful in using the
> >> engine-rename tool or other means as there are leftovers from
> >previous FQDN
> >> that cause issues.
> >>
> >> The cluster has a data storage domain with one guest VM running on it
> >> which has one snapshot.
> >> I am testing a destructive scenario as below and I find out that when
> >> importing the storage domain to the newly configured cluster, while
> >the
> >> guest VM is imported fine, I do not see the guest VM disk snapshots.
> >>
> >> Steps that I follow for this scenario:
> >>
> >> *Initial status: *
> >> I have an ovirt cluster with two hosts named v0 and v1.
> >> The gluster storage domain is configured at a separate network where
> >the
> >> hosts are named gluster0 and gluster1.
> >> The cluster has an engine and data storage domain named "engine" and
> >"vms"
> >> respectively.
> >> The "vms" storage domain hosts one guest VM with one guest VM disk
> >> snapshot.
> >> All are configured with fqdn *localdomain.local*
> >>
> >> *# Steps to rename all cluster to new fqdn lab.local and import "vms"
> >> storage domain*
> >> 1. Set v1 ovirt host at maintenance then remove it from GUI.
> >> 2.  At v1 install fresh CentOS7 using the new FQDN lab.local
> >> 3.  at v0 set global maintenance and shutdown engine. Remove the
> >engine
> >> storage data. (complete wipe of any engine related data. What is
> >important
> >> is only VM guests and their snapshots).
> >> 4.  at v0, remove bricks belonging to "engine" and "vms" gluster
> >volumes
> >> of v1 and detach gluster peer v1.
> >>
> >> gluster volume remove-brick engine replica 1
> >> gluster1:/gluster/engine/brick force
> >> gluster volume remove-brick vms replica 1 gluster1:/gluster/vms/brick
> >force
> >> gluster peer detach gluster1
> >>
> >> 5.  On v1, prepare gluster service, reattach peer and add bricks from
> >v0.
> >> At this phase all data from vms gluster volume will be synced to the
> >new
> >> host. Verify with `gluster heal info vms`.
> >> from v0 server run:
> >>
> >> gluster peer probe gluster1
> >> gluster volume add-brick engine replica 2
> >gluster1:/gluster/engine/brick
> >> gluster volume add-brick vms replica 2 gluster1:/gluster/vms/brick
> >>
> >> At this state all gluster volume are up and in sync. We confirm "vms"
> >sync
> >> with
> >> gluster volume heal info vms
> >>
> >> 6.  At freshly installed v1 install engine using the same clean
> >gluster
> >> engine volume:
> >> hosted-engine --deploy --config-append=/root/storag

[ovirt-users] Re: Guest VM snapshots are not retained when importing data storage domain

[Alex K]

Has anyone been able to import a storage domain and still have access to VM
snapshots or this might be a missing feature/bug that needs to be reported?
Reading the redhat docs about the storage domain import it seems there is
no mention of VM snapshots if they should be accessible following the
import.
Thanx

On Thu, Jul 30, 2020 at 3:58 PM Alex K  wrote:

> Hi all,
>
> I have a dual node self hosted cluster v4.3 using gluster as storage so as
> to test an actual scenario which will need to be followed at production.
> The purpose is to rename the cluster FQDN to a new one, wiping out any
> reference to the old previous FQDN. I was not successful in using the
> engine-rename tool or other means as there are leftovers from previous FQDN
> that cause issues.
>
> The cluster has a data storage domain with one guest VM running on it
> which has one snapshot.
> I am testing a destructive scenario as below and I find out that when
> importing the storage domain to the newly configured cluster, while the
> guest VM is imported fine, I do not see the guest VM disk snapshots.
>
> Steps that I follow for this scenario:
>
> *Initial status: *
> I have an ovirt cluster with two hosts named v0 and v1.
> The gluster storage domain is configured at a separate network where the
> hosts are named gluster0 and gluster1.
> The cluster has an engine and data storage domain named "engine" and "vms"
> respectively.
> The "vms" storage domain hosts one guest VM with one guest VM disk
> snapshot.
> All are configured with fqdn *localdomain.local*
>
> *# Steps to rename all cluster to new fqdn lab.local and import "vms"
> storage domain*
> 1. Set v1 ovirt host at maintenance then remove it from GUI.
> 2.  At v1 install fresh CentOS7 using the new FQDN lab.local
> 3.  at v0 set global maintenance and shutdown engine. Remove the engine
> storage data. (complete wipe of any engine related data. What is important
> is only VM guests and their snapshots).
> 4.  at v0, remove bricks belonging to "engine" and "vms" gluster volumes
> of v1 and detach gluster peer v1.
>
> gluster volume remove-brick engine replica 1
> gluster1:/gluster/engine/brick force
> gluster volume remove-brick vms replica 1 gluster1:/gluster/vms/brick force
> gluster peer detach gluster1
>
> 5.  On v1, prepare gluster service, reattach peer and add bricks from v0.
> At this phase all data from vms gluster volume will be synced to the new
> host. Verify with `gluster heal info vms`.
> from v0 server run:
>
> gluster peer probe gluster1
> gluster volume add-brick engine replica 2 gluster1:/gluster/engine/brick
> gluster volume add-brick vms replica 2 gluster1:/gluster/vms/brick
>
> At this state all gluster volume are up and in sync. We confirm "vms" sync
> with
> gluster volume heal info vms
>
> 6.  At freshly installed v1 install engine using the same clean gluster
> engine volume:
> hosted-engine --deploy --config-append=/root/storage.conf
> --config-append=answers.conf (use new FQDN!)
>
> 7.  Upon completion of engine deployment and after having ensured the vms
> gluster volume is synced (step 5) remove bricks of v0 host (v0 now should
> not be visible at ovirt GUI) and detach gluster peer v0.
> at v1 host run:
> gluster volume remove-brick engine replica 1
> gluster0:/gluster/engine/brick force
> gluster volume remove-brick vms replica 1 gluster0:/gluster/vms/brick force
> gluster peer detach gluster0
>
> 8. Install fresh CentOS7 on v0 and prepare it with ovirt node packages,
> networking and gluster.
> 9. At v0, attach gluster bricks from v1. Confirm sync with gluster volume
> heal info.
> at v1 host:
> gluster peer probe gluster0
> gluster volume add-brick engine replica 2 gluster0:/gluster/engine/brick
> gluster volume add-brick vms replica 2 gluster0:/gluster/vms/brick
>
> 10. at engine, add entry for v0 host at /etc/hosts. At ovirt GUI, add v0.
> /etc/hosts:
> 10.10.10.220 node0 v0.lab.local
> 10.10.10.221 node1 v1.lab.local
> 10.10.10.222 engine.lab.local engine
>
> 10.100.100.1 gluster0
> 10.100.100.2 gluster1
>
> 11. At ovirt GUI import vms gluster volume as vms storage domain.
> At this step I have to approve operation:
> [image: image.png]
>
>
> 12. At ovirt GUI, import VMs from vms storage domain.
> At this step the VM is found and imported from the imported storage domain
> "vms", but the VM does not show the previously available disk snapshot.
>
> The import of the storage domain should have retained the guest VM
> snapshot.
> How can this be troubleshooted? Do I have to keep some type of engine DB
> backup so as to make the snapshots visible? If yes, is it possible to

[ovirt-users] Re: best way to have storage vlan available to host AND vms?

[Alex K]

On Thu, Jul 30, 2020, 23:20 Philip Brown  wrote:

> Not quite done.
>
> How do I then assign a host-level IP address in the VLAN?
> I did mention i need it for both VM use, and host level use.
>
Forgot to mention that you can set host ip at that same vlan through the
same host network management interface.  There is a pencil icon where you
click and configure what you need. Sorry no screenshots at the moment.

>
>
>
> - Original Message -
> From: "Alex K" 
> To: "Philip Brown" 
> Cc: "users" 
> Sent: Thursday, July 30, 2020 1:11:22 PM
> Subject: Re: [ovirt-users] best way to have storage vlan available to host
> AND vms?
>
>
> >
> This should be straightforward from within engine gui. No need to mess with
> cockpit. At networks you add a network and tag it with required vlan. Flag
> the network as VM network, so as to become available for guest VM use. Then
> at each host, at the network management interface of the host, you drag the
> new network at the needed physical interface. Repeat same for all hosts and
> 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/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HLZ7VWAQN7PAPICG3VCH56EOIGFDVSTA/

[ovirt-users] Re: best way to have storage vlan available to host AND vms?

[Alex K]

On Thu, Jul 30, 2020, 23:03 Philip Brown  wrote:

> I'm trying to allow a particular iSCSI VLAN to be available to all hosts..
> but also to a few select VMs.
>
> Im finding this challenging, since prior to now, I did host iSCSI config
> on the host-local level.
> i used the cockpit GUI to create a "VLAN" entity, assigned it to an
> interface, and then configured an IP address.
>
> But when I attempt to create a "network"(/aka VLAN) entity from the main
> hosted-engine level.. it seems to conflict with prior host-local created
> ones.
>
> and when I remove the host-local entries...
> I no longer seem to have a way in the GUI to create IP addresses for the
> host, from host cockpit?
> It recognises that the entity exists, but put it in the "unmanaged"
> section.
>
> So.. how can I handle this best?
>
This should be straightforward from within engine gui. No need to mess with
cockpit. At networks you add a network and tag it with required vlan. Flag
the network as VM network, so as to become available for guest VM use. Then
at each host, at the network management interface of the host, you drag the
new network at the needed physical interface. Repeat same for all hosts and
you're done.

>
>
> --
> Philip Brown| Sr. Linux System Administrator | Medata, Inc.
> 5 Peters Canyon Rd Suite 250
> Irvine CA 92606
> Office 714.918.1310| Fax 714.918.1325
> pbr...@medata.com| www.medata.com
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZRXOFZL6WAKHSTY5IMHIGEEMYXROUX5W/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NBXZQSMTS7WLCDY2T5AVU7VYMGRYF3XX/

[ovirt-users] Changing management network

[Alex K]

Hi all,

I see this has been asked in the past though I was not able to find a
specific answer.
I want to change the management network at a new subnet. In this case I am
using /etc/hosts and not DNS, though the steps can be performed with DNS
also.

What i do is:

1. Enable global maintenance
2. SSH into engine and change its IP address to the new network and update
/etc/hosts with new engine and hosts IP addresses. restart engine network.
3. Update /etc/hosts at each host to reflect new engine and host IPs.
4. Login at engine. the hosts will be by now shown as down. For each host,
set host at maintenance and change its management net. Activate host,
migrate engine and repeat.
5. Disable global maintenance.

I did receive some errors at step 4, failing to update host network and
such, though I did run at each host:

ip addr add 10.10.50.X/24 dev ovirtmgmt

so as to add on the fly the new host IP, in case engine wanted to have
access a priory to this new IP (as already configured at /etc/hosts of
engine), and unchecked the "verify engine connectivity" when saving network
changes. When doing this, the host mgmt net was updated.

Now, to make it slightly more difficult, I want to add also a VLAN tag at
the same management net. When I attempt to enable VLAN tagging at the ovirt
management net I get:

[image: image.png]

I proceed and since having configured already the VLANs, and after
switching the host ports to the VLAN network, I do get access at the hosts
and engine.

Do you think this is fine or are there any other recommended steps?

Thanx for any feedback.

Alex
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UEZHVXW6D2WSUYIF6IDRQM6F6WVSYVV4/

[ovirt-users] Guest VM snapshots are not retained when importing data storage domain

[Alex K]

Hi all,

I have a dual node self hosted cluster v4.3 using gluster as storage so as
to test an actual scenario which will need to be followed at production.
The purpose is to rename the cluster FQDN to a new one, wiping out any
reference to the old previous FQDN. I was not successful in using the
engine-rename tool or other means as there are leftovers from previous FQDN
that cause issues.

The cluster has a data storage domain with one guest VM running on it which
has one snapshot.
I am testing a destructive scenario as below and I find out that when
importing the storage domain to the newly configured cluster, while the
guest VM is imported fine, I do not see the guest VM disk snapshots.

Steps that I follow for this scenario:

*Initial status: *
I have an ovirt cluster with two hosts named v0 and v1.
The gluster storage domain is configured at a separate network where the
hosts are named gluster0 and gluster1.
The cluster has an engine and data storage domain named "engine" and "vms"
respectively.
The "vms" storage domain hosts one guest VM with one guest VM disk
snapshot.
All are configured with fqdn *localdomain.local*

*# Steps to rename all cluster to new fqdn lab.local and import "vms"
storage domain*
1. Set v1 ovirt host at maintenance then remove it from GUI.
2.  At v1 install fresh CentOS7 using the new FQDN lab.local
3.  at v0 set global maintenance and shutdown engine. Remove the engine
storage data. (complete wipe of any engine related data. What is important
is only VM guests and their snapshots).
4.  at v0, remove bricks belonging to "engine" and "vms" gluster volumes of
v1 and detach gluster peer v1.

gluster volume remove-brick engine replica 1 gluster1:/gluster/engine/brick
force
gluster volume remove-brick vms replica 1 gluster1:/gluster/vms/brick force
gluster peer detach gluster1

5.  On v1, prepare gluster service, reattach peer and add bricks from v0.
At this phase all data from vms gluster volume will be synced to the new
host. Verify with `gluster heal info vms`.
from v0 server run:

gluster peer probe gluster1
gluster volume add-brick engine replica 2 gluster1:/gluster/engine/brick
gluster volume add-brick vms replica 2 gluster1:/gluster/vms/brick

At this state all gluster volume are up and in sync. We confirm "vms" sync
with
gluster volume heal info vms

6.  At freshly installed v1 install engine using the same clean gluster
engine volume:
hosted-engine --deploy --config-append=/root/storage.conf
--config-append=answers.conf (use new FQDN!)

7.  Upon completion of engine deployment and after having ensured the vms
gluster volume is synced (step 5) remove bricks of v0 host (v0 now should
not be visible at ovirt GUI) and detach gluster peer v0.
at v1 host run:
gluster volume remove-brick engine replica 1 gluster0:/gluster/engine/brick
force
gluster volume remove-brick vms replica 1 gluster0:/gluster/vms/brick force
gluster peer detach gluster0

8. Install fresh CentOS7 on v0 and prepare it with ovirt node packages,
networking and gluster.
9. At v0, attach gluster bricks from v1. Confirm sync with gluster volume
heal info.
at v1 host:
gluster peer probe gluster0
gluster volume add-brick engine replica 2 gluster0:/gluster/engine/brick
gluster volume add-brick vms replica 2 gluster0:/gluster/vms/brick

10. at engine, add entry for v0 host at /etc/hosts. At ovirt GUI, add v0.
/etc/hosts:
10.10.10.220 node0 v0.lab.local
10.10.10.221 node1 v1.lab.local
10.10.10.222 engine.lab.local engine

10.100.100.1 gluster0
10.100.100.2 gluster1

11. At ovirt GUI import vms gluster volume as vms storage domain.
At this step I have to approve operation:
[image: image.png]


12. At ovirt GUI, import VMs from vms storage domain.
At this step the VM is found and imported from the imported storage domain
"vms", but the VM does not show the previously available disk snapshot.

The import of the storage domain should have retained the guest VM
snapshot.
How can this be troubleshooted? Do I have to keep some type of engine DB
backup so as to make the snapshots visible? If yes, is it possible to
restore this backup to a fresh engine that has a new FQDN?
Thanx very much for any advise and hint.

Alex
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SL2M3NDU6GH2AQZ22QD4A4XRTUQ7UY26/

[ovirt-users] Re: Management Engine IP change

[Alex K]

On Thu, Jul 30, 2020 at 2:45 PM Yedidyah Bar David  wrote:

> On Thu, Jul 30, 2020 at 1:47 PM Alex K  wrote:
>
>>
>>
>> On Thu, Jul 30, 2020 at 1:30 PM Yedidyah Bar David 
>> wrote:
>>
>>> On Thu, Jul 30, 2020 at 1:20 PM Alex K  wrote:
>>> >
>>> >
>>> >
>>> > On Thu, Jul 30, 2020 at 12:56 PM Yedidyah Bar David 
>>> wrote:
>>> >>
>>> >> On Thu, Jul 30, 2020 at 12:42 PM Alex K 
>>> wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Thu, Jul 30, 2020 at 12:01 PM Yedidyah Bar David <
>>> d...@redhat.com> wrote:
>>> >> >>
>>> >> >> On Thu, Jul 30, 2020 at 11:30 AM Alex K 
>>> wrote:
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> On Tue, Jul 28, 2020 at 11:51 AM Anton Louw via Users <
>>> users@ovirt.org> wrote:
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> Hi All,
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> Does somebody perhaps know the process of changing the Hosted
>>> Engine IP address? I see that it is possible, I am just not sure if it is a
>>> straight forward process using ‘nmtui’ or editing the network config file.
>>> I have also ensured that everything was configured using the FQDN.
>>> >> >>>
>>> >> >>> Since the FQDN is not changing you should not have issues just
>>> updating your DNS then changing manually the engine IP from the ifcfg-ethx
>>> files then restart networking.
>>> >> >>> What i find difficult and perhaps impossible is to change engine
>>> FQDN, as one will need to regenerate all certs from scratch (otherwise you
>>> will have issues with several services: imageio proxy, OVN, etc) and there
>>> is no such procedure documented/or supported.
>>> >> >>
>>> >> >>
>>> >> >> I wonder - how/what did you search for, that led you to this
>>> conclusion? Or perhaps you even found it explicitly written somewhere?
>>> >> >
>>> >> > Searching around and testing in LAB. I am testing 4.3 though not
>>> 4.4. I used engine-rename tool and although was able to change fqdn for
>>> hosts and engine, I observed that some certificates were left out (for
>>> example OVN was still complaining about certificate issue with subject name
>>> not agreeing with the new FQDN - checking/downloading the relevant cert was
>>> still showing the previous FQDN). I do not deem successful the renaming of
>>> not all services are functional.
>>> >>
>>> >> Very well.
>>> >>
>>> >> I'd find your above statement less puzzling if you wrote instead "...
>>> >> and the procedure for doing this is buggy/broken/incomplete"...
>>> >
>>> > I'm sorry for the confusion.
>>>
>>> No problem :-)
>>>
>>> >>
>>> >>
>>> >> >>
>>> >> >>
>>> >> >> There actually is:
>>> >> >>
>>> >> >>
>>> >> >>
>>> https://www.ovirt.org/documentation/administration_guide/#sect-The_oVirt_Engine_Rename_Tool
>>> >> >
>>> >> >
>>> >> > At this same link it reads:
>>> >> > While the ovirt-engine-rename command creates a new certificate for
>>> the web server on which the Engine runs, it does not affect the certificate
>>> for the Engine or the certificate authority. Due to this, there is some
>>> risk involved in using the ovirt-engine-rename command, particularly in
>>> environments that have been upgraded from Red Hat Enterprise Virtualization
>>> 3.2 and earlier. Therefore, changing the fully qualified domain name of the
>>> Engine by running engine-cleanup and engine-setup is recommended where
>>> possible.
>>> >> > explaining my above findings from the tests.
>>> >>
>>> >> No. These are two different things:
>>> >>
>>> >> 1. Bugs. All software has bugs. Hopefully we fix them over time. If
>>> >> you find one, please file it.
>>

[ovirt-users] Re: Management Engine IP change

[Alex K]

On Thu, Jul 30, 2020 at 11:15 AM Alex K  wrote:

>
>
> On Tue, Jul 28, 2020 at 11:51 AM Anton Louw via Users 
> wrote:
>
>>
>>
>> Hi All,
>>
>>
>>
>> Does somebody perhaps know the process of changing the Hosted Engine IP
>> address? I see that it is possible, I am just not sure if it is a straight
>> forward process using ‘nmtui’ or editing the network config file. I have
>> also ensured that everything was configured using the FQDN.
>>
> Since the FQDN is not changing you should not have issues just updating
> your DNS then changing manually the engine IP from the ifcfg-ethx files
> then restart networking.
> What i find difficult and perhaps impossible is to change engine FQDN, as
> one will need to regenerate all certs from scratch (otherwise you will have
> issues with several services: imageio proxy, OVN, etc) and there is no such
> procedure documented/or supported.
> I might be able to soon test this engine IP change in a virtual
> environment and let you know.
>

I followed the following steps to change engine IP and had no issues:
1. enable global maintenance
2. update your DNS or /etc/hosts settings to reflect new engine IP
3. change engine network configuration to reflect new IP. restart
networking. (not need to reboot engine)
4. at engine: systemctl restart ovirt-engine, systemctl restart
ovirt-imageio-proxy.service (might not be needed)
5. disable global maintenance
6. login at GUI using the same engine fqdn.

Afterwards I confirmed that imageIO proxy and OVN was ok by testing their
connection through GUI, confirming that there is no certificate or other
issue. Also observed for a while engine logs about any error and found
none.

Hope this helps.



>>
>> Thanks
>>
>> *Anton Louw*
>> *Cloud Engineer: Storage and Virtualization* at *Vox*
>> --
>> *T:*  087 805  | *D:* 087 805 1572
>> *M:* N/A
>> *E:* anton.l...@voxtelecom.co.za
>> *A:* Rutherford Estate, 1 Scott Street, Waverley, Johannesburg
>> www.vox.co.za
>>
>> [image: F] <https://www.facebook.com/voxtelecomZA>
>> [image: T] <https://www.twitter.com/voxtelecom>
>> [image: I] <https://www.instagram.com/voxtelecomza/>
>> [image: L] <https://www.linkedin.com/company/voxtelecom>
>> [image: Y] <https://www.youtube.com/user/VoxTelecom>
>>
>> [image: #VoxBrand]
>> <https://www.vox.co.za/fibre/fibre-to-the-home/?prod=HOME>
>> *Disclaimer*
>>
>> The contents of this email are confidential to the sender and the
>> intended recipient. Unless the contents are clearly and entirely of a
>> personal nature, they are subject to copyright in favour of the holding
>> company of the Vox group of companies. Any recipient who receives this
>> email in error should immediately report the error to the sender and
>> permanently delete this email from all storage devices.
>>
>> This email has been scanned for viruses and malware, and may have been
>> automatically archived by *Mimecast Ltd*, an innovator in Software as a
>> Service (SaaS) for business. Providing a *safer* and *more useful* place
>> for your human generated data. Specializing in; Security, archiving and
>> compliance. To find out more Click Here
>> <https://www.voxtelecom.co.za/security/mimecast/?prod=Enterprise>.
>>
>>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/EZPTYSINJMOIOR3QOG4KL3M5ZFHPHPQD/
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QYUUKE3LDNGL75ZR43T46LUUEXVX2GGI/

[ovirt-users] Re: Management Engine IP change

[Alex K]

On Thu, Jul 30, 2020 at 12:56 PM Yedidyah Bar David  wrote:

> On Thu, Jul 30, 2020 at 12:42 PM Alex K  wrote:
> >
> >
> >
> > On Thu, Jul 30, 2020 at 12:01 PM Yedidyah Bar David 
> wrote:
> >>
> >> On Thu, Jul 30, 2020 at 11:30 AM Alex K 
> wrote:
> >>>
> >>>
> >>>
> >>> On Tue, Jul 28, 2020 at 11:51 AM Anton Louw via Users 
> wrote:
> >>>>
> >>>>
> >>>>
> >>>> Hi All,
> >>>>
> >>>>
> >>>>
> >>>> Does somebody perhaps know the process of changing the Hosted Engine
> IP address? I see that it is possible, I am just not sure if it is a
> straight forward process using ‘nmtui’ or editing the network config file.
> I have also ensured that everything was configured using the FQDN.
> >>>
> >>> Since the FQDN is not changing you should not have issues just
> updating your DNS then changing manually the engine IP from the ifcfg-ethx
> files then restart networking.
> >>> What i find difficult and perhaps impossible is to change engine FQDN,
> as one will need to regenerate all certs from scratch (otherwise you will
> have issues with several services: imageio proxy, OVN, etc) and there is no
> such procedure documented/or supported.
> >>
> >>
> >> I wonder - how/what did you search for, that led you to this
> conclusion? Or perhaps you even found it explicitly written somewhere?
> >
> > Searching around and testing in LAB. I am testing 4.3 though not 4.4. I
> used engine-rename tool and although was able to change fqdn for hosts and
> engine, I observed that some certificates were left out (for example OVN
> was still complaining about certificate issue with subject name not
> agreeing with the new FQDN - checking/downloading the relevant cert was
> still showing the previous FQDN). I do not deem successful the renaming of
> not all services are functional.
>
> Very well.
>
> I'd find your above statement less puzzling if you wrote instead "...
> and the procedure for doing this is buggy/broken/incomplete"...
>
I'm sorry for the confusion.

>
> >>
> >>
> >> There actually is:
> >>
> >>
> >>
> https://www.ovirt.org/documentation/administration_guide/#sect-The_oVirt_Engine_Rename_Tool
> >
> >
> > At this same link it reads:
> > While the ovirt-engine-rename command creates a new certificate for the
> web server on which the Engine runs, it does not affect the certificate for
> the Engine or the certificate authority. Due to this, there is some risk
> involved in using the ovirt-engine-rename command, particularly in
> environments that have been upgraded from Red Hat Enterprise Virtualization
> 3.2 and earlier. Therefore, changing the fully qualified domain name of the
> Engine by running engine-cleanup and engine-setup is recommended where
> possible.
> > explaining my above findings from the tests.
>
> No. These are two different things:
>
> 1. Bugs. All software has bugs. Hopefully we fix them over time. If
> you find one, please file it.
>
> 2. Inherent design (or other) problems - the software works as
> intended, but that's not what you want...
>
I do not intend to blame anyone. I really appreciate the work you all are
doing with this great project and understand that the community stream may
have bugs and rough edges or simply I might not be well informed.

>
> See also:
>
> https://www.ovirt.org/develop/networking/changing-engine-hostname.html
>
> >>
> >>
> >> That said, it indeed was somewhat broken for some time now - some fixed
> were only added quite recently, and are available only in current 4.4:
> >
> > This is interesting and needed for migration scenarios.
>
> Can you please elaborate?
>
I am thinking about a scenario where one will need to migrate a DC from one
FQDN to a completely new one (say I currently have host1.domain1.com,
host2.domain1.com, engine.domain1.com and want to switch to
host1.domain2.com, host2.domain2.com, engine.domain2.com) I am currently
facing one such need. I need to migrate existing DC from domain1.com to
domain2.com. Tried the engine-rename tool and changed IPs of engine and
hosts but observed the OVN certificate issue with 4.3. In case this is
sorted with 4.4 then I will see if this resolves my issue.

>
> If it's DR migration, perhaps you want storage export/import, as is
> done using the DR tool:
>
>
> https://www.ovirt.org/documentation/disaster-recovery-guide/disaster-recovery-guide.html
>
> If you just want to use a new name, but do not need to completely
> forget the ol

[ovirt-users] Re: Management Engine IP change

[Alex K]

On Thu, Jul 30, 2020 at 12:01 PM Yedidyah Bar David  wrote:

> On Thu, Jul 30, 2020 at 11:30 AM Alex K  wrote:
>
>>
>>
>> On Tue, Jul 28, 2020 at 11:51 AM Anton Louw via Users 
>> wrote:
>>
>>>
>>>
>>> Hi All,
>>>
>>>
>>>
>>> Does somebody perhaps know the process of changing the Hosted Engine IP
>>> address? I see that it is possible, I am just not sure if it is a straight
>>> forward process using ‘nmtui’ or editing the network config file. I have
>>> also ensured that everything was configured using the FQDN.
>>>
>> Since the FQDN is not changing you should not have issues just updating
>> your DNS then changing manually the engine IP from the ifcfg-ethx files
>> then restart networking.
>> What i find difficult and perhaps impossible is to change engine FQDN, as
>> one will need to regenerate all certs from scratch (otherwise you will have
>> issues with several services: imageio proxy, OVN, etc) and there is no such
>> procedure documented/or supported.
>>
>
> I wonder - how/what did you search for, that led you to this conclusion?
> Or perhaps you even found it explicitly written somewhere?
>
Searching around and testing in LAB. I am testing 4.3 though not 4.4. I
used engine-rename tool and although was able to change fqdn for hosts and
engine, I observed that some certificates were left out (for example OVN
was still complaining about certificate issue with subject name not
agreeing with the new FQDN - checking/downloading the relevant cert was
still showing the previous FQDN). I do not deem successful the renaming of
not all services are functional.

>
> There actually is:
>
>
https://www.ovirt.org/documentation/administration_guide/#sect-The_oVirt_Engine_Rename_Tool
>

At this same link it reads:
While the ovirt-engine-rename command creates a new certificate for the web
server on which the Engine runs, it does not affect the certificate for the
Engine or the certificate authority. Due to this, there is some risk
involved in using the ovirt-engine-rename command, particularly in
environments that have been upgraded from Red Hat Enterprise Virtualization
3.2 and earlier. Therefore, changing the fully qualified domain name of the
Engine by running engine-cleanup and engine-setup is recommended where
possible.
explaining my above findings from the tests.

>
> That said, it indeed was somewhat broken for some time now - some fixed
> were only added quite recently, and are available only in current 4.4:
>
This is interesting and needed for migration scenarios. Also I am wondering
if I can change in some way the management network and make from untagged
to VLAN tagged.

>
>
> https://github.com/oVirt/ovirt-engine/commits/master/packaging/setup/plugins/ovirt-engine-rename
>
> I do not think I am aware of currently still-open bugs. If you find one,
> please file it in bugzilla. Thanks!
>
>
>> I might be able to soon test this engine IP change in a virtual
>> environment and let you know.
>>
>
> Thanks and good luck!
> --
> Didi
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/R5ZWCNEL3HPK5VGTTR6TJ7HMIJ5YCV4M/

[ovirt-users] Re: Upgrade procedure for oVirt

[Alex K]

On Thu, Jul 30, 2020 at 11:08 AM Alex K  wrote:

>
>
> On Thu, Jul 30, 2020 at 10:57 AM Yedidyah Bar David 
> wrote:
>
>> On Thu, Jul 30, 2020 at 10:47 AM Alex K  wrote:
>> >
>> >
>> >
>> > On Thu, Jul 30, 2020 at 10:25 AM Alex K 
>> wrote:
>> >>
>> >> Hi all!
>> >>
>> >> I am going though an upgrade from ovirt 4.2 (4.2.8.2-1.el7) to 4.3 for
>> a two node cluster with self hosted engine. I have done previously upgrades
>> from 4.1 to 4.2 successfully with minor issues which where fixed.
>> >>
>> >> I wanted to confirm with you, in case I am missing anything that may
>> have changed in the mean time, on the steps for minor and major upgrade:
>> >>
>> >> # Ovirt procedure for minor upgrade: (4.x.y -> 4.x.z)
>> >> • enable global maintenance mode
>> >> • at engine: engine-upgrade-check
>> >> • at engine: yum update "ovirt-*-setup*"
>> >> • at engine: engine-setup
>> >> • at engine: yum update
>>
>> stop global maintenance
>>
>> >> • at each host from GUI: host -> installation -> upgrade
>> >> • at each host: yum update, reboot, activate
>> >>
>> >> # Ovirt procedure for major upgrade (4.x -> 4.y)
>> >> • update DC to latest minor version (engine + nodes)
>> >> • enable global maintenance
>> >> • at engine: install major version repo: yum install
>> https://resources.ovirt.org/pub/yum-repo/ovirt-release4x.rpm
>> >> • at engine: engine-upgrade-check
>> >> • at engine:  yum update "ovirt-*-setup*"
>> >> • at engine: engine-setup
>> >> • at engine: remove the old ovirt release from /etc/yum.repos.d
>> >> • at engine: yum update
>> >> • after completion of engine upgrade disable global maintenance
>> >> • verify engine version
>> >> • update each host/node: update to minor, then install new repo,
>> remove old repo, yum update, reboot, activate
>> >> • after completion of updates: set DC and cluster compatibility level
>> to latest version 4.x.
>> >> • shutdown guest VMs and confirm they start up again. (you may need to
>> disable guest disk leases or re-activate guest disks)
>> >> • check events for any issues and fix accordingly
>> >>
>> >> Am I missing anything? I am planning the upgrade hoping to have no
>> issues since the cluster is hosting production VMs.
>> >
>> > Also I am concerned about the minor release upgrade for any package
>> conflicts due to CentOS repos (I have not managed yet to simulate this in a
>> virtual environment). The hosts/nodes are CentOS Linux release 7.6.1810
>> (Core). Do I have to lock the repos to a specific centos version to avoid
>> possible issues (I am afraid CentOS upgrading to latest 7 and causing
>> dependency issues with 4.2 - I was not able to find out the latest CentOS 7
>> versino compatible with 4.2).
>>
>> You are right in that this can be a problem.
>> Generally speaking, your best bet is to find out which CentOS 7 was
>> latest when 4.3 was released (or shortly before that) - that's likely
>> the most reliable version for 4.2. Shortly after 4.3 was released, we
>> stopped checking 4.2 with newer CentOS, so things indeed might have
>> broken without anyone noticing.
>>
> OK. I will try to figure this out.
>
I find out the following notification email about 4.2 last release:

Q+++
The oVirt Project is pleased to announce the general availability of oVirt
4.2.8, as of January 22nd, 2019.

This update is the eighth and last in a series of stabilization updates to
the 4.2 series.

Please note that no further updates will be issued for the 4.2 series.
We encourage users to upgrade to 4.3 series when generally available to
receive new features and updates.

This release is available now for:
* Red Hat Enterprise Linux 7.6 or later
* CentOS Linux (or similar) 7.6 or later

This release supports Hypervisor Hosts running:
* Red Hat Enterprise Linux 7.6 or later
* CentOS Linux (or similar) 7.6 or later
* oVirt Node 4.2
+++Q

So I will try locking to latest 7.6 version and fingers crossed!


>> What do you mean in "I have not managed yet to simulate this in a
>> virtual environment"? That it fails? Passes? Didn't try yet?
>
> Did not manage to yet test it and find out. In the process of doing so.  I
> recall several dependency issues when going from 4.1 to 4.2. Unfortunately
> I am not able to keep up with the ovirt upgrades in a timely manner
> (currently managing around 20 such cluste

[ovirt-users] Re: Management Engine IP change

[Alex K]

On Tue, Jul 28, 2020 at 11:51 AM Anton Louw via Users 
wrote:

>
>
> Hi All,
>
>
>
> Does somebody perhaps know the process of changing the Hosted Engine IP
> address? I see that it is possible, I am just not sure if it is a straight
> forward process using ‘nmtui’ or editing the network config file. I have
> also ensured that everything was configured using the FQDN.
>
Since the FQDN is not changing you should not have issues just updating
your DNS then changing manually the engine IP from the ifcfg-ethx files
then restart networking.
What i find difficult and perhaps impossible is to change engine FQDN, as
one will need to regenerate all certs from scratch (otherwise you will have
issues with several services: imageio proxy, OVN, etc) and there is no such
procedure documented/or supported.
I might be able to soon test this engine IP change in a virtual environment
and let you know.

>
>
> Thanks
>
> *Anton Louw*
> *Cloud Engineer: Storage and Virtualization* at *Vox*
> --
> *T:*  087 805  | *D:* 087 805 1572
> *M:* N/A
> *E:* anton.l...@voxtelecom.co.za
> *A:* Rutherford Estate, 1 Scott Street, Waverley, Johannesburg
> www.vox.co.za
>
> [image: F] 
> [image: T] 
> [image: I] 
> [image: L] 
> [image: Y] 
>
> [image: #VoxBrand]
> 
> *Disclaimer*
>
> The contents of this email are confidential to the sender and the intended
> recipient. Unless the contents are clearly and entirely of a personal
> nature, they are subject to copyright in favour of the holding company of
> the Vox group of companies. Any recipient who receives this email in error
> should immediately report the error to the sender and permanently delete
> this email from all storage devices.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by *Mimecast Ltd*, an innovator in Software as a
> Service (SaaS) for business. Providing a *safer* and *more useful* place
> for your human generated data. Specializing in; Security, archiving and
> compliance. To find out more Click Here
> .
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/EZPTYSINJMOIOR3QOG4KL3M5ZFHPHPQD/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/6XWDYTWTQIWO44FOS25R7TEQOVSCIZCR/

[ovirt-users] Re: Upgrade procedure for oVirt

[Alex K]

On Thu, Jul 30, 2020 at 10:57 AM Yedidyah Bar David  wrote:

> On Thu, Jul 30, 2020 at 10:47 AM Alex K  wrote:
> >
> >
> >
> > On Thu, Jul 30, 2020 at 10:25 AM Alex K  wrote:
> >>
> >> Hi all!
> >>
> >> I am going though an upgrade from ovirt 4.2 (4.2.8.2-1.el7) to 4.3 for
> a two node cluster with self hosted engine. I have done previously upgrades
> from 4.1 to 4.2 successfully with minor issues which where fixed.
> >>
> >> I wanted to confirm with you, in case I am missing anything that may
> have changed in the mean time, on the steps for minor and major upgrade:
> >>
> >> # Ovirt procedure for minor upgrade: (4.x.y -> 4.x.z)
> >> • enable global maintenance mode
> >> • at engine: engine-upgrade-check
> >> • at engine: yum update "ovirt-*-setup*"
> >> • at engine: engine-setup
> >> • at engine: yum update
>
> stop global maintenance
>
> >> • at each host from GUI: host -> installation -> upgrade
> >> • at each host: yum update, reboot, activate
> >>
> >> # Ovirt procedure for major upgrade (4.x -> 4.y)
> >> • update DC to latest minor version (engine + nodes)
> >> • enable global maintenance
> >> • at engine: install major version repo: yum install
> https://resources.ovirt.org/pub/yum-repo/ovirt-release4x.rpm
> >> • at engine: engine-upgrade-check
> >> • at engine:  yum update "ovirt-*-setup*"
> >> • at engine: engine-setup
> >> • at engine: remove the old ovirt release from /etc/yum.repos.d
> >> • at engine: yum update
> >> • after completion of engine upgrade disable global maintenance
> >> • verify engine version
> >> • update each host/node: update to minor, then install new repo, remove
> old repo, yum update, reboot, activate
> >> • after completion of updates: set DC and cluster compatibility level
> to latest version 4.x.
> >> • shutdown guest VMs and confirm they start up again. (you may need to
> disable guest disk leases or re-activate guest disks)
> >> • check events for any issues and fix accordingly
> >>
> >> Am I missing anything? I am planning the upgrade hoping to have no
> issues since the cluster is hosting production VMs.
> >
> > Also I am concerned about the minor release upgrade for any package
> conflicts due to CentOS repos (I have not managed yet to simulate this in a
> virtual environment). The hosts/nodes are CentOS Linux release 7.6.1810
> (Core). Do I have to lock the repos to a specific centos version to avoid
> possible issues (I am afraid CentOS upgrading to latest 7 and causing
> dependency issues with 4.2 - I was not able to find out the latest CentOS 7
> versino compatible with 4.2).
>
> You are right in that this can be a problem.
> Generally speaking, your best bet is to find out which CentOS 7 was
> latest when 4.3 was released (or shortly before that) - that's likely
> the most reliable version for 4.2. Shortly after 4.3 was released, we
> stopped checking 4.2 with newer CentOS, so things indeed might have
> broken without anyone noticing.
>
OK. I will try to figure this out.

>
> What do you mean in "I have not managed yet to simulate this in a
> virtual environment"? That it fails? Passes? Didn't try yet?

Did not manage to yet test it and find out. In the process of doing so.  I
recall several dependency issues when going from 4.1 to 4.2. Unfortunately
I am not able to keep up with the ovirt upgrades in a timely manner
(currently managing around 20 such clusters) hence have to face the issues
when I manage to do the upgrades... :) I will have to further streamline
the process perhaps through ansible and see if I can at least keep a local
repo for such delayed upgrades.

> I'd
> definitely first simulate this in a test (can be virtual) env, before
> production. If possible, I'd start with a copy of production - and
> make sure it's an isolated network, so that the tested engine can't
> mess with your production hosts.
>
> Good luck and best regards,
>
Thank you Didi

> --
> Didi
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JWYA5GEXGDCHKIRQMVLBA57H74K6WVGX/

[ovirt-users] Re: Ovirt hypervisor as an DRBD node

[Alex K]

On Tue, Jul 28, 2020 at 9:06 AM  wrote:

> Hi community,
> I would like to use 3 nodes for hypervisor (hosted engine or install a
> separate VM with engine for its subsequent management) to use them as
> storage nodes - drbd 9 dual primary + quorum node (aka backup), ocfs 2 - so
> that the VMs used the hardware of both nodes (so to speak, hyperconverged
> with drbd). Can you tell me if there are any limits on the part of ovirt
> for this configuration and the best way to mount ocfs2 - iscsi via scst,
> posixFS or cinder?
>
I would not expect an issue as long as you expose the storage with
supported storage types (iSCSI, NFS, etc). I guess though that you need to
separately manage the HA part of the storage (pacemaker comes to my mind)
which complicates the setup, whereas if going with glusterFS this is done
automatically from oVirt by using the backup-volfile-servers gluster mount
option.

Thanks in advance
> Best regards
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/XEFI5UWHODWAPDKROWVDLE4OIWHQ2P77/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/H3RQ4LWCXAMFRRCAWIFKKBDZW27UVLJC/

[ovirt-users] Re: Upgrade procedure for oVirt

[Alex K]

On Thu, Jul 30, 2020 at 10:25 AM Alex K  wrote:

> Hi all!
>
> I am going though an upgrade from ovirt 4.2 (4.2.8.2-1.el7) to 4.3 for a
> two node cluster with self hosted engine. I have done previously upgrades
> from 4.1 to 4.2 successfully with minor issues which where fixed.
>
> I wanted to confirm with you, in case I am missing anything that may have
> changed in the mean time, on the steps for minor and major upgrade:
>
> *# Ovirt procedure for minor upgrade: (4.x.y -> 4.x.z)*
> • enable global maintenance mode
> • at engine: engine-upgrade-check
> • at engine: yum update "ovirt-*-setup*"
> • at engine: engine-setup
> • at engine: yum update
> • at each host from GUI: host -> installation -> upgrade
> • at each host: yum update, reboot, activate
>
> *# Ovirt procedure for major upgrade (4.x -> 4.y)*
> • update DC to latest minor version (engine + nodes)
> • enable global maintenance
> • at engine: install major version repo: yum install
> https://resources.ovirt.org/pub/yum-repo/ovirt-release4x.rpm
> • at engine: engine-upgrade-check
> • at engine:  yum update "ovirt-*-setup*"
> • at engine: engine-setup
> • at engine: remove the old ovirt release from /etc/yum.repos.d
> • at engine: yum update
> • after completion of engine upgrade disable global maintenance
> • verify engine version
> • update each host/node: update to minor, then install new repo, remove
> old repo, yum update, reboot, activate
> • after completion of updates: set DC and cluster compatibility level to
> latest version 4.x.
> • shutdown guest VMs and confirm they start up again. (you may need to
> disable guest disk leases or re-activate guest disks)
> • check events for any issues and fix accordingly
>
> Am I missing anything? I am planning the upgrade hoping to have no issues
> since the cluster is hosting production VMs.
>
Also I am concerned about the minor release upgrade for any package
conflicts due to CentOS repos (I have not managed yet to simulate this in a
virtual environment). The hosts/nodes are CentOS Linux release 7.6.1810
(Core). Do I have to lock the repos to a specific centos version to avoid
possible issues (I am afraid CentOS upgrading to latest 7 and causing
dependency issues with 4.2 - I was not able to find out the latest CentOS 7
versino compatible with 4.2).

>
> Thanx for any feedback!
> Alex
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/HUSCBUEFJAEAFAZMFIV7AVDWBVSJ3E27/

[ovirt-users] Upgrade procedure for oVirt

[Alex K]

Hi all!

I am going though an upgrade from ovirt 4.2 (4.2.8.2-1.el7) to 4.3 for a
two node cluster with self hosted engine. I have done previously upgrades
from 4.1 to 4.2 successfully with minor issues which where fixed.

I wanted to confirm with you, in case I am missing anything that may have
changed in the mean time, on the steps for minor and major upgrade:

*# Ovirt procedure for minor upgrade: (4.x.y -> 4.x.z)*
• enable global maintenance mode
• at engine: engine-upgrade-check
• at engine: yum update "ovirt-*-setup*"
• at engine: engine-setup
• at engine: yum update
• at each host from GUI: host -> installation -> upgrade
• at each host: yum update, reboot, activate

*# Ovirt procedure for major upgrade (4.x -> 4.y)*
• update DC to latest minor version (engine + nodes)
• enable global maintenance
• at engine: install major version repo: yum install
https://resources.ovirt.org/pub/yum-repo/ovirt-release4x.rpm
• at engine: engine-upgrade-check
• at engine:  yum update "ovirt-*-setup*"
• at engine: engine-setup
• at engine: remove the old ovirt release from /etc/yum.repos.d
• at engine: yum update
• after completion of engine upgrade disable global maintenance
• verify engine version
• update each host/node: update to minor, then install new repo, remove old
repo, yum update, reboot, activate
• after completion of updates: set DC and cluster compatibility level to
latest version 4.x.
• shutdown guest VMs and confirm they start up again. (you may need to
disable guest disk leases or re-activate guest disks)
• check events for any issues and fix accordingly

Am I missing anything? I am planning the upgrade hoping to have no issues
since the cluster is hosting production VMs.

Thanx for any feedback!
Alex
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KB3QFU5F66FQYUGXOLDRC5DGYGKQIL4F/

[ovirt-users] Re: subnets

[Alex K]

On Sat, Feb 29, 2020, 18:38  wrote:

> I have a network in place with several subnets, one for iscsi and one for
> virtual pbx and VoIP phones. I use the iscsi in Ovirt, but I cannot get
> Ovirt to recognize and use the physical vlan 3 network for phones. If I add
> it and the subnet, Ovirt will make give it an IP, but it's an isolated
> network with no connectivity to the other vm's or the Internet.
>
You will need to attach a vm to a network in order the vm to have access to
the specific network. This should be straightforward from web gui.

> I have read several topics on this but I can't get it to work properly.
> Any help would be appreciated.
> 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/CYXBJM43M6TR6GZKU3AKE2LTCGDBS7MK/
>
___
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/5NH3Y7ULFVLL3BNLO3BK4ZSLS5U3C6YQ/

[ovirt-users] Re: oVirt & Zabbix agent

[Alex K]

On Fri, Feb 14, 2020, 20:48 Diggy Mc  wrote:

> Are there any known issues with running the Zabbix agent on either the
> Hosted Engine (4.3.8) or oVirt Nodes (4.3.8) ???  I'd like to install the
> agent while not crashing my hosting environment.
>
I've done that and have seen no issues for several years.

> ___
> 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/DR3LNJFP2KV53DMXESZCI4MIFR3ZCNUQ/
>
___
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/5ZGCPQNWV3M6PHFWMWB3WE7UAKGM77A3/

[ovirt-users] Re: Power management and storage domains error when running Ansible tasks!

[Alex K]

Hi,

On Tue, Jan 14, 2020 at 7:51 PM  wrote:

> I don't have power management devices on the Intel NUC. You probably
> missed the message where I posted this because of
> https://lists.ovirt.org/archives/list/users@ovirt.org/thread/4WRVQKDASO7YORTR24UINCHVGAWWXU4T/
> .
>

For production you will need hardware that supports power management
(either the servers or external device, like UPS). In case you need just to
test ovirt with power management, you can setup software power management
on the hypervisor, where the ovirt nodes will be hosted as nested. I had
luck with following approach:

Assumption:
Baremetal: the host where nested KVM is setup.
Ovirt VMs: CentOS7-ovirt0, CentOS7-ovirt1

[root@baremetal ~]# yum install python-pip -y
[root@baremetal ~]# yum install -y zeromq-devel
[root@baremetal ~]# yum install -y gcc python-devel libvirt-devel
[root@baremetal ~]# firewall-cmd --permanent --zone=public
--add-port=623-624/udp
[root@baremetal ~]# firewall-cmd --reload
[root@baremetal ~]# vbmc add CentOS7-ovirt0 --username root --password
yourpass --port 623
[root@baremetal ~]# vbmc add CentOS7-ovirt1 --username root --password
yourpass --port 624

[root@baremetal ~]# vbmc list
+++-+--+
| Domain name| Status | Address | Port |
+++-+--+
| CentOS7-ovirt0 | down   | ::  |  623 |
| CentOS7-ovirt1 | down   | ::  |  624 |
+++-+--+

[root@baremetal ~]# vbmc start CentOS7-ovirt0
2019-10-16 18:44:57,397.397 26596 INFO VirtualBMC [-] Started vBMC instance
for domain CentOS7-ovirt0
[root@baremetal ~]# vbmc start CentOS7-ovirt1
2019-10-16 18:45:38,056.056 26596 INFO VirtualBMC [-] Started vBMC instance
for domain CentOS7-ovirt1
[root@baremetal ~]# vbmc list
++-+-+--+
| Domain name| Status  | Address | Port |
++-+-+--+
| CentOS7-ovirt0 | running | ::  |  623 |
| CentOS7-ovirt1 | running | ::  |  624 |
++-+-+--+

at node0 host (VM) check:
ipmitool -I lanplus -U root -P yourpass -H  power status
(default port is 623)
ipmitool -I lanplus -U root -P yourpass -H  power status
-p 624

at ovirt GUI you need lanplus=1,-p623 and lanplus=1,-p624 options for each
host.

___
> 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/SBA4MTQT62YFIGOLLBRQDEGYCDDDQYOU/
>
___
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/ENR5EYVELCNWVHZON63MZHG6J2RCQXOX/

[ovirt-users] Re: Setting up cockpit?

[Alex K]

On Mon, Jan 13, 2020 at 11:23 AM  wrote:

> I was not able to open a bug I was getting several different errors from
> bugzilla. But of course after a while it was working again. Someone
> restarted the web server. Now everything is OK but the experience of
> entering bugs in that tool is/was horrible.
>
Glad that you managed to open the bug. I agree that the experience is
somehow outdated.

> ___
> 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/65RBRITLI4IFQINNJQLQDLH45Q5EYNL2/
>
___
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/QATYGQU7QG5A5LZGCPKBDBFFMGNRH4DU/

[ovirt-users] Re: Setting up cockpit?

[Alex K]

On Mon, Jan 13, 2020 at 12:36 AM  wrote:

> Well if *you* don't see any issues then we can finally sleep at night.
>
You mentioned issues with bugzilla or did I understood wrong? You are not
able to open a bug? Went to bugzilla and it seems that the process to open
a bug functions properly. In case not, let us know more details what are
you facing so as to have a chance to get some assistance.

___
> 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/2OZAXV2KFOWKTLJK2OBYQC7EGOFATEPI/
>
___
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/6ZG7KYIN742QLK33ZIB4WG5OTLL5VG4U/

[ovirt-users] Re: HCI Disaster Recovery

[Alex K]

On Fri, Jan 10, 2020, 20:12 Christian Reiss 
wrote:

> Hey,
>
> is there really no ovirt native way to restore a single host and bring
> it back into the cluster?
>
I'm not sure if all can be done from gui. I would manually configure
gluster and do the host install from gui.

>
> -Chris.
>
> On 07.01.2020 09:54, Christian Reiss wrote:
> > Hey folks,
> >
> >- theoretical question, no live data in jeopardy -
> >
> > Let's say a 3-way HCI cluster is up and running, with engine running,
> > all is well. The setup was done via gui, including gluster.
> >
> > Now I would kill a host, poweroff & disk wipe. Simulating a full node
> > failure.
> >
> > The remaining nodes should keep running on (3 copy sync, no arbiter),
> > vms keep running or will be restarted. I would reinstall using the ovirt
> > node installer on the "failed" node.
> >
> > This would net me with a completely empty, no-gluster setup. What is the
> > oVirt way to recover from this point onward?
> >
> > Thanks for your continued support! <3
> > -Christian.
> >
>
> --
> Christian Reiss - em...@christian-reiss.de /"\  ASCII Ribbon
> christ...@reiss.nrw  \ /Campaign
>   X   against HTML
>   XMPP ch...@alpha-labs.net  / \   in eMails
>   WEB  christian-reiss.de, reiss.nrw
>
>   GPG Retrieval http://gpg.christian-reiss.de
>   GPG ID ABCD43C5, 0x44E29126ABCD43C5
>   GPG fingerprint = 9549 F537 2596 86BA 733C  A4ED 44E2 9126 ABCD 43C5
>
>   "It's better to reign in hell than to serve in heaven.",
>John Milton, Paradise 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/GQECSH72L4SMOWYT6WDADUHR7MMWVHP6/
>
___
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/GPI662ULD332KIZFJMQJGK6LMAEQPBIJ/

[ovirt-users] Re: No virtio-win vfd oVirt 4.3.7

[Alex K]

On Thu, Dec 19, 2019, 17:29 Vrgotic, Marko 
wrote:

> Dear oVIrt,
>
>
>
> I am trying to install Windows 10 on oVirt, following procedure on:
>
>
> https://www.ovirt.org/documentation/vmm-guide/chap-Installing_Windows_Virtual_Machines.html
>
>
>
> Unfortunately, there is no option as explained in the “Installing Windows
> on VirtIO-Optimized Hardware”.
>
>
>
> There is just no “*virtio-win.vfd” *option when attaching Floppy. Is this
> valid.
>
>
>
> I have ISO Domain, which is not hosted by Hosted Engine, but mounte
> additionally. Is this required in order to have the virtio-win.vfd option?
>
You need to upload the vfd file at the ISO domain that is managed from
engine.

>
>
> If not, please let me know what am I missing.
>
> In the meanwhile,  I am working on building custom Wind 10 ISO which
> contains Virtio/Virtio-SCSI drivers.
>
>
>
> Kindly awaiting your reply.
>
>
>
>
>
>
>
> -
>
> kind regards/met vrindelijke groet
>
>
>
> Marko Vrgotic
> Sr. System Engineer @ System Administration
>
>
> ActiveVideo
>
> *o: *+31 (35) 6774131
>
> *e:* m.vrgo...@activevideo.com
> *w: *www.activevideo.com
>
>
>
> ActiveVideo Networks BV. Mediacentrum 3745 Joop van den Endeplein 1.1217
> WJ Hilversum, The Netherlands. The information contained in this message
> may be legally privileged and confidential. It is intended to be read only
> by the individual or entity to whom it is addressed or by their designee.
> If the reader of this message is not the intended recipient, you are on
> notice that any distribution of this message, in any form, is strictly
> prohibited.  If you have received this message in error, please immediately
> notify the sender and/or ActiveVideo Networks, LLC by telephone at +1
> 408.931.9200 and delete or destroy any copy of this message.
>
>
>
>
> ___
> 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/3UYBO73SHPRHQ7DPOTGAJXS5NPA33TOK/
>
___
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/3D7QH7QG2TBXBSSDVGJNM5NTQZBO7BBH/

[ovirt-users] Re: Migrate VM from oVirt to oVirt

[Alex K]

On Thu, Nov 14, 2019, 01:25  wrote:

> Thank Jayme,
> It worked, wondering if there is a more straight fwd way.
>
You can also export to ova, and then upload the ova.

>
> 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/RVMMVD6QRKSM24DATHM6564QKLSSC4CW/
>
___
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/EHIIVOTNFMFDLHTNZRVDQW5DWR26D72D/

[ovirt-users] Re: Reimport OVA Windows 2019 VM

[Alex K]

On Tue, Oct 22, 2019, 13:59 matteo fedeli  wrote:

> "I presume that inside oVirt the disk itself is marked as bootable,
> correct?"
> yes.
>
> "Which type has been assigned to it?"
> Type. What do you mean?
>
> "In the original exported VM do you remember which type of disk/controller
> you used for the boot disk?"
> VirtIO or VirtIO SCSI
>
> "In case you can edit it (with VM powered down) and try both virtio and
> virtio-scsi as interface types."
> Already done! No success...
>
I confirm having the same issue.  I was testing Windows 10.

>
> The others linux machines are imported with success.
> ___
> 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/7ZP62GNJOOVG25IPQR42YKJ7EDQZCL3Q/
>
___
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/7PD5SGR7UAQ5UEGNYN7V3DYZWZWAIJRQ/

[ovirt-users] Re: Windows server std 2019 64 bit support

[Alex K]

On Fri, Sep 6, 2019 at 2:49 PM Bernhard Dick  wrote:

> Hi Alex,
>
> Am 05.09.2019 um 14:23 schrieb Alex K:
> > [...]
> > Have you tried to load Windows server std 2019 64 bit successfullyon
> > ovirt 3.4?
> I think you are talking about version 4.3, as you also mention RHEV 4.3?
> I have three Windows Server 2019 64bit installations running in an oVirt
> 4.3 environment (two in Core mode, one with Desktop extensions
> available) and they're running fine.
>
Thank you Bernhard.
Yes, I meant 4.3.

>
>Regards
>  Bernhard
> >
> > Thank you.
> ___
> 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/BU4HO5QZAO3GMYFXSPDI7SWPMEHKSNZZ/
>
___
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/NTVYHJGZHKEJNZQ3PCQYG4HR642W3SFV/

[ovirt-users] Windows server std 2019 64 bit support

[Alex K]

Hi all,

I am trying to find out if Windows server std 2019 64 bit is supported at
ovirt 3.4.

I have checked the following links:
https://www.ovirt.org/documentation/vmm-guide/chap-Introduction.html

https://access.redhat.com/articles/973133

https://www.windowsservercatalog.com/results.aspx?=1521=24121=0=0=0=0=1=25

>From the above I deduce that RHEV 4.3.5 supports it and ovirt does not
include it in the supported list of guest OS. Also KVM on CentOS 7.7 seems
to be supporting it as RHEL 7.7 is listed as supported platform.

Have you tried to load Windows server std 2019 64 bit successfullyon ovirt
3.4?

Thank you.
___
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/TNN2RZRXAWCXSKD5KCPQMJYWXYTC4NAA/

[ovirt-users] Re: oVirt 4.3.5 WARN no gluster network found in cluster

[Alex K]

On Thu, Aug 22, 2019, 04:47  wrote:

> Hi,
> I have a 4.3.5 hyperconverged setup with 3 hosts, each host has 2x10G NIC
> ports
>
> Host1:
> NIC1: 192.168.1.11
> NIC2: 192.168.0.67 (Gluster)
>
> Host2:
> NIC1: 10.10.1.12
> NIC2: 192.168.0.68 (Gluster)
>
> Host3:
> NIC1: 10.10.1.13
> NIC2: 192.168.0.69 (Gluster)
>
> I am able to ping all the gluster IPs from within the hosts. i.e  from
> host1 i can ping 192.168.0.68 and 192.168.0.69
> However from the HostedEngine VM I cant ping any of those IPs
> [root@ovirt-engine ~]# ping 192.168.0.9
> PING 192.168.0.60 (192.168.0.60) 56(84) bytes of data.
> From 10.10.255.5 icmp_seq=1 Time to live exceeded
>
>
> and on the HostedEngine I see the following WARNINGS (only for host1)
> which make me think that I am not using a separate network exclusively for
> gluster.
>
> 2019-08-21 21:04:34,215-04 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn]
> (DefaultQuartzScheduler10) [397b6038] Could not associate brick
> 'host1.example.com:/gluster_bricks/engine/engine' of volume
> 'ac1f73ce-cdf0-4bb9-817d-xxcxxx' with correct network as no gluster
> network found in cluster '11e9-b8d3-00163e5d860d'
>
>
> Any ideas?
>
Have you designated the specific network as gluster? This is done under
Cluster -> network -> network setup

>
> thank you!!
> 2019-08-21 21:04:34,220-04 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn]
> (DefaultQuartzScheduler10) [397b6038] Could not associate brick
> 'vmm01.virt.ord1d:/gluster_bricks/data/data' of volume
> 'bc26633a-9a0b-49de-b714-97e76f222a02' with correct network as no gluster
> network found in cluster 'e98e2c16-c31e-11e9-b8d3-00163e5d860d'
>
> 2019-08-21 21:04:34,224-04 WARN
> [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturn]
> (DefaultQuartzScheduler10) [397b6038] Could not associate brick
> 'host1:/gluster_bricks/vmstore/vmstore' of volume
> 'x-ca96-45cc-9e0f-649055e0e07b' with correct network as no gluster
> network found in cluster 'e98e2c16-c31e-11e9-b8d3xxx'
> ___
> 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/ABYMLUNKBVCPDBGHSDFNCKMH7LOLVA7O/
>
___
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/2LZTSTADZBUR45ICDVCIT7ZXHORU6ZDJ/

[ovirt-users] Re: engine-setup failure on 4.1 -> 4.2

[Alex K]

I repeated the same upgrade steps to another cluster and although I was
receiving same warnings about the db the upgrade completed successfully.

Is there a way I can manually inform engine db about the maintenance
status? I was thinking that in this way the engine would proceed with the
remaining steps.

On Thu, Jul 25, 2019 at 3:55 PM Alex K  wrote:

> Hi all,
>
> I have a self hosted engine setup, with 3 servers.
> I have successfully upgraded several other installations, from 4.1 to 4.2.
> On one of them I am encountering and issue with the engine-setup.
>
> I get the following warning:
>
>   Found the following problems in PostgreSQL configuration for the Engine
> database:
>It is required to be at least '8192'
>
>   Please note the following required changes in postgresql.conf on
> 'localhost':
> 'work_mem' is currently '1024'. It is required to be at least
> '8192'.
>   postgresql.conf is usually in /var/lib/pgsql/data,
> /var/opt/rh/rh-postgresql95/lib/pgsql/data, or somewhere under
> /etc/postgresql* . You have to restart PostgreSQL after making these
> changes.
>   The database requires these configurations values to be changed.
> Setup can fix them for you or abort. Fix automatically? (Yes, No) [Yes]:
>
> Then, if I select Yes to proceed, I get:
>
> [WARNING] This release requires PostgreSQL server 9.5.14 but the engine
> database is currently hosted on PostgreSQL server 9.2.24.
>
> Then finally:
> [ ERROR ] It seems that you are running your engine inside of the
> hosted-engine VM and are not in "Global Maintenance" mode.
>  In that case you should put the system into the "Global
> Maintenance" mode before running engine-setup, or the hosted-engine HA
> agent might kill the machine, which might corrupt your data.
>
> [ ERROR ] Failed to execute stage 'Setup validation': Hosted Engine setup
> detected, but Global Maintenance is not set.
> [ INFO  ] Stage: Clean up
>   Log file is located at
> /var/log/ovirt-engine/setup/ovirt-engine-setup-20190725124653-hvekp2.log
> [ INFO  ] Generating answer file
> '/var/lib/ovirt-engine/setup/answers/20190725125154-setup.conf'
> [ INFO  ] Stage: Pre-termination
> [ INFO  ] Stage: Termination
> [ ERROR ] Execution of setup failed
>
> I have put the cluster on global maintenance, though the engine thinks it
> is not.
>
> Are any steps that I may follow to avoid above?
> I am attaching also the last full setup log.
> Thank you!
>
> Alex
>
>
>
>
___
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/LGTG2Q2IYBVVZXDPRXP53BOTFBKBOMXK/

[ovirt-users] Re: System unable to recover after a crash

[Alex K]

On Fri, Jul 12, 2019, 22:30 carl langlois  wrote:

> Hi ,
>
> I am in state where my system does not recover from a major failure. I
> have pinpoint the probleme to be that the hosted engine storage domain is
> not able to mount
>
> I have a glusterfs containing the storage domain. but when it attempt to
> mount glusterfs to /rhev/data-center/mnt/glusterSD/ovhost1:_engine i get
>
>
> +--+
> [2019-07-12 19:19:44.063608] I [rpc-clnt.c:1986:rpc_clnt_reconfig]
> 0-engine-client-2: changing port to 49153 (from 0)
> [2019-07-12 19:19:55.033725] I [fuse-bridge.c:4205:fuse_init]
> 0-glusterfs-fuse: FUSE inited with protocol versions: glusterfs 7.24 kernel
> 7.22
> [2019-07-12 19:19:55.033748] I [fuse-bridge.c:4835:fuse_graph_sync]
> 0-fuse: switched to graph 0
> [2019-07-12 19:19:55.033895] I [MSGID: 108006]
> [afr-common.c:5372:afr_local_init] 0-engine-replicate-0: no subvolumes up
> [2019-07-12 19:19:55.033938] E [fuse-bridge.c:4271:fuse_first_lookup]
> 0-fuse: first lookup on root failed (Transport endpoint is not connected)
> [2019-07-12 19:19:55.034041] W [fuse-resolve.c:132:fuse_resolve_gfid_cbk]
> 0-fuse: ----0001: failed to resolve (Transport
> endpoint is not connected)
> [2019-07-12 19:19:55.034060] E [fuse-bridge.c:900:fuse_getattr_resume]
> 0-glusterfs-fuse: 2: GETATTR 1 (----0001)
> resolution failed
> [2019-07-12 19:19:55.034095] W [fuse-resolve.c:132:fuse_resolve_gfid_cbk]
> 0-fuse: ----0001: failed to resolve (Transport
> endpoint is not connected)
> [2019-07-12 19:19:55.034102] E [fuse-bridge.c:900:fuse_getattr_resume]
> 0-glusterfs-fuse: 3: GETATTR 1 (----0001)
> resolution failed
> [2019-07-12 19:19:55.035596] W [fuse-resolve.c:132:fuse_resolve_gfid_cbk]
> 0-fuse: ----0001: failed to resolve (Transport
> endpoint is not connected)
> [2019-07-12 19:19:55.035611] E [fuse-bridge.c:900:fuse_getattr_resume]
> 0-glusterfs-fuse: 4: GETATTR 1 (----0001)
> resolution failed
> [2019-07-12 19:19:55.047957] I [fuse-bridge.c:5093:fuse_thread_proc]
> 0-fuse: initating unmount of /rhev/data-center/mnt/glusterSD/ovhost1:_engine
> The message "I [MSGID: 108006] [afr-common.c:5372:afr_local_init]
> 0-engine-replicate-0: no subvolumes up" repeated 3 times between
> [2019-07-12 19:19:55.033895] and [2019-07-12 19:19:55.035588]
> [2019-07-12 19:19:55.048138] W [glusterfsd.c:1375:cleanup_and_exit]
> (-->/lib64/libpthread.so.0(+0x7e25) [0x7f51cecb3e25]
> -->/usr/sbin/glusterfs(glusterfs_sigwaiter+0xe5) [0x5632143bd4b5]
> -->/usr/sbin/glusterfs(cleanup_and_exit+0x6b) [0x5632143bd32b] ) 0-:
> received signum (15), shutting down
> [2019-07-12 19:19:55.048150] I [fuse-bridge.c:5852:fini] 0-fuse:
> Unmounting '/rhev/data-center/mnt/glusterSD/ovhost1:_engine'.
> [2019-07-12 19:19:55.048155] I [fuse-bridge.c:5857:fini] 0-fuse: Closing
> fuse connection to '/rhev/data-center/mnt/glusterSD/ovhost1:_engine'.
> [2019-07-12 19:19:56.029923] I [MSGID: 100030] [glusterfsd.c:2511:main]
> 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.12.11
> (args: /usr/sbin/glusterfs --volfile-server=ovhost1
> --volfile-server=ovhost2 --volfile-server=ovhost3 --volfile-id=/engine
> /rhev/data-center/mnt/glusterSD/ovhost1:_engine)
> [2019-07-12 19:19:56.032209] W [MSGID: 101002]
> [options.c:995:xl_opt_validate] 0-glusterfs: option 'address-family' is
> deprecated, preferred is 'transport.address-family', continuing with
> correction
> [2019-07-12 19:19:56.037510] I [MSGID: 101190]
> [event-epoll.c:613:event_dispatch_epoll_worker] 0-epoll: Started thread
> with index 1
> [2019-07-12 19:19:56.039618] I [MSGID: 101190]
> [event-epoll.c:613:event_dispatch_epoll_worker] 0-epoll: Started thread
> with index 2
> [2019-07-12 19:19:56.039691] W [MSGID: 101174]
> [graph.c:363:_log_if_unknown_option] 0-engine-readdir-ahead: option
> 'parallel-readdir' is not recognized
> [2019-07-12 19:19:56.039739] I [MSGID: 114020] [client.c:2360:notify]
> 0-engine-client-0: parent translators are ready, attempting connect on
> transport
> [2019-07-12 19:19:56.043324] I [MSGID: 114020] [client.c:2360:notify]
> 0-engine-client-1: parent translators are ready, attempting connect on
> transport
> [2019-07-12 19:19:56.043481] I [rpc-clnt.c:1986:rpc_clnt_reconfig]
> 0-engine-client-0: changing port to 49153 (from 0)
> [2019-07-12 19:19:56.048539] I [MSGID: 114020] [client.c:2360:notify]
> 0-engine-client-2: parent translators are ready, attempting connect on
> transport
> [2019-07-12 19:19:56.048952] I [rpc-clnt.c:1986:rpc_clnt_reconfig]
> 0-engine-client-1: changing port to 49153 (from 0)
> Final graph:
>
> without this mount point the ha-agent is not starting.
>
> the volume seem to be okey
>
>
> Gluster process TCP Port  RDMA Port  Online
>  Pid
>
> 

[ovirt-users] Re: Manual Migration not working and Dashboard broken after 4.3.4 update

[Alex K]

On Thu, Jul 11, 2019 at 7:57 AM Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
>
> On 11 Jul 2019, at 06:34, Alex K  wrote:
>
>
>
> On Tue, Jul 9, 2019, 19:10 Michal Skrivanek 
> wrote:
>
>>
>>
>> On 9 Jul 2019, at 17:16, Strahil  wrote:
>>
>> I'm not sure, but I always thought that you need  an agent for live
>> migrations.
>>
>>
>> You don’t. For snapshots, and other less important stuff like reporting
>> IPs you do. In 4.3 you should be fine with qemu-ga only
>>
> I've seen resolving live migration issues by installing newer versions of
> ovirt ga.
>
>
> Hm, it shouldn’t make any difference whatsoever. Do you have any concrete
> data? that would help.
>
That is some time ago when runnign 4.1. No data unfortunately. Also did not
expect ovirt ga to affect migration, but experience showed me that it did.
The only observation is that it affected only Windows VMs. Linux VMs never
had an issue, regardless of ovirt ga.

> You can always try installing either qemu-guest-agent  or
>> ovirt-guest-agent and check if live  migration between hosts is possible.
>>
>> Have you set the new cluster/dc version ?
>>
>> Best Regards
>> Strahil Nikolov
>> On Jul 9, 2019 17:42, Neil  wrote:
>>
>> I remember seeing the bug earlier but because it was closed thought it
>> was unrelated, this appears to be it
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1670701
>>
>> Perhaps I'm not understanding your question about the VM guest agent, but
>> I don't have any guest agent currently installed on the VM, not sure if the
>> output of my qemu-kvm process maybe answers this question?
>>
>> /usr/libexec/qemu-kvm -name
>> guest=Headoffice.cbl-ho.local,debug-threads=on -S -object
>> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-Headoffice.cbl-ho.lo/master-key.aes
>> -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu
>> Broadwell,vme=on,f16c=on,rdrand=on,hypervisor=on,arat=on,xsaveopt=on,abm=on,rtm=on,hle=on
>> -m 8192 -realtime mlock=off -smp 8,maxcpus=64,sockets=16,cores=4,threads=1
>> -numa node,nodeid=0,cpus=0-7,mem=8192 -uuid
>> 9a6561b8-5702-43dc-9e92-1dc5dfed4eef -smbios
>> type=1,manufacturer=oVirt,product=oVirt
>> Node,version=7-3.1611.el7.centos,serial=4C4C4544-0034-5810-8033-
>>
>>
> It’s 7.3, likely oVirt 4.1. Please upgrade...
>
> C2C04F4E4B32,uuid=9a6561b8-5702-43dc-9e92-1dc5dfed4eef -no-user-config
>> -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon
>> chardev=charmonitor,id=monitor,mode=control -rtc
>> base=2019-07-09T10:26:53,driftfix=slew -global
>> kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on
>> -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
>> virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device
>> virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -drive
>> if=none,id=drive-ide0-1-0,readonly=on -device
>> ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
>> file=/rhev/data-center/59831b91-00a5-01e4-0294-0018/8a607f8a-542a-473c-bb18-25c05fe2a3d4/images/56e8240c-a172-4f52-b0c1-2bddc4f34f93/9f245467-d31d-4f5a-8037-7c5012a4aa84,format=qcow2,if=none,id=drive-virtio-disk0,serial=56e8240c-a172-4f52-b0c1-2bddc4f34f93,werror=stop,rerror=stop,cache=none,aio=native
>> -device
>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on
>> -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device
>> virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:5b,bus=pci.0,addr=0x3
>> -chardev socket,id=charchannel0,fd=35,server,nowait -device
>> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm
>> -chardev socket,id=charchannel1,fd=36,server,nowait -device
>> virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
>> -chardev spicevmc,id=charchannel2,name=vdagent -device
>> virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0
>> -spice 
>> tls-port=5900,addr=10.0.1.11,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=default,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on
>> -device
>> qxl-vga,id=video0,ram_size=67108864,vram_size=8388608,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2
>> -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
>> -object r

[ovirt-users] Re: Manual Migration not working and Dashboard broken after 4.3.4 update

[Alex K]

On Tue, Jul 9, 2019, 19:10 Michal Skrivanek 
wrote:

>
>
> On 9 Jul 2019, at 17:16, Strahil  wrote:
>
> I'm not sure, but I always thought that you need  an agent for live
> migrations.
>
>
> You don’t. For snapshots, and other less important stuff like reporting
> IPs you do. In 4.3 you should be fine with qemu-ga only
>
I've seen resolving live migration issues by installing newer versions of
ovirt ga.

> You can always try installing either qemu-guest-agent  or
> ovirt-guest-agent and check if live  migration between hosts is possible.
>
> Have you set the new cluster/dc version ?
>
> Best Regards
> Strahil Nikolov
> On Jul 9, 2019 17:42, Neil  wrote:
>
> I remember seeing the bug earlier but because it was closed thought it was
> unrelated, this appears to be it
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1670701
>
> Perhaps I'm not understanding your question about the VM guest agent, but
> I don't have any guest agent currently installed on the VM, not sure if the
> output of my qemu-kvm process maybe answers this question?
>
> /usr/libexec/qemu-kvm -name guest=Headoffice.cbl-ho.local,debug-threads=on
> -S -object
> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-Headoffice.cbl-ho.lo/master-key.aes
> -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu
> Broadwell,vme=on,f16c=on,rdrand=on,hypervisor=on,arat=on,xsaveopt=on,abm=on,rtm=on,hle=on
> -m 8192 -realtime mlock=off -smp 8,maxcpus=64,sockets=16,cores=4,threads=1
> -numa node,nodeid=0,cpus=0-7,mem=8192 -uuid
> 9a6561b8-5702-43dc-9e92-1dc5dfed4eef -smbios
> type=1,manufacturer=oVirt,product=oVirt
> Node,version=7-3.1611.el7.centos,serial=4C4C4544-0034-5810-8033-C2C04F4E4B32,uuid=9a6561b8-5702-43dc-9e92-1dc5dfed4eef
> -no-user-config -nodefaults -chardev
> socket,id=charmonitor,fd=31,server,nowait -mon
> chardev=charmonitor,id=monitor,mode=control -rtc
> base=2019-07-09T10:26:53,driftfix=slew -global
> kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on
> -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
> virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device
> virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -drive
> if=none,id=drive-ide0-1-0,readonly=on -device
> ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
> file=/rhev/data-center/59831b91-00a5-01e4-0294-0018/8a607f8a-542a-473c-bb18-25c05fe2a3d4/images/56e8240c-a172-4f52-b0c1-2bddc4f34f93/9f245467-d31d-4f5a-8037-7c5012a4aa84,format=qcow2,if=none,id=drive-virtio-disk0,serial=56e8240c-a172-4f52-b0c1-2bddc4f34f93,werror=stop,rerror=stop,cache=none,aio=native
> -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on
> -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:5b,bus=pci.0,addr=0x3
> -chardev socket,id=charchannel0,fd=35,server,nowait -device
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm
> -chardev socket,id=charchannel1,fd=36,server,nowait -device
> virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
> -chardev spicevmc,id=charchannel2,name=vdagent -device
> virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0
> -spice 
> tls-port=5900,addr=10.0.1.11,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=default,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on
> -device
> qxl-vga,id=video0,ram_size=67108864,vram_size=8388608,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2
> -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
> -object rng-random,id=objrng0,filename=/dev/urandom -device
> virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x8 -sandbox
> on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
> -msg timestamp=on
>
> Please shout if you need further info.
>
> Thanks.
>
>
>
>
>
>
> On Tue, Jul 9, 2019 at 4:17 PM Strahil Nikolov 
> wrote:
>
> Shouldn't cause that problem.
>
> You have to find the bug in bugzilla and report a regression (if it's not
> closed) , or open a new one and report the regression.
> As far as I remember , only the dashboard was affected due to new features
> about vdo disk savings.
>
> ___
> 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/IQCHU3VAIQQCG7NSBYK5UMZYFRTJ7B2E/
>
> ___
> Users mailing list -- users@ovirt.org
> 

[ovirt-users] Re: Manual Migration not working and Dashboard broken after 4.3.4 update

[Alex K]

On Wed, Jul 10, 2019, 14:57 Neil  wrote:

> To provide a slight update on this.
>
> I put one of my hosts into maintenance and it then migrated the two VM's
> off of it, I then upgraded the host to 4.3.
>
> I have 12 VM's running on the remaining host, if I put it into maintenance
> will it try migrate all 12 VM's at once or will it stagger them until they
> are all migrated?
>
If you have a good migration network (at least 10Gbps) the it should be
fine. You could also just manually migrate one by one.

>
> Thank you.
>
> Regards.
>
> Neil Wilson.
>
>
>
>
>
>
> On Wed, Jul 10, 2019 at 9:44 AM Neil  wrote:
>
>> Hi Michal,
>>
>> Thanks for assisting.
>>
>> I've just done as requested however nothing is logged in the engine.log
>> at the time I click Migrate, below is the log and I hit the Migrate button
>> about 4 times between 09:35 and 09:36 and nothing was logged about this...
>>
>> 2019-07-10 09:35:57,967+02 INFO
>>  [org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-14) []
>> User trouble@internal successfully logged in with scopes:
>> ovirt-app-admin ovirt-app-api ovirt-app-portal
>> ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all
>> ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search
>> ovirt-ext=token-info:validate ovirt-ext=token:password-access
>> 2019-07-10 09:35:58,012+02 INFO
>>  [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-14)
>> [2997034] Running command: CreateUserSessionCommand internal: false.
>> 2019-07-10 09:35:58,021+02 INFO
>>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-14) [2997034] EVENT_ID: USER_VDC_LOGIN(30), User
>> trouble@internal-authz connecting from '160.128.20.85' using session
>> 'bv55G0wZznETUiQwjgjfUNje7wOsG4UDCuFunSslVeAFQkhdY2zzTY7du36ynTF5nW5U7JiPyr7gl9QDHfWuig=='
>> logged in.
>> 2019-07-10 09:36:58,304+02 INFO
>>  [org.ovirt.engine.core.bll.utils.ThreadPoolMonitoringService]
>> (EE-ManagedThreadFactory-engineThreadMonitoring-Thread-1) [] Thread pool
>> 'default' is using 0 threads out of 1, 5 threads waiting for tasks.
>> 2019-07-10 09:36:58,305+02 INFO
>>  [org.ovirt.engine.core.bll.utils.ThreadPoolMonitoringService]
>> (EE-ManagedThreadFactory-engineThreadMonitoring-Thread-1) [] Thread pool
>> 'engine' is using 0 threads out of 500, 16 threads waiting for tasks and 0
>> tasks in queue.
>> 2019-07-10 09:36:58,305+02 INFO
>>  [org.ovirt.engine.core.bll.utils.ThreadPoolMonitoringService]
>> (EE-ManagedThreadFactory-engineThreadMonitoring-Thread-1) [] Thread pool
>> 'engineScheduled' is using 0 threads out of 100, 100 threads waiting for
>> tasks.
>> 2019-07-10 09:36:58,305+02 INFO
>>  [org.ovirt.engine.core.bll.utils.ThreadPoolMonitoringService]
>> (EE-ManagedThreadFactory-engineThreadMonitoring-Thread-1) [] Thread pool
>> 'engineThreadMonitoring' is using 1 threads out of 1, 0 threads waiting for
>> tasks.
>> 2019-07-10 09:36:58,305+02 INFO
>>  [org.ovirt.engine.core.bll.utils.ThreadPoolMonitoringService]
>> (EE-ManagedThreadFactory-engineThreadMonitoring-Thread-1) [] Thread pool
>> 'hostUpdatesChecker' is using 0 threads out of 5, 2 threads waiting for
>> tasks.
>>
>> The same is observed in the vdsm.log too, below is the log during the
>> attempted migration
>>
>> 2019-07-10 09:39:57,034+0200 INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer]
>> RPC call Host.getStats succeeded in 0.01 seconds (__init__:573)
>> 2019-07-10 09:39:57,994+0200 INFO  (jsonrpc/2) [api.host] START
>> getStats() from=:::10.0.1.1,57934 (api:46)
>> 2019-07-10 09:39:57,994+0200 INFO  (jsonrpc/2) [vdsm.api] START
>> repoStats(domains=()) from=:::10.0.1.1,57934,
>> task_id=e2529cfc-4293-42b4-91fa-7f5558e279dd (api:46)
>> 2019-07-10 09:39:57,994+0200 INFO  (jsonrpc/2) [vdsm.api] FINISH
>> repoStats return={u'8a607f8a-542a-473c-bb18-25c05fe2a3d4': {'code': 0,
>> 'actual': True, 'version': 4, 'acquired': True, 'delay': '0.000194846',
>> 'lastCheck': '2.4', 'valid': True},
>> u'37b1a5d7-4e29-4763-9337-63c51dbc5fc8': {'code': 0, 'actual': True,
>> 'version': 0, 'acquired': True, 'delay': '0.000277154', 'lastCheck': '6.0',
>> 'valid': True}, u'2558679a-2214-466b-8f05-06fdda9146e5': {'code': 0,
>> 'actual': True, 'version': 4, 'acquired': True, 'delay': '0.000421988',
>> 'lastCheck': '2.4', 'valid': True},
>> u'640a5875-3d82-43c0-860f-7bb3e4a7e6f0': {'code': 0, 'actual': True,
>> 'version': 4, 'acquired': True, 'delay': '0.000228443', 'lastCheck': '2.4',
>> 'valid': True}} from=:::10.0.1.1,57934,
>> task_id=e2529cfc-4293-42b4-91fa-7f5558e279dd (api:52)
>> 2019-07-10 09:39:57,995+0200 INFO  (jsonrpc/2) [vdsm.api] START
>> multipath_health() from=:::10.0.1.1,57934,
>> task_id=fd7ad703-5096-4f09-99fa-54672cb4aad9 (api:46)
>> 2019-07-10 09:39:57,995+0200 INFO  (jsonrpc/2) [vdsm.api] FINISH
>> multipath_health return={} from=:::10.0.1.1,57934,
>> task_id=fd7ad703-5096-4f09-99fa-54672cb4aad9 (api:52)
>> 2019-07-10 09:39:58,002+0200 INFO  (jsonrpc/2) [api.host] FINISH 

[ovirt-users] Re: Upgrade engine to 4.3.3 or setup a new engine

[Alex K]

On Thu, May 9, 2019, 16:39 Magnus Isaksson  wrote:

> Hello all
>
> I'm having trouble upgrading my engine to 4.3.3 from 4.2.8
> The upgrade goes well, no errors but webgui wont load, it just says
> "waiting for engine"
>
> I have tried to set up a new machine with engine and import the DB from
> the old(after upgrade) still the same problem.
>
> So after quite a few tries i gave up and set up a fresh new engine 4.3.3
> But can i move/migrate the hosts with running VM:s in to the new engine?
> In vmware vcenter it is just to add the host and all VM:s and stuff comes
> over, but im guessing from what ive read that it is not that simple with
> ovirt.
> Or how should i solve this?
>
I would try to import the db into the new engine.

>
> //Magnus
> ___
> 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/XEPQMW5R4JG5SZHX2DO2MC7LSO74BZAH/
>
___
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/FYQVBNAVVD4KSQ5GWOYFPYSA44TY2AUJ/

[ovirt-users] Re: Migrating Domain Storage Gluster

[Alex K]

On Thu, May 9, 2019, 20:57 Alex McWhirter  wrote:

> Basically i want to take out all of the HDD's in the main gluster pool,
> and replace with SSD's.
>
> My thought was to put everything in maintenance, copy the data manually
> over to a transient storage server. Destroy the gluster volume, swap in
> all the new drives, build a new gluster volume with the same name /
> settings, move data back, and be done.
>
> Any thoughts on this?
>
Seems ok if you can afford downtime. Otherwise you can go one node at a
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/TP6V2OYG5ZXPU53TYB6PVQMOCHFBA3NA/
>
___
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/EQYZIC5V7VSODRMJZT6N24KZ4JYWSHRX/