date:20200730

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?

2020-07-30 Thread Philip Brown

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.



- 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/MXWWVPB7IDSKYI3H42BGO4WMBRBFRRMN/

[ovirt-users] Re: 10GB disk created on glusterfs storage has only 4096B in vm

2020-07-30 Thread Strahil Nikolov via Users

Damn,  those thick fingers...

На 30 юли 2020 г. 23:12:00 GMT+03:00, Strahil Nikolov  
написа:
>I  have been using 7.6 (and rewntly migrated to 7.7) on my oVirt 4.3.10
> withkut any issues  so far.
>
>Are  you sure that it's  not  oVirt 4.4 specific  ?
>
>Best  Regards,
>Strahil Nikolov
>
>На 30 юли 2020 г. 15:03:17 GMT+03:00, shadow emy
> написа:
>>Good that is ok for you now.
>>As Gianluca told you the command to see all the gluster volume
>settings
>>is : gluster volume get vol_name all
>>
>>The previous command you used : gluster volume info vol_name   will
>>list only modified settings from default and not all the settings. The
>>output shows only volume "Options Reconfigured". 
>>
>>Regarding if this is an important bug that affects gluster 7.6(or
>other
>>versions) and should be disabled by default, i dont know for sure.
>>I am just using ovirt as a hyperconvergence tool.
>> Maybe someone from the ovirt development team can answer that.
>>___
>>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/EFVT6AMOI4IQJKR6SURWNEMWVY622Y6T/
___
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/M6URBE72HWPTLPITFW2W3VXHXVTVJU2T/

[ovirt-users] Re: 10GB disk created on glusterfs storage has only 4096B in vm

2020-07-30 Thread Strahil Nikolov via Users

I  have been using 7.6 (and rewntly migrated to 7.7) on my oVirt 4.3.10  
withkut any issues  so far.

Are  you sure that it's  not  oVirt 4.4 specific  ?

Best  Regards,
Strahil Nikolov

На 30 юли 2020 г. 15:03:17 GMT+03:00, shadow emy  написа:
>Good that is ok for you now.
>As Gianluca told you the command to see all the gluster volume settings
>is : gluster volume get vol_name all
>
>The previous command you used : gluster volume info vol_name   will
>list only modified settings from default and not all the settings. The
>output shows only volume "Options Reconfigured". 
>
>Regarding if this is an important bug that affects gluster 7.6(or other
>versions) and should be disabled by default, i dont know for sure.
>I am just using ovirt as a hyperconvergence tool.
> Maybe someone from the ovirt development team can answer that.
>___
>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/EFVT6AMOI4IQJKR6SURWNEMWVY622Y6T/
___
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/EFGXM6J6PRZAMC37CXEQNE6XWJI7ZCMA/

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

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] best way to have storage vlan available to host AND vms?

2020-07-30 Thread Philip Brown

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?


--
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/

[ovirt-users] Re: PKI Problem

2020-07-30 Thread Ramon Clematide

HI Nir

Thank you. Yes exactly, another parameter different to config.tls.ca_file would 
be nice.

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/EEKJFVQ7QUZB4UBZC2VKGN6V4QZJOEWI/

[ovirt-users] Re: Problem with paused VMs in ovirt 4.3.10.

+Arik Hadas  can you please have a look here?

Il giorno lun 27 lug 2020 alle ore 09:09 Dmitry Sekretev <
dmitry.sekre...@profitclicks.ru> ha scritto:

> Hi!
> We have a problem with paused VMs in ovirt cluster. Please, help to solve
> this.
> In ovirt manager massege "VM rtb-stagedsw02-ovh has been paused."
> Resume fails with error "Failed to resume VM rtb-stagedsw02-ovh (Host:
> ovirt-node09-ovh.local, User: admin@internal-authz)."
> In oVirt Cluster 38 VM, paused VM only ubuntu 20.04 focal with docker
> swarm.
> Archived logs in attach.
>
> Packeges on ovirt nodes:
> python2-ovirt-setup-lib-1.2.0-1.el7.noarch
> ovirt-vmconsole-1.0.7-2.el7.noarch
> ovirt-provider-ovn-driver-1.2.29-1.el7.noarch
> ovirt-vmconsole-host-1.0.7-2.el7.noarch
> python2-ovirt-host-deploy-1.8.5-1.el7.noarch
> ovirt-imageio-common-1.5.3-0.el7.x86_64
> cockpit-machines-ovirt-195.6-1.el7.centos.noarch
> ovirt-ansible-engine-setup-1.1.9-1.el7.noarch
> ovirt-host-dependencies-4.3.5-1.el7.x86_64
> ovirt-host-4.3.5-1.el7.x86_64
> python-ovirt-engine-sdk4-4.3.4-2.el7.x86_64
> ovirt-host-deploy-common-1.8.5-1.el7.noarch
> ovirt-ansible-hosted-engine-setup-1.0.32-1.el7.noarch
> ovirt-hosted-engine-setup-2.3.13-1.el7.noarch
> ovirt-ansible-repositories-1.1.5-1.el7.noarch
> ovirt-imageio-daemon-1.5.3-0.el7.noarch
> cockpit-ovirt-dashboard-0.13.10-1.el7.noarch
> ovirt-release43-4.3.10-1.el7.noarch
> ovirt-hosted-engine-ha-2.3.6-1.el7.noarch
> Packeges on HostedEngine:
>
> ovirt-ansible-infra-1.1.13-1.el7.noarch
> ovirt-vmconsole-1.0.7-2.el7.noarch
> ovirt-engine-setup-plugin-websocket-proxy-4.3.10.4-1.el7.noarch
> ovirt-engine-websocket-proxy-4.3.10.4-1.el7.noarch
> ovirt-engine-restapi-4.3.10.4-1.el7.noarch
> ovirt-ansible-engine-setup-1.1.9-1.el7.noarch
> ovirt-ansible-shutdown-env-1.0.3-1.el7.noarch
> ovirt-iso-uploader-4.3.2-1.el7.noarch
> ovirt-provider-ovn-1.2.29-1.el7.noarch
> ovirt-imageio-proxy-setup-1.5.3-0.el7.noarch
> ovirt-engine-extension-aaa-ldap-setup-1.3.10-1.el7.noarch
> ovirt-engine-setup-plugin-vmconsole-proxy-helper-4.3.10.4-1.el7.noarch
> python-ovirt-engine-sdk4-4.3.4-2.el7.x86_64
> python2-ovirt-host-deploy-1.8.5-1.el7.noarch
> ovirt-ansible-vm-infra-1.1.22-1.el7.noarch
> ovirt-engine-metrics-1.3.7-1.el7.noarch
> ovirt-ansible-disaster-recovery-1.2.0-1.el7.noarch
> ovirt-engine-wildfly-overlay-17.0.1-1.el7.noarch
> ovirt-ansible-roles-1.1.7-1.el7.noarch
> ovirt-engine-dwh-setup-4.3.8-1.el7.noarch
> python2-ovirt-engine-lib-4.3.10.4-1.el7.noarch
> ovirt-engine-extension-aaa-ldap-1.3.10-1.el7.noarch
> ovirt-engine-setup-plugin-ovirt-engine-4.3.10.4-1.el7.noarch
> ovirt-engine-vmconsole-proxy-helper-4.3.10.4-1.el7.noarch
> ovirt-engine-tools-backup-4.3.10.4-1.el7.noarch
> ovirt-engine-webadmin-portal-4.3.10.4-1.el7.noarch
> ovirt-host-deploy-common-1.8.5-1.el7.noarch
> ovirt-ansible-image-template-1.1.12-1.el7.noarch
> ovirt-ansible-manageiq-1.1.14-1.el7.noarch
> ovirt-engine-wildfly-17.0.1-1.el7.x86_64
> ovirt-ansible-hosted-engine-setup-1.0.32-1.el7.noarch
> ovirt-imageio-common-1.5.3-0.el7.x86_64
> ovirt-imageio-proxy-1.5.3-0.el7.noarch
> python2-ovirt-setup-lib-1.2.0-1.el7.noarch
> ovirt-vmconsole-proxy-1.0.7-2.el7.noarch
> ovirt-engine-setup-base-4.3.10.4-1.el7.noarch
> ovirt-engine-setup-plugin-cinderlib-4.3.10.4-1.el7.noarch
> ovirt-engine-extensions-api-impl-4.3.10.4-1.el7.noarch
> ovirt-release43-4.3.10-1.el7.noarch
> ovirt-engine-backend-4.3.10.4-1.el7.noarch
> ovirt-engine-tools-4.3.10.4-1.el7.noarch
> ovirt-web-ui-1.6.0-1.el7.noarch
> ovirt-ansible-cluster-upgrade-1.1.14-1.el7.noarch
> ovirt-cockpit-sso-0.1.1-1.el7.noarch
> ovirt-engine-ui-extensions-1.0.10-1.el7.noarch
> ovirt-engine-setup-plugin-ovirt-engine-common-4.3.10.4-1.el7.noarch
> ovirt-engine-4.3.10.4-1.el7.noarch
> ovirt-ansible-repositories-1.1.5-1.el7.noarch
> ovirt-engine-extension-aaa-jdbc-1.1.10-1.el7.noarch
> ovirt-host-deploy-java-1.8.5-1.el7.noarch
> ovirt-engine-dwh-4.3.8-1.el7.noarch
> ovirt-engine-api-explorer-0.0.5-1.el7.noarch
> ovirt-guest-agent-common-1.0.16-1.el7.noarch
> ovirt-engine-setup-4.3.10.4-1.el7.noarch
> ovirt-engine-dbscripts-4.3.10.4-1.el7.noarch
>
> In /var/log/ovirt-engine/engine.log:
>
> 2020-07-24 09:38:44,472+03 INFO
> [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer]
> (EE-ManagedThreadFactory-engineScheduled-Thread-91) [] VM
> '18f6bb79-ba9b-4a0e-bcb2-b4ef4904ef99'(rtb-stagedsw02-ovh) move
> d from 'Up' --> 'Paused'
> 2020-07-24 09:38:44,493+03 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engineScheduled-Thread-91) [] EVENT_ID:
> VM_PAUSED(1,025), VM rtb-stagedsw02-ovh has been paused.
>
> In /var/log/vdsm/vdsm.log
>
> 2020-07-24 09:38:42,771+0300 INFO  (libvirt/events) [virt.vm]
> (vmId='18f6bb79-ba9b-4a0e-bcb2-b4ef4904ef99') CPU stopped: onSuspend
> (vm:6100)
> 2020-07-24 09:38:44,328+0300 INFO  (jsonrpc/1) [api.host] FINISH
> getAllVmIoTunePolicies return={'status': {'message': 'Done', 'code': 0},
> 'io_tune_policies_dict':

[ovirt-users] [ANN] oVirt 4.4.2 First Release Candidate is now available for testing

2020-07-30 Thread Lev Veyde

oVirt 4.4.2 First Release Candidate is now available for testing

The oVirt Project is pleased to announce the availability of oVirt 4.4.2
First Release Candidate for testing, as of July 30h, 2020.

This update is the second in a series of stabilization updates to the 4.4
series.
Important notes before you try it

Please note this is a pre-release build.

The oVirt Project makes no guarantees as to its suitability or usefulness.

This pre-release must not be used in production.
Installation instructions

For the engine: either use appliance or:

- Install CentOS Linux 8.2 minimal from:

https://mirrors.edge.kernel.org/centos/8.2.2004/isos/x86_64/CentOS-8.2.2004-x86_64-minimal.iso

- dnf install
https://resources.ovirt.org/pub/yum-repo/ovirt-release44-pre.rpm

- dnf update (reboot if needed)

- dnf module enable -y javapackages-tools pki-deps postgresql:12

- dnf install ovirt-engine

- engine-setup

For the nodes:

Either use oVirt Node ISO or:

- Install CentOS Linux 8.2 from

https://mirrors.edge.kernel.org/centos/8.2.2004/isos/x86_64/CentOS-8.2.2004-x86_64-minimal.iso
; select minimal installation

- dnf install
https://resources.ovirt.org/pub/yum-repo/ovirt-release44-pre.rpm

- dnf update (reboot if needed)

- Attach the host to the engine and let it be deployed.



This release is available now on x86_64 architecture for:

* Red Hat Enterprise Linux 8.2 or newer

* CentOS Linux (or similar) 8.2 or newer

This release supports Hypervisor Hosts on x86_64 and ppc64le architectures
for:

* Red Hat Enterprise Linux 8.2 or newer

* CentOS Linux (or similar) 8.2 or newer

* oVirt Node 4.4 based on CentOS Linux 8.2 (available for x86_64 only)

See the release notes [1] for installation instructions and a list of new
features and bugs fixed.

Notes:

- oVirt Appliance is already available for CentOS Linux 8

- oVirt Node NG is already available for CentOS Linux 8

Additional Resources:

* Read more about the oVirt 4.4.2 release highlights:
http://www.ovirt.org/release/4.4.2/

* Get more oVirt project updates on Twitter: https://twitter.com/ovirt

* Check out the latest project news on the oVirt blog:
http://www.ovirt.org/blog/


[1] http://www.ovirt.org/release/4.4.2/

[2] http://resources.ovirt.org/pub/ovirt-4.4-pre/iso/

-- 

Lev Veyde

Senior Software Engineer, RHCE | RHCVA | MCITP

Red Hat Israel



l...@redhat.com | lve...@redhat.com

TRIED. TESTED. TRUSTED. 
___
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/YPUKLEEKBKTIC7UA7YGL4QEYTLNSCVUS/

[ovirt-users] Re: oVirt 4.4 Self-Hosted Installation failed

Il giorno lun 27 lug 2020 alle ore 21:00  ha
scritto:

> Hi There!
>
> I'm trying to install oVirt self-hosted on Fedora 32 with kvm and the
> install failed.


Hi, despite we would love to be able to support Fedora we had to give up
trying to support it.
You can read more at https://blogs.ovirt.org/2020/05/ovirt-and-fedora/
I would suggest to use CentOS Linux 8  or CentOS Stream 8 as an alternative.

Cheers,
-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.*
___
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/ERLA6WSGFNL62SVODQ7R5CNDRN3WPYUA/

[ovirt-users] Re: Windows TimeZone UTC

Il giorno dom 26 lug 2020 alle ore 16:15 Arik Hadas  ha
scritto:

>
>
> On Sun, Jul 26, 2020 at 4:39 PM Liran Rotenberg 
> wrote:
>
>>
>>
>> On Sun, Jul 26, 2020 at 11:52 AM Erez Zarum  wrote:
>>
>>> Hey Liran,
>>> I still don't understand from those resources how can i add an "extra"
>>> timezone that is not "compiled" into Engine?
>>> Is there a possibility you can write one here? I fear to mess up the
>>> Engine.
>>>
>> Hi, I'm afraid not. There is no option to add a new one.
>> The only options you have for windows are:
>>
>> https://docs.microsoft.com/en-us/previous-versions/windows/embedded/ms912391(v=winembedded.11)?redirectedfrom=MSDN
>> As can be seen in:
>>
>> https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/TimeZoneType.java
>>
>
> (GMT) Greenwich Standard Time should result in offset=0 which will give
> you UTC time inside the guest
>

Looking at above mentioned table I see we have Etc/GMT.
Any specific reason for not adding Etc/UTC to the table too?
It differs from Etc/GMT by a bunch of nanoseconds but we are setting
Etc/UTC by default on oVirt Node and sounds weird not having it as
supported timezone.




>
>
>>
>> ___
>>> 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/4TJBJEW5QF74EKOBEX5TBH2VHSYRSISR/
>>>
>> ___
>> 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/OT2BQH3TJ5Y7IPGFNEE2C4UPMECISUZC/
>>
> ___
> 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/K75CTJ5RBEIMAZMAZ7USFVGTK42GLH67/
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
*
___
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/Y44ZFRL57NSGSOUIZ4TAMLVWHXDQZDNF/

[ovirt-users] Re: oVirt 4.3 ssh passwordless setup guide

Il giorno gio 23 lug 2020 alle ore 20:46 Morris, Roy 
ha scritto:

> Hello,
>
>
>
> Does anyone have a guide or how to on setting up oVirt with passwordless
> ssh setup? I want to do this with a production environment to improve
> security but I have never done this before and want to build a test
> environment to try it out.
>

I think what you are looking for is:
https://wiki.centos.org/HowTos/Network/SecuringSSH#Use_Public.2FPrivate_Keys_for_Authentication
for an explanation about passwordless ssh access.

And then
https://ovirt.org/documentation/administration_guide/#Adding_standard_hosts_to_the_Manager_host_tasks
on how to get the ssh public key to be added on  /root/.ssh/authorized_keys
on your hosts



>
>
> Best regards,
>
> Roy Morris
> ___
> 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/OAEFVXWUIVQCPTO2YYPSUJKHUZKED5ZQ/
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
*
___
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/EYMNS2YWV4GABWJBY2T3JTGWFJTL4NOJ/

[ovirt-users] Changing management network

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] Re: OVA export creates empty and unusable images

2020-07-30 Thread Gianluca Cecchi

On Thu, Jul 30, 2020 at 4:04 PM  wrote:

> Here is the ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1862115
>
>
could it be this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1813028
?
It seems only verified as a status.
Can you check /var/log/ovirt-engine/ova/ (on engine I presume) if you find
similar permission errors inside it?

Gianluca
___
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/J7WLKTVWQXI23735OMFODKP7KDN6XBHS/

[ovirt-users] Re: oVirt 4.4.1 HCI single server deployment failed nested-kvm

2020-07-30 Thread wodel youchi

Hi,

This is not my first time, I have installed ovirt, ovirt-hci, rhv and
rhv-hci on top of a kvm host many times to test some functionality or to
test a new version til this latest version of ovirt 4.4.1

On my first test there was a problem with HCI deployment the gluster part.

Now that part works with the new ovirt-node version but not the vm manager
deployment part.

Regards.

Le jeu. 30 juil. 2020 14:56, Strahil Nikolov via Users  a
écrit :

> I've run  KVM  VMs  ontop  oVirt Guest.  Are  you sure that the Nested
> Virtualization is your problem  ?
> Best Regards,
> Strahil Nikolov
>
> На 29 юли 2020 г. 23:33:48 GMT+03:00, tho...@hoberg.net написа:
> >I tried using nested virtualization, too, a couple of weeks ago.
> >
> >I was using a 3 node HCI CentOS 7.8 cluster and I got pretty far.
> >Configuring KVM to work with nested page tables isn't all that well
> >documented but I got there, I even installed some host extensions, that
> >seem requried.
> >
> >Even the actual nesting, that is a VM run inside a VM did work, the
> >setup came to the point where it ran the hosted engine on temporary
> >local storage, before it's picked up, fixed up to run on the Gluster
> >storage and restarted there. But that process failed eventually,
> >evidently because the overlay network doesn't support nesting. Where
> >the initial hosted engine is using a local bridge with the (in this
> >case virtual) host--and that works--afterwards it's using the overlay
> >network and that evidently doesn't.
> >
> >It was only then when I ran across a very obscure message somewhere in
> >this mailing list, that oVirt on top of oVirt in fact does not work at
> >all! Up to that point it just wasn't "supported".
> >
> >When a hypervisor producer speaks of nested virtualization support, I
> >would understand it to mean that you can run their product under their
> >product, ideally also somebody else's product. I've run ESX on VMware
> >workstation and that was pretty cool.
> >
> >In the case of oVirt from what I have gathered (and I'd love to be
> >wrong), it is supposed to only mean that you can run oVirt on top of
> >KVM.
> >
> >Not the other way around, nor in any other way most likely.
> >
> >To me that looks much more like an internal Redhat development
> >facility, than a product feature.
> >
> >Of course I mostly wish they'd find a way to make it work like it does
> >on VMware.
> >But next on my wishlist would be an explicit description of what does
> >and what doesn't work.
> >
> >This way it was almost a week of a me against the computer adventure
> >where I lost.
> >___
> >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/7WHRDMXMAWW3DPS24X23X3GCY5S2MCZF/
> ___
> 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/XI4G36UJLPKTLMPNEKXBE3CN6UETXLEB/
>
___
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/JINUOPVOYLOQMEHLJ72JFMATO44HA7BN/

[ovirt-users] Re: oVirt 4.4.1 HCI single server deployment failed nested-kvm

2020-07-30 Thread Stefan Wolf

Hello,

I ve the same problem, I ve already set up glusterfs and like to deplay a self 
hosted engine. I ve allready ovirt self hosted engine deployed, with no 
problems. But here I get the same error with hosted-engine --deploy and in the 
web frontend.

[ INFO  ] TASK [ovirt.hosted_engine_setup : Failed if only teaming devices are 
availible]
[ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The conditional check 
'(otopi_host_net.ansible_facts.otopi_host_net | length == 0)' failed. The error 
was: error while evaluating conditional 
((otopi_host_net.ansible_facts.otopi_host_net | length == 0)): 'list object' 
has no attribute 'ansible_facts'\n\nThe error appears to be in 
'/usr/share/ansible/roles/ovirt.hosted_engine_setup/tasks/filter_team_devices.yml':
 line 29, column 13, but may\nbe elsewhere in the file depending on the exact 
syntax problem.\n\nThe offending line appears to be:\n\n- debug: 
var=otopi_host_net\n^ here\n\nThere appears to be both 'k=v' 
shorthand syntax and YAML in this task. Only one syntax may be used.\n"}
[ ERROR ] Failed to execute stage 'Environment customization': Failed executing 
ansible-playbook


is there a solution or just use an older ovirt `node iso?

bye shb
___
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/L2T6ENJRXFLQNJ6DMQ5H4WWV2TJLJJCE/

[ovirt-users] Re: It is possible to export a vm bigger as 5 TB?

Thanks to your log post, I was able to identify the proper place to find 
information about the export process.

OVA exports don't fail for me, but result in empty disks, which is perhaps even 
worse.

Two things I can suggest: Try with a new and smaller VM to see if it's actually 
a size related issue or due to the fact that e.g. the number of disks in an OVA 
export are limited.

The other is to make do with an export domain, which seems to work fine and 
might have less issues with OVA file format constraints: Don't know if you just 
need the backup or want to migrate...
___
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/5ODWFJPBRG5YVNK7DZYVZNYXIY36BRRW/

[ovirt-users] Re: OVA export creates empty and unusable images

Export/Import/Transfer via export domain worked just fine. Just moved my last 
surviving Univention domain controller from the single node HCI 
disaster-recovery farm to the three node HCI primary, where I can now try to 
make it primary and start building new backups...

Backups that do not work are food for nightmares!
___
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/AGK7KEY3RRKOVUBDGYPZO2JCQHIEA2BR/

[ovirt-users] Re: OVA export creates empty and unusable images

Here is the ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1862115 
___
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/W4BMX4FPWL3LVR26K637UJ43YJ7E2KUT/

[ovirt-users] Re: oVirt 4.4.1 HCI single server deployment failed nested-kvm

2020-07-30 Thread Strahil Nikolov via Users

I've run  KVM  VMs  ontop  oVirt Guest.  Are  you sure that the Nested  
Virtualization is your problem  ?
Best Regards,
Strahil Nikolov

На 29 юли 2020 г. 23:33:48 GMT+03:00, tho...@hoberg.net написа:
>I tried using nested virtualization, too, a couple of weeks ago.
>
>I was using a 3 node HCI CentOS 7.8 cluster and I got pretty far.
>Configuring KVM to work with nested page tables isn't all that well
>documented but I got there, I even installed some host extensions, that
>seem requried.
>
>Even the actual nesting, that is a VM run inside a VM did work, the
>setup came to the point where it ran the hosted engine on temporary
>local storage, before it's picked up, fixed up to run on the Gluster
>storage and restarted there. But that process failed eventually,
>evidently because the overlay network doesn't support nesting. Where
>the initial hosted engine is using a local bridge with the (in this
>case virtual) host--and that works--afterwards it's using the overlay
>network and that evidently doesn't.
>
>It was only then when I ran across a very obscure message somewhere in
>this mailing list, that oVirt on top of oVirt in fact does not work at
>all! Up to that point it just wasn't "supported".
>
>When a hypervisor producer speaks of nested virtualization support, I
>would understand it to mean that you can run their product under their
>product, ideally also somebody else's product. I've run ESX on VMware
>workstation and that was pretty cool.
>
>In the case of oVirt from what I have gathered (and I'd love to be
>wrong), it is supposed to only mean that you can run oVirt on top of
>KVM.
>
>Not the other way around, nor in any other way most likely.
>
>To me that looks much more like an internal Redhat development
>facility, than a product feature.
>
>Of course I mostly wish they'd find a way to make it work like it does
>on VMware.
>But next on my wishlist would be an explicit description of what does
>and what doesn't work.
>
>This way it was almost a week of a me against the computer adventure
>where I lost.
>___
>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/7WHRDMXMAWW3DPS24X23X3GCY5S2MCZF/
___
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/XI4G36UJLPKTLMPNEKXBE3CN6UETXLEB/

[ovirt-users] Re: OVA export creates empty and unusable images

Bongiorno Gianluca,

I am entering the data in bugzilla right now...

Logs: There is a problem, I have not found any log evidence of this export and 
import, I don't even know which component is actually doing this.

For 'foreign' imports like VMware and other *.vmdk producing hypervisors, VDSM 
seems to be doing the job and leaves logs in /var/log/vdsm/import, describing 
the format conversion using virt-v2v.

For these 'domestic' imports, there is no such log while the imports seem to 
complete, but with little or no disk data.

I am just validating that at least the transfer between farms or the 
export/import via the deprecated export domain still works.

It's quite messy and unintuitive as buttons to detach an export domain don't 
enable, until you have found a way to put them into maintenance, which for some 
reason has to be done from the datacenter etc.

It's still importing on the target as I write this...

Yes, I guess some validation by others would be lovely, just make sure you 
don't delete any VM you might want back later ;-)
___
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/CPZOYGX6YKHZXADYOEZURHDFGGSVQ7YX/

[ovirt-users] Re: PKI Problem

2020-07-30 Thread Nir Soffer

On Thu, Jul 30, 2020 at 12:53 PM Nir Soffer  wrote:
>
>
>
> On Sun, Jul 19, 2020, 17:22  wrote:
>>
>> Hi
>>
>> I did a fresh installation of version 4.4.0.3. After the engine setup I 
>> replaced the apache certificate with a custom certificate. I used this 
>> article to do it: 
>> https://myhomelab.gr/linux/2020/01/20/replacing_ovirt_ssl.html
>>
>> To summarize, I replaced those files with my own authority and the signed 
>> custom certificate
>>
>> /etc/pki/ovirt-engine/keys/apache.key.nopass
>> /etc/pki/ovirt-engine/certs/apache.cer
>> /etc/pki/ovirt-engine/apache-ca.pem
>>
>> That worked so far, apache uses now my certificate, login is possible. To 
>> setup a new machine, I need to upload an iso image, which failed. I found 
>> this error in /var/log/ovirt-imageio/daemon.log
>>
>> 2020-07-08 20:43:23,750 INFO(Thread-10) [http] OPEN client=192.168.1.228
>> 2020-07-08 20:43:23,767 INFO(Thread-10) [backends.http] Open backend 
>> netloc='the_secret_hostname:54322' 
>> path='/images/ef60404c-dc69-4a3d-bfaa-8571f675f3e1' 
>> cafile='/etc/pki/ovirt-engine/apache-ca.pem' secure=True
>> 2020-07-08 20:43:23,770 ERROR   (Thread-10) [http] Server error
>> Traceback (most recent call last):
>>   File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/http.py", 
>> line 699, in __call__
>> self.dispatch(req, resp)
>>   File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/http.py", 
>> line 744, in dispatch
>> return method(req, resp, *match.groups())
>>   File "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/cors.py", 
>> line 84, in wrapper
>> return func(self, req, resp, *args)
>>   File 
>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/images.py", line 
>> 66, in put
>> backends.get(req, ticket, self.config),
>>   File 
>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/__init__.py",
>>  line 53, in get
>> cafile=config.tls.ca_file)
>>   File 
>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/http.py",
>>  line 48, in open
>> secure=options.get("secure", True))
>>   File 
>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/http.py",
>>  line 63, in __init__
>> options = self._options()
>>   File 
>> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/http.py",
>>  line 364, in _options
>> self._con.request("OPTIONS", self.url.path)
>>   File "/usr/lib64/python3.6/http/client.py", line 1254, in request
>> self._send_request(method, url, body, headers, encode_chunked)
>>   File "/usr/lib64/python3.6/http/client.py", line 1300, in _send_request
>> self.endheaders(body, encode_chunked=encode_chunked)
>>   File "/usr/lib64/python3.6/http/client.py", line 1249, in endheaders
>> self._send_output(message_body, encode_chunked=encode_chunked)
>>   File "/usr/lib64/python3.6/http/client.py", line 1036, in _send_output
>> self.send(msg)
>>   File "/usr/lib64/python3.6/http/client.py", line 974, in send
>> self.connect()
>>   File "/usr/lib64/python3.6/http/client.py", line 1422, in connect
>> server_hostname=server_hostname)
>>   File "/usr/lib64/python3.6/ssl.py", line 365, in wrap_socket
>> _context=self, _session=session)
>>   File "/usr/lib64/python3.6/ssl.py", line 776, in __init__
>> self.do_handshake()
>>   File "/usr/lib64/python3.6/ssl.py", line 1036, in do_handshake
>> self._sslobj.do_handshake()
>>   File "/usr/lib64/python3.6/ssl.py", line 648, in do_handshake
>> self._sslobj.do_handshake()
>> ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed 
>> (_ssl.c:897)
>> 2020-07-08 20:43:23,770 INFO(Thread-10) [http] CLOSE 
>> client=192.168.1.228 [connection 1 ops, 0.019775 s] [dispatch 1 ops, 
>> 0.003114 s]
>>
>> I'm a python developer so I had no problem reading the traceback.
>>
>> The SSL handshake fails when image-io tries to connect to what I think is 
>> called an ovn-provider. But it is using my new authority certificate 
>> cafile='/etc/pki/ovirt-engine/apache-ca.pem' which does not validate the 
>> certificate generated by the ovirt engine setup, which the ovn-provider 
>> probably uses.
>>
>> I didn't exactly know where the parameter for the validation ca file is. 
>> Probably it is the ca_file parameter in 
>> /etc/ovirt-imageio/conf.d/50-engine.conf. But that needs to be set to my own 
>> authority ca file.
>>
>> I modified the python file to set the ca_file parameter to the engine setups 
>> ca_file directly
>>
>> /usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/__init__.py
>>
>> So the function call around line 50 looks like this:
>>
>> backend = module.open(
>> ticket.url,
>> mode,
>> sparse=ticket.sparse,
>> dirty=ticket.dirty,
>> cafile='/etc/pki/ovirt-engine/ca.pem' #config.tls.ca_file
>> )
>
>
> Reading this again, the problem is clear now.
>
> The imageio proxy is

[ovirt-users] Re: OVA export creates empty and unusable images

2020-07-30 Thread Gianluca Cecchi

On Thu, Jul 30, 2020 at 2:37 PM  wrote:

> I've tested this now in three distinct farms with CentOS7.8 and the latest
> oVirt 4.3 release: OVA export files only contain an XML header and then
> lots of zeros where the disk images should be.
>
> Where an 'ls -l .ova' shows a file about the size of the disk, 'du
> -h .ova' shows mere kilobytes, 'strings .ova' dumps the XML
> and then nothing but repeating zeros until the end of the file.
>
> Exporting existing VMs from a CentOS/RHEL 7 farm and importing them after
> a rebuild on CentOS/RHEL 8 would seem like a safe migration strategy,
> except when OVA export isn't working.
>
> Please treat with priority!
>

I think the best way to get appropriate attention is to open a bugzilla for
it, providing information and logs
In the meantime I can test in a 4.3.10 environment of mine if I have the
same problem.
HIH,
Gianluca
___
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/P5L2OESA4HJPATG7VGTXRDX6OE2R72GE/

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

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.

[ovirt-users] OVA export creates empty and unusable images

I've tested this now in three distinct farms with CentOS7.8 and the latest 
oVirt 4.3 release: OVA export files only contain an XML header and then lots of 
zeros where the disk images should be.

Where an 'ls -l .ova' shows a file about the size of the disk, 'du -h 
.ova' shows mere kilobytes, 'strings .ova' dumps the XML and 
then nothing but repeating zeros until the end of the file.

Exporting existing VMs from a CentOS/RHEL 7 farm and importing them after a 
rebuild on CentOS/RHEL 8 would seem like a safe migration strategy, except when 
OVA export isn't working.

Please treat with priority!
___
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/UY6WYFZKDUA7IVAJH7UKZVTMFA5CX34X/

[ovirt-users] Re: Management Engine IP change

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.
>>> >>
>>> >> 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.
>>>
>>> These are _names_, for the same machines, right? I'd call it a rename,
>>> then,

[ovirt-users] Re: 10GB disk created on glusterfs storage has only 4096B in vm

2020-07-30 Thread shadow emy

Good that is ok for you now.
As Gianluca told you the command to see all the gluster volume settings is : 
gluster volume get vol_name all

 The previous command you used : gluster volume info vol_name   will list only 
modified settings from default and not all the settings. The output shows only 
volume "Options Reconfigured". 

Regarding if this is an important bug that affects gluster 7.6(or other 
versions) and should be disabled by default, i dont know for sure.
I am just using ovirt as a hyperconvergence tool.
 Maybe someone from the ovirt development team can answer that.
___
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/EFVT6AMOI4IQJKR6SURWNEMWVY622Y6T/

[ovirt-users] Re: 10GB disk created on glusterfs storage has only 4096B in vm

2020-07-30 Thread jury cat

Good that is ok for you now.
As Gianluca told you the command to see all the gluster volume settings is :
gluster volume get vol_name all


The previous command you used : gluster volume info vol_name   will
list only modified settings from default and not all the settings. The
output shows only volume "Options Reconfigured".


Regarding if this is an important bug that affects gluster 7.6(or other
versions) and should be disabled by default, i dont know for sure.
I am just using ovirt as a hyperconvergence tool.
Maybe someone from the ovirt developmemt team can answer that.
___
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/RTWGP552KMJFYVX5GYO2JSZ7M2ECZUUK/

[ovirt-users] Re: VM Snapshot inconsistent

2020-07-30 Thread Arsène Gschwind

On Thu, 2020-07-23 at 15:17 +0300, Benny Zlotnik wrote:
I think you can remove 6197b30d-0732-4cc7-aef0-12f9f6e9565b from images and the 
corresponding snapshot, and set the parent, 
8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8 as active (active = 't' field), and change 
its snapshot to be active snapshot. That is if I correctly understand the 
current layout, that 6197b30d-0732-4cc7-aef0-12f9f6e9565b was removed from the 
storage and 8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8 is now the only volume for the 
disk

What do you mean by "change its snapshot to be active snapshot" ?
Yes correct, 6197b30d-0732-4cc7-aef0-12f9f6e9565b was removed from the storage 
and 8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8 is now the only volume for the disk

Thanks,
arsene

On Wed, Jul 22, 2020 at 1:32 PM Arsène Gschwind 
mailto:arsene.gschw...@unibas.ch>> wrote:
Please find the result:

psql -d engine -c "\x on" -c "select * from images where image_group_id = 
'd7bd480d-2c51-4141-a386-113abf75219e';"

Expanded display is on.

-[ RECORD 1 ]-+-

image_guid| 8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8

creation_date | 2020-04-23 14:59:23+02

size  | 161061273600

it_guid   | ----

parentid  | ----

imagestatus   | 1

lastmodified  | 2020-07-06 20:38:36.093+02

vm_snapshot_id| 6bc03db7-82a3-4b7e-9674-0bdd76933eb8

volume_type   | 2

volume_format | 4

image_group_id| d7bd480d-2c51-4141-a386-113abf75219e

_create_date  | 2020-04-23 14:59:20.919344+02

_update_date  | 2020-07-06 20:38:36.093788+02

active| f

volume_classification | 1

qcow_compat   | 2

-[ RECORD 2 ]-+-

image_guid| 6197b30d-0732-4cc7-aef0-12f9f6e9565b

creation_date | 2020-07-06 20:38:38+02

size  | 161061273600

it_guid   | ----

parentid  | 8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8

imagestatus   | 1

lastmodified  | 1970-01-01 01:00:00+01

vm_snapshot_id| fd5193ac-dfbc-4ed2-b86c-21caa8009bb2

volume_type   | 2

volume_format | 4

image_group_id| d7bd480d-2c51-4141-a386-113abf75219e

_create_date  | 2020-07-06 20:38:36.093788+02

_update_date  | 2020-07-06 20:38:52.139003+02

active| t

volume_classification | 0

qcow_compat   | 2


psql -d engine -c "\x on" -c "SELECT s.* FROM snapshots s, images i where 
i.vm_snapshot_id = s.snapshot_id and i.image_guid = 
'6197b30d-0732-4cc7-aef0-12f9f6e9565b';"

Expanded display is on.

-[ RECORD 1 
]---+--

snapshot_id | fd5193ac-dfbc-4ed2-b86c-21caa8009bb2

vm_id   | b5534254-660f-44b1-bc83-d616c98ba0ba

snapshot_type   | ACTIVE

status  | OK

description | Active VM

creation_date   | 2020-04-23 14:59:20.171+02

app_list| 
kernel-3.10.0-957.12.2.el7,xorg-x11-drv-qxl-0.1.5-4.el7.1,kernel-3.10.0-957.12.1.el7,kernel-3.10.0-957.38.1.el7,ovirt-guest-agent-common-1.0.14-1.el7

vm_configuration|

_create_date| 2020-04-23 14:59:20.154023+02

_update_date| 2020-07-03 17:33:17.483215+02

memory_metadata_disk_id |

memory_dump_disk_id |

vm_configuration_broken | f


Thanks.


On Tue, 2020-07-21 at 13:45 +0300, Benny Zlotnik wrote:
I forgot to add the `\x on` to make the output readable, can you run it with:
$ psql -U engine -d engine -c "\x on" -c ""

On Mon, Jul 20, 2020 at 2:50 PM Arsène Gschwind 
mailto:arsene.gschw...@unibas.ch>> wrote:
Hi,

Please find the output:

select * from images where image_group_id = 
'd7bd480d-2c51-4141-a386-113abf75219e';


  image_guid  | creation_date  | size | 
  it_guid|   parentid   | 
imagestatus |lastmodified|vm_snapshot_id
| volume_type | volume_for

mat |image_group_id| _create_date  |
 _update_date  | active | volume_classification | qcow_compat

--++--+--+--+-++--+-+---

+--+---+---++---+-

 8e412b5a-85ec-4c53-a5b8-dfb4d6d987b8 | 2020-04-23 14:59:23+02 | 161061273600 | 
---- |

[ovirt-users] Re: Management Engine IP change

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  
>> > 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.

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.
>>
>> 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.

These are _names_, for the same machines, right? I'd call it a rename,
then, not a migration.

If it's migration (you have two sets of physical machines, and want to
migrate the VMs from one set to the other), indeed using storage
import is simpler (perhaps using the DR tool/doc).

>>
>>
>> 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 old one, you can add

[ovirt-users] Re: Management Engine IP change

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] 
>> [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/QYUUKE3LDNGL75ZR43T46LUUEXVX2GGI/

[ovirt-users] Re: Management Engine IP change

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 old one, you can add it using SSO_ALTERNATE_ENGINE_FQDNS.
>
I need to wipe out completely any reference to the old domain/FQDN.

>
> > Also I am wondering if I can change in some way the management network
> and make from untagged to VLAN tagged.
>
> Sorry, no idea. Perhaps start a different thread about this.
>
I will. thanx.

>
> Best regards,
>
> >>
> >>
> >>
> 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

[ovirt-users] Re: Management Engine IP change

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"...

>>
>>
>> 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...

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?

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 old one, you can add it using SSO_ALTERNATE_ENGINE_FQDNS.

> Also I am wondering if I can change in some way the management network and 
> make from untagged to VLAN tagged.

Sorry, no idea. Perhaps start a different thread about this.

Best regards,

>>
>>
>> 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/



-- 
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/HADIKTQLYKFFA5K3AE6LP2G7I3SDJMF6/

[ovirt-users] Re: PKI Problem

2020-07-30 Thread Nir Soffer

On Sun, Jul 19, 2020, 17:22  wrote:

> Hi
>
> I did a fresh installation of version 4.4.0.3. After the engine setup I
> replaced the apache certificate with a custom certificate. I used this
> article to do it:
> https://myhomelab.gr/linux/2020/01/20/replacing_ovirt_ssl.html
>
> To summarize, I replaced those files with my own authority and the signed
> custom certificate
>
> /etc/pki/ovirt-engine/keys/apache.key.nopass
> /etc/pki/ovirt-engine/certs/apache.cer
> /etc/pki/ovirt-engine/apache-ca.pem
>
> That worked so far, apache uses now my certificate, login is possible. To
> setup a new machine, I need to upload an iso image, which failed. I found
> this error in /var/log/ovirt-imageio/daemon.log
>
> 2020-07-08 20:43:23,750 INFO(Thread-10) [http] OPEN
> client=192.168.1.228
> 2020-07-08 20:43:23,767 INFO(Thread-10) [backends.http] Open backend
> netloc='the_secret_hostname:54322'
> path='/images/ef60404c-dc69-4a3d-bfaa-8571f675f3e1'
> cafile='/etc/pki/ovirt-engine/apache-ca.pem' secure=True
> 2020-07-08 20:43:23,770 ERROR   (Thread-10) [http] Server error
> Traceback (most recent call last):
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/http.py", line
> 699, in __call__
> self.dispatch(req, resp)
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/http.py", line
> 744, in dispatch
> return method(req, resp, *match.groups())
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/cors.py", line
> 84, in wrapper
> return func(self, req, resp, *args)
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/images.py",
> line 66, in put
> backends.get(req, ticket, self.config),
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/__init__.py",
> line 53, in get
> cafile=config.tls.ca_file)
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/http.py",
> line 48, in open
> secure=options.get("secure", True))
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/http.py",
> line 63, in __init__
> options = self._options()
>   File
> "/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/http.py",
> line 364, in _options
> self._con.request("OPTIONS", self.url.path)
>   File "/usr/lib64/python3.6/http/client.py", line 1254, in request
> self._send_request(method, url, body, headers, encode_chunked)
>   File "/usr/lib64/python3.6/http/client.py", line 1300, in _send_request
> self.endheaders(body, encode_chunked=encode_chunked)
>   File "/usr/lib64/python3.6/http/client.py", line 1249, in endheaders
> self._send_output(message_body, encode_chunked=encode_chunked)
>   File "/usr/lib64/python3.6/http/client.py", line 1036, in _send_output
> self.send(msg)
>   File "/usr/lib64/python3.6/http/client.py", line 974, in send
> self.connect()
>   File "/usr/lib64/python3.6/http/client.py", line 1422, in connect
> server_hostname=server_hostname)
>   File "/usr/lib64/python3.6/ssl.py", line 365, in wrap_socket
> _context=self, _session=session)
>   File "/usr/lib64/python3.6/ssl.py", line 776, in __init__
> self.do_handshake()
>   File "/usr/lib64/python3.6/ssl.py", line 1036, in do_handshake
> self._sslobj.do_handshake()
>   File "/usr/lib64/python3.6/ssl.py", line 648, in do_handshake
> self._sslobj.do_handshake()
> ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
> (_ssl.c:897)
> 2020-07-08 20:43:23,770 INFO(Thread-10) [http] CLOSE
> client=192.168.1.228 [connection 1 ops, 0.019775 s] [dispatch 1 ops,
> 0.003114 s]
>
> I'm a python developer so I had no problem reading the traceback.
>
> The SSL handshake fails when image-io tries to connect to what I think is
> called an ovn-provider. But it is using my new authority certificate
> cafile='/etc/pki/ovirt-engine/apache-ca.pem' which does not validate the
> certificate generated by the ovirt engine setup, which the ovn-provider
> probably uses.
>
> I didn't exactly know where the parameter for the validation ca file is.
> Probably it is the ca_file parameter in
> /etc/ovirt-imageio/conf.d/50-engine.conf. But that needs to be set to my
> own authority ca file.
>
> I modified the python file to set the ca_file parameter to the engine
> setups ca_file directly
>
>
> /usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/backends/__init__.py
>
> So the function call around line 50 looks like this:
>
> backend = module.open(
> ticket.url,
> mode,
> sparse=ticket.sparse,
> dirty=ticket.dirty,
> cafile='/etc/pki/ovirt-engine/ca.pem' #config.tls.ca_file
> )
>

Reading this again, the problem is clear now.

The imageio proxy is trying to use your CA to verify the the host imageio
daemon certificate. This cannot work because the host certificate is signed
by engine CA, and the imageio daemon on the host is using vdsm

[ovirt-users] Re: Management Engine IP change

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: PKI Problem

2020-07-30 Thread Nir Soffer

On Thu, Jul 30, 2020, 09:31 Ramon Clematide  wrote:

> Hi Nir
>
> I did not modify /etc/ovirt-imageio/conf.d/50-engine.conf
>
> I only replaced those files:
>
> /etc/pki/ovirt-engine/keys/apache.key.nopass
> /etc/pki/ovirt-engine/certs/apache.cer
> /etc/pki/ovirt-engine/apache-ca.pem
>
> ovirt-imageio has the apache certificates configured by default.
>

So why did you change the code using the default configuration?


>
> I found certificates generated by the engine setup for imageio (but not
> used?)
>
> So I switched to those certificates:
>
> cat /etc/ovirt-imageio/conf.d/99-locl.conf
> [tls]
> key_file = /etc/pki/ovirt-engine/keys/imageio-proxy.key.nopass
> cert_file = /etc/pki/ovirt-engine/certs/imageio-proxy.cer
> ca_file = /etc/pki/ovirt-engine/ca.pem
>
>
> When I test the connection in the image upload screen, now my browser does
> not validate the imageio's certificate. When import the ca generated by the
> engine setup, upload works. But I don't want to import the ca generated by
> the engine setup.
>

Why did you switch to engine ca if you don't want to use it?

When you change certificates, you need to restart the ovirt-imageio service
since it loads the certificates during startup.

Did you restart it?


___
> 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/GRKFPQKHKODCJUV3YAL7M5ZJP2PSZCCU/
>
___
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/WXQXUDOSUVFFUV2ANM5FHCM4GYDCSJ35/

[ovirt-users] Re: Management Engine IP change

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?

There actually is:

https://www.ovirt.org/documentation/administration_guide/#sect-The_oVirt_Engine_Rename_Tool

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:

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/A2KVHS5CKLMZV5MYISXJEZBTFPQNOH2Z/

[ovirt-users] Re: Upgrade procedure for oVirt

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 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

[ovirt-users] Re: Management Engine IP change

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

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

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

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.

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? 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,
-- 
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/GGN3ZUZW64J2R3XKH6PSOW7ZAOA6J2N6/

[ovirt-users] Re: Upgrade procedure for oVirt

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

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: Management Engine IP change