[ovirt-users] Re: oVirt Survey Autumn 2020

2020-10-06 Thread Jayme 
https://docs.google.com/forms/u/1/d/e/1FAIpQLSdzzh_MSsSq-LSQLauJzuaHC0Va1baXm84A_9XBCIileLNSPQ/viewform?usp=send_form


On Tue, Oct 6, 2020 at 7:28 PM Strahil Nikolov via Users 
wrote:

> Hello All,
>
>
>
> can someone send me the full link (not the short one) as my proxy is
> blocking it :)
>
>
>
> Best Regards,
>
> Strahil Nikolov
>
>
>
>
>
>
>
>
>
>
>
>
>
> В вторник, 6 октомври 2020 г., 15:26:57 Гринуич+3, Sandro Bonazzola <
> sbona...@redhat.com> написа:
>
>
>
>
>
>
>
>
>
>
>
> Just a kind reminder about the survey (https://forms.gle/bPvEAdRyUcyCbgEc7)
> closing on October 18th
>
>
>
> Il giorno mer 23 set 2020 alle ore 11:11 Sandro Bonazzola <
> sbona...@redhat.com> ha scritto:
>
> > As we continue to develop oVirt 4.4, the Development and Integration
> teams at Red Hat would value insights on how you are deploying the oVirt
> environment.
>
> > Please help us to hit the mark by completing this short survey.
>
> > The survey will close on October 18th 2020. If you're managing multiple
> oVirt deployments with very different use cases or very different
> deployments you can consider answering this survey multiple times.
>
> >
>
> > Please note the answers to this survey will be publicly accessible.
>
> > This survey is under oVirt Privacy Policy available at
> https://www.ovirt.org/site/privacy-policy.html .
>
>
>
> and the privacy link was wrong, the right one:
> https://www.ovirt.org/privacy-policy.html (no content change, only url
> change)
>
>
>
>
>
> >
>
> >
>
> > The survey is available https://forms.gle/bPvEAdRyUcyCbgEc7
>
> >
>
> > --
>
> > 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.
>
> >
>
> >
>
>
>
>
>
> --
>
> 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/IJEW35XLR6WBM45DKYMZQ2UOZRWYXHKY/
>
> ___
>
> 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/QYKXU7P2DNXPGZ2MOBBXVMJYA6DIND2S/
>
>
___
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/DAISGM2VUZ73SWAU5OALNXM35W7GCAVT/

[ovirt-users] Re: CPU Type / Cluster

2020-10-06 Thread Strahil Nikolov via Users 
Hi Michael,

I'm running 4.3.10 and I can confirm that Opteron_G5 was not removed.
What is reported by 'virsh -c 
qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf capabilities' 
on both hosts ?

Best Regards,
Strahil Nikolov






В сряда, 7 октомври 2020 г., 00:06:08 Гринуич+3, Michael Jones 
 написа: 





Thanks for the email;

unfortunately it seems "Opteron_G5" is not on the 2nd host (guessing it
was removed in 4.2 or some strange cpu compat thing);

I upgraded the CPU #consumerism,

now both are "model_EPYC-IBPB / EPYC Secure" and clustered.

Kind Regards,

Mike

On 04/10/2020 17:51, Strahil Nikolov wrote:
> Hi Mike,
>
> In order to add them to a single cluster , you should set them to Opteron_G5 
> (my FX-8350 is also there) , untill you replace the host with something more 
> modern.
>
> Of course , you can have your hosts in separate clusters - but then you won't 
> be able to live migrate your VMs.
>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В събота, 3 октомври 2020 г., 16:50:24 Гринуич+3, Michael Jones 
>  написа: 
>
>
>
>
>
> to get these two hosts into a cluster would i need to castrate them down
> to nehalem, or would i be able to botch the db for the 2nd host from
> "EPYC-IBPB" to "Opteron_G5"?
>
> I don't really want to drop them down to nehalem, so either I can botch
> the 2nd cpu so they are both on opteron_G5 or i'll have to buy a new CPU
> for host1 to bring it up to "EPYC-IBPB";
>
> I have;
>
> host1;
>
> # vdsm-client Host getCapabilities | grep cpuFlags | tr "," "\n" | grep
> model_ | sed 's/"//' | sort -n
> model_486
> model_Conroe
> model_cpu64-rhel6
> model_kvm32
> model_kvm64
> model_Nehalem
> model_Opteron_G1
> model_Opteron_G2
> model_Opteron_G3
> model_Opteron_G4
> model_Opteron_G5  "AMD FX(tm)-8350 Eight-Core Processor"
> model_Penryn
> model_pentium
> model_pentium2
> model_pentium3
> model_qemu32
> model_qemu64
> model_Westmere
>
> host2;
>
> # vdsm-client Host getCapabilities | grep cpuFlags | tr "," "\n" | grep
> model_ | sed 's/"//' | sort -n
> model_486
> model_Conroe
> model_Dhyana
> model_EPYC
> model_EPYC-IBPB  "AMD Ryzen 7 1700X Eight-Core Processor"
> model_kvm32
> model_kvm64
> model_Nehalem
> model_Opteron_G1
> model_Opteron_G2
> model_Opteron_G3
> model_Penryn
> model_pentium
> model_pentium2
> model_pentium3
> model_qemu32
> model_qemu64
> model_SandyBridge
> model_Westmere
>
> Thanks,
>
> Mike
>
> ___
> 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/NULJX3JB736A4MHC2GX7ADDW3ZT3C37O/
>
___
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/D462NVX5MFSMPSD52HN342C3OK3MSV4F/

[ovirt-users] Re: oVirt Survey Autumn 2020

2020-10-06 Thread Strahil Nikolov via Users 
Hello All,

can someone send me the full link (not the short one) as my proxy is blocking 
it :)

Best Regards,
Strahil Nikolov






В вторник, 6 октомври 2020 г., 15:26:57 Гринуич+3, Sandro Bonazzola 
 написа: 





Just a kind reminder about the survey (https://forms.gle/bPvEAdRyUcyCbgEc7) 
closing on October 18th

Il giorno mer 23 set 2020 alle ore 11:11 Sandro Bonazzola  
ha scritto:
> As we continue to develop oVirt 4.4, the Development and Integration teams at 
> Red Hat would value insights on how you are deploying the oVirt environment.
> Please help us to hit the mark by completing this short survey.
> The survey will close on October 18th 2020. If you're managing multiple oVirt 
> deployments with very different use cases or very different deployments you 
> can consider answering this survey multiple times. 
> 
> Please note the answers to this survey will be publicly accessible.
> This survey is under oVirt Privacy Policy available at 
> https://www.ovirt.org/site/privacy-policy.html .

and the privacy link was wrong, the right one: 
https://www.ovirt.org/privacy-policy.html (no content change, only url change)

 
> 
> 
> The survey is available https://forms.gle/bPvEAdRyUcyCbgEc7
> 
> -- 
> 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.
> 
>  


-- 
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/IJEW35XLR6WBM45DKYMZQ2UOZRWYXHKY/
___
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/QYKXU7P2DNXPGZ2MOBBXVMJYA6DIND2S/

[ovirt-users] Re: engine-setup in 4.4.2 not using yum/dnf proxy?

2020-10-06 Thread Strahil Nikolov via Users 
I would put it in the yum.conf and export it as "http_proxy" & "https_proxy" 
system variables.

Best Regards,
Strahil Nikolov






В вторник, 6 октомври 2020 г., 12:39:22 Гринуич+3, Gianluca Cecchi 
 написа: 





Hello,
I'm testing upgrade from 4.3.10 to 4.4.2 for a standalone manager with local 
database environment.
I configured the new engine system as a CentOS 8.2 with a proxy in 
/etc/yum.conf (that is a link to /etc/dnf/dnf.com) and that worked for all the 
steps until engine-setup.
Now I get this

[root@ovmgr1 ~]# engine-setup
[ INFO  ] Stage: Initializing
[ INFO  ] Stage: Environment setup
          Configuration files: 
/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf, 
/etc/ovirt-engine-setup.conf.d/10-packaging.conf, 
/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf
          Log file: 
/var/log/ovirt-engine/setup/ovirt-engine-setup-20201006112458-p84x9i.log
          Version: otopi-1.9.2 (otopi-1.9.2-1.el8)
[ INFO  ] DNF Downloading 1 files, 0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloaded CentOS-8 - AppStream
[ INFO  ] DNF Errors during downloading metadata for repository 'AppStream':

[ ERROR ] Execution of setup failed

and I see in netstat during the phase

tcp        0      1 10.4.192.43:33418       18.225.36.18:80         SYN_SENT   

so it seems it is not using the proxy.
Do I have to put proxy info into any other file?

Thanks,
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/D5WQSM7OZNKJQK3L5CN367W2TRVZZVHZ/
___
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/2UXQ6J6CAWQWV3DLAJOH3NOVADSIM54N/

[ovirt-users] Optimizing Gluster

2020-10-06 Thread eevans 
This article provides good information to stabilize gluster. I thought i would 
pass it along.
https://docs.gluster.org/en/latest/Administrator%20Guide/Linux%20Kernel%20Tuning/
___
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/I62VBDYPQIWPRE3LKUUVSLHPZJVQBT4X/

[ovirt-users] Re: CPU Type / Cluster

2020-10-06 Thread Michael Jones 
Thanks for the email;

unfortunately it seems "Opteron_G5" is not on the 2nd host (guessing it
was removed in 4.2 or some strange cpu compat thing);

I upgraded the CPU #consumerism,

now both are "model_EPYC-IBPB / EPYC Secure" and clustered.

Kind Regards,

Mike

On 04/10/2020 17:51, Strahil Nikolov wrote:
> Hi Mike,
>
> In order to add them to a single cluster , you should set them to Opteron_G5 
> (my FX-8350 is also there) , untill you replace the host with something more 
> modern.
>
> Of course , you can have your hosts in separate clusters - but then you won't 
> be able to live migrate your VMs.
>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В събота, 3 октомври 2020 г., 16:50:24 Гринуич+3, Michael Jones 
>  написа: 
>
>
>
>
>
> to get these two hosts into a cluster would i need to castrate them down
> to nehalem, or would i be able to botch the db for the 2nd host from
> "EPYC-IBPB" to "Opteron_G5"?
>
> I don't really want to drop them down to nehalem, so either I can botch
> the 2nd cpu so they are both on opteron_G5 or i'll have to buy a new CPU
> for host1 to bring it up to "EPYC-IBPB";
>
> I have;
>
> host1;
>
> # vdsm-client Host getCapabilities | grep cpuFlags | tr "," "\n" | grep
> model_ | sed 's/"//' | sort -n
> model_486
> model_Conroe
> model_cpu64-rhel6
> model_kvm32
> model_kvm64
> model_Nehalem
> model_Opteron_G1
> model_Opteron_G2
> model_Opteron_G3
> model_Opteron_G4
> model_Opteron_G5  "AMD FX(tm)-8350 Eight-Core Processor"
> model_Penryn
> model_pentium
> model_pentium2
> model_pentium3
> model_qemu32
> model_qemu64
> model_Westmere
>
> host2;
>
> # vdsm-client Host getCapabilities | grep cpuFlags | tr "," "\n" | grep
> model_ | sed 's/"//' | sort -n
> model_486
> model_Conroe
> model_Dhyana
> model_EPYC
> model_EPYC-IBPB  "AMD Ryzen 7 1700X Eight-Core Processor"
> model_kvm32
> model_kvm64
> model_Nehalem
> model_Opteron_G1
> model_Opteron_G2
> model_Opteron_G3
> model_Penryn
> model_pentium
> model_pentium2
> model_pentium3
> model_qemu32
> model_qemu64
> model_SandyBridge
> model_Westmere
>
> Thanks,
>
> Mike
>
> ___
> 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/NULJX3JB736A4MHC2GX7ADDW3ZT3C37O/
>
___
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/R6EB3FXBVSVF72ZN3QGAS3SOWNQKN2LG/

[ovirt-users] Re: Upgrade oVirt from 4.3.10 to 4.4.2 and AD users

2020-10-06 Thread Martin Perina 
Hi Gianluca,

There is a bug in the documentation. Configuration of all oVirt engine
extensions is included in 4.3 backup, these configuration files are
properly restored and upgraded during engine-setup execution:
https://bugzilla.redhat.com/show_bug.cgi?id=1814212
So further action around extension configuration is needed.

Regards,
Martin

On Tue, Oct 6, 2020 at 3:17 PM Gianluca Cecchi 
wrote:

> Hello,
> I'm upgrading a standalone engine with local database and with 3 hosts
> from oVirt 4.3.10 to 4.4.2 and I'm cross checking both oVirt and RHV
> documents.
> In my oVirt environment I have integration with AD for web admin access.
>
> Inside RHV upgrade guide docs there is this statement regarding manager
> upgrade:
> "
> Install optional extension packages if they were installed on the Red Hat
> Virtualization Manager 4.3 machine.
> # yum install ovirt-engine-extension-aaa-ldap
> ovirt-engine-extension-aaa-misc ovirt-engine-extension-logger-log4j
> NOTE
> The configuration for these package extensions must be manually reapplied
> because they are not migrated as part of the backup and restore process.
> "
>
> In my case I had ovirt-engine-extension-aaa-ldap and
> ovirt-engine-extension-aaa-misc installed on 4.3.10.
> So after "engine-backup --mode=restore " command I executed:
>
> [root@ovmgr1 ~]# yum install ovirt-engine-extension-aaa-ldap
> ovirt-engine-extension-aaa-misc
> Last metadata expiration check: 0:01:11 ago on Tue 06 Oct 2020 11:23:04 AM
> CEST.
> Dependencies resolved.
>
> ==
>  Package  ArchVersion Repository
>   Size
>
> ==
> Installing:
>  ovirt-engine-extension-aaa-ldap  noarch  1.4.1-1.el8 ovirt-4.4
>   127 k
>  ovirt-engine-extension-aaa-misc  noarch  1.1.0-1.el8 ovirt-4.4
>37 k
> Installing dependencies:
>  unboundid-ldapsdknoarch  4.0.14-2.el8
>  ovirt-4.4-centos-ovirt44  4.0 M
>
> Transaction Summary
>
> ==
> Install  3 Packages
>
> Total download size: 4.2 M
> Installed size: 4.5 M
>
> and followed the next upgrade flow steps.
> After finishing the engine upgrade with the "engine-setup" step, it seems
> actually that I can still connect to my engine with my AD accounts, so that
> I don't have to do any manual step described...
>
> Does it match any one other experience?
>
> 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/WBQDOZM4PUWJJQ4TBRU33OSLPWVKXDLQ/
>


-- 
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
___
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/SOLX5Y4GMUZZX56UNDEAYLXQFHOSOVER/

[ovirt-users] Re: oVirt Node 4.4.2 is now generally available

2020-10-06 Thread Martin Perina 
Hi Gianluca,

please see my replies inline

On Tue, Oct 6, 2020 at 11:37 AM Gianluca Cecchi 
wrote:

> On Tue, Oct 6, 2020 at 11:25 AM Martin Perina  wrote:
>
>>
>>> You say to drive a command form the engine that is a VM that runs inside
>>> the host, but ask to shutdown VMs running on host before...
>>> This is a self hosted engine composed by only one single host.
>>> Normally I would use the procedure from the engine web admin gui, one
>>> host at a time, but with single host it is not possible.
>>>
>>
>> We have said several times, that it doesn't make sense to use oVirt on a
>> single host system. So you either need to attach 2nd host to your setup
>> (preferred) or shutdown all VMS and run manual upgrade of your host OS
>>
>>
> We who
>

So I've spent the past hour deeply investigating our upstream documentation
and you are right, we don't have any clear requirements about the minimal
number of hosts in upstream oVirt documentation.
But here are the facts:

1. To be able to upgrade a host either from UI/RESTAPI or manually using
SSH, the host always needs to be in Maintenance:

https://www.ovirt.org/documentation/administration_guide/#Updating_a_host_between_minor_releases

2. To perform Reinstall or Enroll certificate of a host, the host needs to
be in Maintenance mode

https://www.ovirt.org/documentation/administration_guide/#Reinstalling_Hosts_admin

3. When host is in Maintenance mode, there are no oVirt managed VMs running
on it

https://www.ovirt.org/documentation/administration_guide/#Moving_a_host_to_maintenance_mode

4. When engine is not running (either stopped or crashed), VMs running on
hypervisor hosts are unaffected (meaning they are running independently on
engine), but they are pretty much "pinned to the host they are running on"
(for example VMs cannot be migrated or started/stopped (of course you can
stop this VM from within) without running engine)

So just using above facts here are logical conclusions:

1. Standalone engine installation with only one hypervisor host
- this means that engine runs on bare metal hosts (for example
engine.domain.com) and single hypervisor host is managed by it (for example
host1.domain.com)
- in this case scenario administrator is able to perform all
maintenance task (even though at the cost that VMs running on hypervisor
need to be stopped before switching to Maintenance mode),
  because engine is running independently on hypervisor

2. Hosted engine installation with one hypervisor hosts
- this means that engine runs as a VM (for example engine.domain.com)
inside a single hypervisor host, which is managed by it (for example
host1.domain.com)
- in this scenario maintenance of the host is very limited:
- you cannot move the host to Maintenance, because hosted engine VM
cannot be migrated outside a host
- you can perform global Maintenance and the probably manually stop
hosted engine VM, but then you don't have engine to be able to perform
maintenance tasks (for example, Upgrade, Reinstall or Enroll certificates)

But in both above use cases you cannot use the biggest oVirt advantage and
that's a shared storage among hypervisor hosts, which allows you to perform
live migration of VMs. And thanks to that feature you can perform
maintenance tasks on the host(s) without interruption in providing VM
services.

*From the above it's obvious that we need to really clearly state that in a
production environment oVirt requires to have at least 2 hypervisor hosts
for full functionality.*

In old times there was the all-in-one setup that was substituted from
> single host HCI
>

All-in-one feature has been deprecated in oVirt 3.6 and fully removed in
oVirt 4.0

> ... developers also put extra efforts to setup the wizard comprising the
> single host scenario.
>

Yes, you are right, you can initially set up oVirt with just a single host,
but it's expected that you are going to add an additional host(s) soon.

Obviously it is aimed at test bed / devel / home environments, not
> production ones.
>

Of course, for development use whatever your want, but for production you
care about your setup, because you want the services your offer to run
smoothly

> Do you want me to send you the list of bugzilla contributed by users using
> single host environments that helped Red Hat to have a better working RHV
> too?
>

It's clearly stated that at least 2 hypervisors are required for hosted
engine or standalone RHV installation:
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/planning_and_prerequisites_guide/rhv_architecture
But as I mentioned above, we have a bug in oVirt documentation, that such
an important requirement is not clearly stated. And this is not a fault of
a community, this is a fault of oVirt maintainers, that we have forgotten
to mention such an important requirement in oVirt documentation and it's
clearly visible, that it caused a confusion to so many users.

But no matter what I

[ovirt-users] Re: Is it possible to backup stopped vm? (ovirt 4.4)

2020-10-06 Thread Nir Soffer 
On Tue, Oct 6, 2020 at 4:08 PM Łukasz Kołaciński
 wrote:
>
> Hello,
> While trying to backup stopped VM (with POST on 
> /ovirt-engine/api/vms/b79b34c0-d8db-43e5-916e-5528ff7bcfbe/backups) I got the 
> response:
>
> 
> 
> [Cannot backup VM. The Virtual Machine should be in Up 
> status.]
> Operation Failed
> 

Yes, this is not supported now.

> I found here: 
> https://www.ovirt.org/develop/release-management/features/storage/incremental-backup.html
>  that it should be possible to back up a virtual machine that is not running.
> "If the VM is not running, the system will create a paused, stripped-down 
> version of the VM, with only backup disks attached, and use libvirt API to 
> start and stop the backup."

This is a possible solution we considered, but it is not implemented yet.

The next line is:

   Since creating special paused VM for backing up non-running VM is a
lot of work,
   we may defer support for backing up non-running VMs.

We got a request to implement this from other backup vendor, and we are
discussing the possible solutions with platform folks.

Nir
___
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/SOG7V6SRAIHAKB6CKJOHDCDJDRQRLC7W/

[ovirt-users] Upgrade oVirt from 4.3.10 to 4.4.2 and AD users

2020-10-06 Thread Gianluca Cecchi 
Hello,
I'm upgrading a standalone engine with local database and with 3 hosts from
oVirt 4.3.10 to 4.4.2 and I'm cross checking both oVirt and RHV documents.
In my oVirt environment I have integration with AD for web admin access.

Inside RHV upgrade guide docs there is this statement regarding manager
upgrade:
"
Install optional extension packages if they were installed on the Red Hat
Virtualization Manager 4.3 machine.
# yum install ovirt-engine-extension-aaa-ldap
ovirt-engine-extension-aaa-misc ovirt-engine-extension-logger-log4j
NOTE
The configuration for these package extensions must be manually reapplied
because they are not migrated as part of the backup and restore process.
"

In my case I had ovirt-engine-extension-aaa-ldap and
ovirt-engine-extension-aaa-misc installed on 4.3.10.
So after "engine-backup --mode=restore " command I executed:

[root@ovmgr1 ~]# yum install ovirt-engine-extension-aaa-ldap
ovirt-engine-extension-aaa-misc
Last metadata expiration check: 0:01:11 ago on Tue 06 Oct 2020 11:23:04 AM
CEST.
Dependencies resolved.
==
 Package  ArchVersion Repository
  Size
==
Installing:
 ovirt-engine-extension-aaa-ldap  noarch  1.4.1-1.el8 ovirt-4.4
127 k
 ovirt-engine-extension-aaa-misc  noarch  1.1.0-1.el8 ovirt-4.4
 37 k
Installing dependencies:
 unboundid-ldapsdknoarch  4.0.14-2.el8
 ovirt-4.4-centos-ovirt44  4.0 M

Transaction Summary
==
Install  3 Packages

Total download size: 4.2 M
Installed size: 4.5 M

and followed the next upgrade flow steps.
After finishing the engine upgrade with the "engine-setup" step, it seems
actually that I can still connect to my engine with my AD accounts, so that
I don't have to do any manual step described...

Does it match any one other experience?

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

[ovirt-users] Re: engine-setup in 4.4.2 not using yum/dnf proxy?

2020-10-06 Thread Gianluca Cecchi 
On Tue, Oct 6, 2020 at 11:33 AM Gianluca Cecchi 
wrote:

> Hello,
> I'm testing upgrade from 4.3.10 to 4.4.2 for a standalone manager with
> local database environment.
> I configured the new engine system as a CentOS 8.2 with a proxy in
> /etc/yum.conf (that is a link to /etc/dnf/dnf.com) and that worked for
> all the steps until engine-setup.
> Now I get this
>
> [root@ovmgr1 ~]# engine-setup
> [ INFO  ] Stage: Initializing
> [ INFO  ] Stage: Environment setup
>   Configuration files:
> /etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf,
> /etc/ovirt-engine-setup.conf.d/10-packaging.conf,
> /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf
>   Log file:
> /var/log/ovirt-engine/setup/ovirt-engine-setup-20201006112458-p84x9i.log
>   Version: otopi-1.9.2 (otopi-1.9.2-1.el8)
> [ INFO  ] DNF Downloading 1 files, 0.00KB
> [ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
> [ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
> [ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
> [ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
> [ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
> [ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
> [ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
> [ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
> [ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
> [ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
> [ INFO  ] DNF Downloaded CentOS-8 - AppStream
> [ INFO  ] DNF Errors during downloading metadata for repository
> 'AppStream':
> 
> [ ERROR ] Execution of setup failed
>
> and I see in netstat during the phase
>
> tcp0  1 10.4.192.43:33418   18.225.36.18:80
> SYN_SENT
>
> so it seems it is not using the proxy.
> Do I have to put proxy info into any other file?
>
> Thanks,
> Gianluca
>

It was necessary and sufficient to set both:

[root@ovmgr1 ~]# export http_proxy=my.proxy.host:proxy_port

[root@ovmgr1 ~]# export https_proxy=my.proxy.host:proxy_port

It seems some repos are using http and other https.
A smarter way would be to leverage the already systemwide dnf proxy config.

Anyway the upgrade of the engine from 4.3.10 to 4.4.2 went smooth and ok
and I was able to move VMs from a host to start upgrading it.
Let's see how it goes.

HIH others,
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/GW4YI5D7TTKCAWY3N4BZ3QOIPLIN66VI/

[ovirt-users] Re: oVirt Survey Autumn 2020

2020-10-06 Thread Sandro Bonazzola 
Just a kind reminder about the survey (https://forms.gle/bPvEAdRyUcyCbgEc7)
closing on October 18th

Il giorno mer 23 set 2020 alle ore 11:11 Sandro Bonazzola <
sbona...@redhat.com> ha scritto:

> As we continue to develop oVirt 4.4, the Development and Integration teams
> at Red Hat would value insights on how you are deploying the oVirt
> environment.
> Please help us to hit the mark by completing this short survey.
> The survey will close on October 18th 2020. If you're managing multiple
> oVirt deployments with very different use cases or very different
> deployments you can consider answering this survey multiple times.
>
> *Please note the answers to this survey will be publicly accessible*.
> This survey is under oVirt Privacy Policy available at
> https://www.ovirt.org/site/privacy-policy.html .
>

and the privacy link was wrong, the right one:
https://www.ovirt.org/privacy-policy.html (no content change, only url
change)



>
> The survey is available https://forms.gle/bPvEAdRyUcyCbgEc7
>
> --
>
> 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.*
>


-- 

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

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-10-06 Thread Dominik Holler 
On Tue, Oct 6, 2020 at 12:25 PM Konstantinos Betsis 
wrote:

> Hi Dominic
>
> That fixed it.
>

Thanks for letting us know and your patience.


> VMs have full connectivity and I don't see any errors on the nodes ovn
> controller.
>
> Thanks for the help and quick responses, I really appreciate it.
>
> In summary for future reference:
>

Thanks for this nice summary, I am sure this will help others in the
community.


> If certificate errors are met need to review:
>
> ovs-vsctl --no-wait get open . external-ids:ovn-remote
> ovs-vsctl --no-wait get open . external-ids:ovn-encap-type
> ovs-vsctl --no-wait get open . external-ids:ovn-encap-ip
>
> The ovn-remote will state if the OVN connection is using TCP or TLS.
>
> We then do:
>
> ovn-nbctl get-ssl
> ovn-nbctl get-connection
> ovn-sbctl get-ssl
> ovn-sbctl get-connection
> ls -l /etc/pki/ovirt-engine/keys/ovn-*
>
>
> As to check the ovn northbound and southbound configuration and listening
> ports and if TCP or TLS is used.
>
> If tls is used we must update the nodes with:
>
> ovn-nbctl set-ssl "ovn northbound interface certificate key" "ovn
> northbound interface certificate file"
> ovn-nbctl set-connection pssl:6641
> ovn-sbctl set-ssl "ovn southbound interface certificate key" "ovn
> southbound interface certificate file"
> ovn-sbctl set-connection pssl:6642
>
>
> The certificates must reside within nodes through the VDSM client.
>
> Finally, we check that all tunnels are established and working ok.
>
> If we get to a stuck chassis we simply stop the ovn service on the node
> and delete the chassis from the northbound interface through:
>
> ovn-sbctl  chassis-del "chassis_ID"
>
> Thank you
> Best Regards
> Konstantinos Betsis
>
>
> On Tue, Oct 6, 2020 at 11:37 AM Dominik Holler  wrote:
>
>>
>>
>> On Tue, Oct 6, 2020 at 10:31 AM Konstantinos Betsis 
>> wrote:
>>
>>> Hi guys
>>>
>>> Sorry to disturb you but i am pretty much stuck at this point with the
>>> ovn southbound interface.
>>>
>>> Is there a way i can flush it and have it reconfigured from ovirt?
>>>
>>>
>> Can you please delete the chassis via
>>
>> ovn-sbctl  chassis-del 32cd0eb4-d763-4036-bbc9-a4d3a4013ee6
>>
>> while  32cd0eb4-d763-4036-bbc9-a4d3a4013ee6 should be replaced with the
>> id of the suspicious chassis show by
>> ovn-sbctl  show
>>
>> The ovn-controller will add the chassis again in a few seconds, but I
>> hope that this would remove the inconsistency in the db.
>>
>>
>>
>>> Thank you
>>> Best Regards
>>> Konstantinos Betsis
>>>
>>> On Thu, Oct 1, 2020 at 6:52 PM Konstantinos Betsis 
>>> wrote:
>>>
 Regarding the ovn-controller logs

 2020-10-01T15:51:03.156Z|14143|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:03.220Z|14144|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:03.284Z|14145|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:03.347Z|14146|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:03.411Z|14147|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:03.474Z|14148|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:03.538Z|14149|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:03.601Z|14150|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:03.664Z|14151|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:03.727Z|14152|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:08.792Z|14153|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:08.855Z|14154|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:08.919Z|14155|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:08.982Z|14156|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:09.046Z|14157|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:09.109Z|14158|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:09.173Z|14159|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:09.236Z|14160|main|INFO|OVNSB commit failed, force
 recompute next time.
 2020-10-01T15:51:09.299Z|14161|main|INFO|OVNSB commit failed, force
 recompute next time.


 I don't think we can see anything more from these.



 On Thu, Oct 1, 2020 at 6:12 PM Konstantinos Betsis 
 wrote:

> Hi Dimitru
>
> I've seen that as well.
> I've deleted the dc01-node2 (ams03-hypersec02) from ovirt.
> I've also issued ovs-vsctl emer-reset.
>
> But ovn-sbctl list chassis still depicts the node twice.
> The ovs-sbctl show still depicts 3 geneve tunnels from dc01-node2
>
> How, can we fix

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-10-06 Thread Konstantinos Betsis 
Hi Dominic

That fixed it.
VMs have full connectivity and I don't see any errors on the nodes ovn
controller.

Thanks for the help and quick responses, I really appreciate it.

In summary for future reference:
If certificate errors are met need to review:

ovs-vsctl --no-wait get open . external-ids:ovn-remote
ovs-vsctl --no-wait get open . external-ids:ovn-encap-type
ovs-vsctl --no-wait get open . external-ids:ovn-encap-ip

The ovn-remote will state if the OVN connection is using TCP or TLS.

We then do:

ovn-nbctl get-ssl
ovn-nbctl get-connection
ovn-sbctl get-ssl
ovn-sbctl get-connection
ls -l /etc/pki/ovirt-engine/keys/ovn-*


As to check the ovn northbound and southbound configuration and listening
ports and if TCP or TLS is used.

If tls is used we must update the nodes with:

ovn-nbctl set-ssl "ovn northbound interface certificate key" "ovn
northbound interface certificate file"
ovn-nbctl set-connection pssl:6641
ovn-sbctl set-ssl "ovn southbound interface certificate key" "ovn
southbound interface certificate file"
ovn-sbctl set-connection pssl:6642


The certificates must reside within nodes through the VDSM client.

Finally, we check that all tunnels are established and working ok.

If we get to a stuck chassis we simply stop the ovn service on the node and
delete the chassis from the northbound interface through:

ovn-sbctl  chassis-del "chassis_ID"

Thank you
Best Regards
Konstantinos Betsis


On Tue, Oct 6, 2020 at 11:37 AM Dominik Holler  wrote:

>
>
> On Tue, Oct 6, 2020 at 10:31 AM Konstantinos Betsis 
> wrote:
>
>> Hi guys
>>
>> Sorry to disturb you but i am pretty much stuck at this point with the
>> ovn southbound interface.
>>
>> Is there a way i can flush it and have it reconfigured from ovirt?
>>
>>
> Can you please delete the chassis via
>
> ovn-sbctl  chassis-del 32cd0eb4-d763-4036-bbc9-a4d3a4013ee6
>
> while  32cd0eb4-d763-4036-bbc9-a4d3a4013ee6 should be replaced with the id
> of the suspicious chassis show by
> ovn-sbctl  show
>
> The ovn-controller will add the chassis again in a few seconds, but I hope
> that this would remove the inconsistency in the db.
>
>
>
>> Thank you
>> Best Regards
>> Konstantinos Betsis
>>
>> On Thu, Oct 1, 2020 at 6:52 PM Konstantinos Betsis 
>> wrote:
>>
>>> Regarding the ovn-controller logs
>>>
>>> 2020-10-01T15:51:03.156Z|14143|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:03.220Z|14144|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:03.284Z|14145|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:03.347Z|14146|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:03.411Z|14147|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:03.474Z|14148|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:03.538Z|14149|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:03.601Z|14150|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:03.664Z|14151|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:03.727Z|14152|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:08.792Z|14153|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:08.855Z|14154|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:08.919Z|14155|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:08.982Z|14156|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:09.046Z|14157|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:09.109Z|14158|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:09.173Z|14159|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:09.236Z|14160|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>> 2020-10-01T15:51:09.299Z|14161|main|INFO|OVNSB commit failed, force
>>> recompute next time.
>>>
>>>
>>> I don't think we can see anything more from these.
>>>
>>>
>>>
>>> On Thu, Oct 1, 2020 at 6:12 PM Konstantinos Betsis 
>>> wrote:
>>>
 Hi Dimitru

 I've seen that as well.
 I've deleted the dc01-node2 (ams03-hypersec02) from ovirt.
 I've also issued ovs-vsctl emer-reset.

 But ovn-sbctl list chassis still depicts the node twice.
 The ovs-sbctl show still depicts 3 geneve tunnels from dc01-node2

 How, can we fix this?

 On Thu, Oct 1, 2020 at 9:59 AM Dumitru Ceara  wrote:

> On 9/30/20 3:41 PM, Konstantinos Betsis wrote:
> > From the configuration I can see only three nodes.
> > "Encap":{
> > #dc01-node02
> >
>

[ovirt-users] Re: ovirt-engine and host certification is expired in ovirt4.0

2020-10-06 Thread Gianluca Cecchi 
On Tue, Oct 6, 2020 at 11:33 AM Martin Perina  wrote:

> Hi,
>
> we have mentioned several times that it doesn't make sense to oVirt on a
> single host setup. So you really need to add 2nd host to your setup, move
> the 1st host to Maintenance and execute Enroll certificates.
>
> Regards,
> Martin
>
>
>
Again, just fallen from the moon this morning?

It is indeed true that some scenarios, like upgrading a self hosted engine
environment composed by only a single host, are not coverable and need some
extra work, but the single host environment is usable
Did you miss this perhaps for RHV 4.4 (and the same for 4.3):

https://access.redhat.com/documentation/en-us/red_hat_hyperconverged_infrastructure_for_virtualization/1.8/html/deploying_red_hat_hyperconverged_infrastructure_for_virtualization_on_a_single_node/index

?

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

[ovirt-users] Re: oVirt Node 4.4.2 is now generally available

2020-10-06 Thread Gianluca Cecchi 
On Tue, Oct 6, 2020 at 11:25 AM Martin Perina  wrote:

>
>> You say to drive a command form the engine that is a VM that runs inside
>> the host, but ask to shutdown VMs running on host before...
>> This is a self hosted engine composed by only one single host.
>> Normally I would use the procedure from the engine web admin gui, one
>> host at a time, but with single host it is not possible.
>>
>
> We have said several times, that it doesn't make sense to use oVirt on a
> single host system. So you either need to attach 2nd host to your setup
> (preferred) or shutdown all VMS and run manual upgrade of your host OS
>
>
We who
In old times there was the all-in-one setup that was substituted from
single host HCI ... developers also put extra efforts to setup the wizard
comprising the single host scenario.
Obviously it is aimed at test bed / devel / home environments, not
production ones.
Do you want me to send you the list of bugzilla contributed by users using
single host environments that helped Red Hat to have a better working RHV
too?

Please think more deeply next time, thanks

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

[ovirt-users] engine-setup in 4.4.2 not using yum/dnf proxy?

2020-10-06 Thread Gianluca Cecchi 
Hello,
I'm testing upgrade from 4.3.10 to 4.4.2 for a standalone manager with
local database environment.
I configured the new engine system as a CentOS 8.2 with a proxy in
/etc/yum.conf (that is a link to /etc/dnf/dnf.com) and that worked for all
the steps until engine-setup.
Now I get this

[root@ovmgr1 ~]# engine-setup
[ INFO  ] Stage: Initializing
[ INFO  ] Stage: Environment setup
  Configuration files:
/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf,
/etc/ovirt-engine-setup.conf.d/10-packaging.conf,
/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf
  Log file:
/var/log/ovirt-engine/setup/ovirt-engine-setup-20201006112458-p84x9i.log
  Version: otopi-1.9.2 (otopi-1.9.2-1.el8)
[ INFO  ] DNF Downloading 1 files, 0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloading CentOS-8 - AppStream 0.00/0.00KB
[ INFO  ] DNF Downloaded CentOS-8 - AppStream
[ INFO  ] DNF Errors during downloading metadata for repository 'AppStream':

[ ERROR ] Execution of setup failed

and I see in netstat during the phase

tcp0  1 10.4.192.43:33418   18.225.36.18:80
SYN_SENT

so it seems it is not using the proxy.
Do I have to put proxy info into any other file?

Thanks,
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/D5WQSM7OZNKJQK3L5CN367W2TRVZZVHZ/

[ovirt-users] Re: ovirt-engine and host certification is expired in ovirt4.0

2020-10-06 Thread Martin Perina 
Hi,

we have mentioned several times that it doesn't make sense to oVirt on a
single host setup. So you really need to add 2nd host to your setup, move
the 1st host to Maintenance and execute Enroll certificates.

Regards,
Martin

On Sun, Oct 4, 2020 at 5:30 PM  wrote:

> From what I observed (but it's not something I try often), if you try to
> enable maintenance on a host and have VMs on it, it will try migrating the
> VMs first, which is a copy-first, state-transfer-afterwards process. So if
> there is no migration target available or if the copying and state-transfer
> fail, the VM will simply continue to run on the original host... and the
> host will refuse to go into maintenance.
>
> It doesn't solve your problem, but the loss of service you fear shouldn't
> happen either... except sometimes oVirt seems to have bugs or the resulting
> network activity cause confusion.
>
> Ah, perhaps this is important: I've only ever tried that by setting a host
> into maintenance (typically for patch updates) via the GUI. I am far less
> convinced that VM migration would also be triggered if you use the
> 'hosted-engine --set-maintenance --mode=local' variant on the host that
> runs the HostedEngine VM. That might just make it unavailable for newly
> started VMs.
> ___
> 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/7D6XC4YHIKMWSCJWZC2TJFMMD27PT4LD/
>


-- 
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
___
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/QWKO2IMWKJSEMRYKMTURNZBHEERKU2WW/

[ovirt-users] Re: oVirt Node 4.4.2 is now generally available

2020-10-06 Thread Martin Perina 
On Mon, Oct 5, 2020 at 3:25 PM Gianluca Cecchi 
wrote:

>
>
> On Mon, Oct 5, 2020 at 3:13 PM Dana Elfassy  wrote:
>
>> Can you shutdown the vms just for the upgrade process?
>>
>> On Mon, Oct 5, 2020 at 1:57 PM Gianluca Cecchi 
>> wrote:
>>
>>> On Mon, Oct 5, 2020 at 12:52 PM Dana Elfassy 
>>> wrote:
>>>
 In order to run the playbooks you would also need the parameters that
 they use - some are set on the engine side
 Why can't you upgrade the host from the engine admin portal?


>>> Because when you upgrade a host you put it into maintenance before.
>>> And this implies no VMs in execution on it.
>>> But if you are in a single host composed environment you cannot
>>>
>>> Gianluca
>>>
>>
> we are talking about chicken-egg problem.
>
> You say to drive a command form the engine that is a VM that runs inside
> the host, but ask to shutdown VMs running on host before...
> This is a self hosted engine composed by only one single host.
> Normally I would use the procedure from the engine web admin gui, one host
> at a time, but with single host it is not possible.
>

We have said several times, that it doesn't make sense to use oVirt on a
single host system. So you either need to attach 2nd host to your setup
(preferred) or shutdown all VMS and run manual upgrade of your host OS


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


-- 
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
___
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/7EATX7RPVUOAQWKLHYOTSTRVJG4M2O6Q/

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-10-06 Thread Dominik Holler 
On Tue, Oct 6, 2020 at 10:31 AM Konstantinos Betsis 
wrote:

> Hi guys
>
> Sorry to disturb you but i am pretty much stuck at this point with the ovn
> southbound interface.
>
> Is there a way i can flush it and have it reconfigured from ovirt?
>
>
Can you please delete the chassis via

ovn-sbctl  chassis-del 32cd0eb4-d763-4036-bbc9-a4d3a4013ee6

while  32cd0eb4-d763-4036-bbc9-a4d3a4013ee6 should be replaced with the id
of the suspicious chassis show by
ovn-sbctl  show

The ovn-controller will add the chassis again in a few seconds, but I hope
that this would remove the inconsistency in the db.



> Thank you
> Best Regards
> Konstantinos Betsis
>
> On Thu, Oct 1, 2020 at 6:52 PM Konstantinos Betsis 
> wrote:
>
>> Regarding the ovn-controller logs
>>
>> 2020-10-01T15:51:03.156Z|14143|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.220Z|14144|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.284Z|14145|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.347Z|14146|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.411Z|14147|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.474Z|14148|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.538Z|14149|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.601Z|14150|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.664Z|14151|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:03.727Z|14152|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:08.792Z|14153|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:08.855Z|14154|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:08.919Z|14155|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:08.982Z|14156|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:09.046Z|14157|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:09.109Z|14158|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:09.173Z|14159|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:09.236Z|14160|main|INFO|OVNSB commit failed, force
>> recompute next time.
>> 2020-10-01T15:51:09.299Z|14161|main|INFO|OVNSB commit failed, force
>> recompute next time.
>>
>>
>> I don't think we can see anything more from these.
>>
>>
>>
>> On Thu, Oct 1, 2020 at 6:12 PM Konstantinos Betsis 
>> wrote:
>>
>>> Hi Dimitru
>>>
>>> I've seen that as well.
>>> I've deleted the dc01-node2 (ams03-hypersec02) from ovirt.
>>> I've also issued ovs-vsctl emer-reset.
>>>
>>> But ovn-sbctl list chassis still depicts the node twice.
>>> The ovs-sbctl show still depicts 3 geneve tunnels from dc01-node2
>>>
>>> How, can we fix this?
>>>
>>> On Thu, Oct 1, 2020 at 9:59 AM Dumitru Ceara  wrote:
>>>
 On 9/30/20 3:41 PM, Konstantinos Betsis wrote:
 > From the configuration I can see only three nodes.
 > "Encap":{
 > #dc01-node02
 >
 "da8fb1dc-f832-4d62-a01d-2e5aef018c8d":{"ip":"10.137.156.56","chassis_name":"be3abcc9-7358-4040-a37b-8d8a782f239c","options":["map",[["csum","true"]]],"type":"geneve"},
 > #dc01-node01
 >
 "4808bd8f-7e46-4f29-9a96-046bb580f0c5":{"ip":"10.137.156.55","chassis_name":"95ccb04a-3a08-4a62-8bc0-b8a7a42956f8","options":["map",[["csum","true"]]],"type":"geneve"},
 > #dc02-node01
 >
 "f20b33ae-5a6b-456c-b9cb-2e4d8b54d8be":{"ip":"192.168.121.164","chassis_name":"c4b23834-aec7-4bf8-8be7-aa94a50a6144","options":["map",[["csum","true"]]],"type":"geneve"}}
 >
 > So I don't understand why the dc01-node02 tries to establish a tunnel
 > with itself.
 >
 > Is there a way for ovn to refresh according to Ovirt network database
 as
 > to not affect VM networks?
 >
 > On Wed, Sep 30, 2020 at 2:33 PM Konstantinos Betsis <
 k.bet...@gmail.com
 > > wrote:
 >
 > Sure
 >
 > I've attached it for easier reference.
 >
 > On Wed, Sep 30, 2020 at 2:21 PM Dominik Holler <
 dhol...@redhat.com
 > > wrote:
 >
 >
 >
 > On Wed, Sep 30, 2020 at 1:16 PM Konstantinos Betsis
 > mailto:k.bet...@gmail.com>> wrote:
 >
 > Hi Dominik
 >
 > The DC01-node02 was formatted and reinstalled and then
 > attached to ovirt environment.
 > Unfortunately we exhibit the same issue.
 > The new DC01-node02 tries to establish geneve tunnels to
 his
 > own IP.
 >
 > [root@dc01-node02 ~]# ovs-vsctl show
 >

[ovirt-users] Re: OVN Geneve tunnels not been established

2020-10-06 Thread Konstantinos Betsis 
Hi guys

Sorry to disturb you but i am pretty much stuck at this point with the ovn
southbound interface.

Is there a way i can flush it and have it reconfigured from ovirt?

Thank you
Best Regards
Konstantinos Betsis

On Thu, Oct 1, 2020 at 6:52 PM Konstantinos Betsis 
wrote:

> Regarding the ovn-controller logs
>
> 2020-10-01T15:51:03.156Z|14143|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:03.220Z|14144|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:03.284Z|14145|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:03.347Z|14146|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:03.411Z|14147|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:03.474Z|14148|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:03.538Z|14149|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:03.601Z|14150|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:03.664Z|14151|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:03.727Z|14152|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:08.792Z|14153|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:08.855Z|14154|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:08.919Z|14155|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:08.982Z|14156|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:09.046Z|14157|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:09.109Z|14158|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:09.173Z|14159|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:09.236Z|14160|main|INFO|OVNSB commit failed, force
> recompute next time.
> 2020-10-01T15:51:09.299Z|14161|main|INFO|OVNSB commit failed, force
> recompute next time.
>
>
> I don't think we can see anything more from these.
>
>
>
> On Thu, Oct 1, 2020 at 6:12 PM Konstantinos Betsis 
> wrote:
>
>> Hi Dimitru
>>
>> I've seen that as well.
>> I've deleted the dc01-node2 (ams03-hypersec02) from ovirt.
>> I've also issued ovs-vsctl emer-reset.
>>
>> But ovn-sbctl list chassis still depicts the node twice.
>> The ovs-sbctl show still depicts 3 geneve tunnels from dc01-node2
>>
>> How, can we fix this?
>>
>> On Thu, Oct 1, 2020 at 9:59 AM Dumitru Ceara  wrote:
>>
>>> On 9/30/20 3:41 PM, Konstantinos Betsis wrote:
>>> > From the configuration I can see only three nodes.
>>> > "Encap":{
>>> > #dc01-node02
>>> >
>>> "da8fb1dc-f832-4d62-a01d-2e5aef018c8d":{"ip":"10.137.156.56","chassis_name":"be3abcc9-7358-4040-a37b-8d8a782f239c","options":["map",[["csum","true"]]],"type":"geneve"},
>>> > #dc01-node01
>>> >
>>> "4808bd8f-7e46-4f29-9a96-046bb580f0c5":{"ip":"10.137.156.55","chassis_name":"95ccb04a-3a08-4a62-8bc0-b8a7a42956f8","options":["map",[["csum","true"]]],"type":"geneve"},
>>> > #dc02-node01
>>> >
>>> "f20b33ae-5a6b-456c-b9cb-2e4d8b54d8be":{"ip":"192.168.121.164","chassis_name":"c4b23834-aec7-4bf8-8be7-aa94a50a6144","options":["map",[["csum","true"]]],"type":"geneve"}}
>>> >
>>> > So I don't understand why the dc01-node02 tries to establish a tunnel
>>> > with itself.
>>> >
>>> > Is there a way for ovn to refresh according to Ovirt network database
>>> as
>>> > to not affect VM networks?
>>> >
>>> > On Wed, Sep 30, 2020 at 2:33 PM Konstantinos Betsis <
>>> k.bet...@gmail.com
>>> > > wrote:
>>> >
>>> > Sure
>>> >
>>> > I've attached it for easier reference.
>>> >
>>> > On Wed, Sep 30, 2020 at 2:21 PM Dominik Holler >> > > wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Sep 30, 2020 at 1:16 PM Konstantinos Betsis
>>> > mailto:k.bet...@gmail.com>> wrote:
>>> >
>>> > Hi Dominik
>>> >
>>> > The DC01-node02 was formatted and reinstalled and then
>>> > attached to ovirt environment.
>>> > Unfortunately we exhibit the same issue.
>>> > The new DC01-node02 tries to establish geneve tunnels to
>>> his
>>> > own IP.
>>> >
>>> > [root@dc01-node02 ~]# ovs-vsctl show
>>> > eff2663e-cb10-41b0-93ba-605bb5c7bd78
>>> > Bridge br-int
>>> > fail_mode: secure
>>> > Port "ovn-95ccb0-0"
>>> > Interface "ovn-95ccb0-0"
>>> > type: geneve
>>> > options: {csum="true", key=flow,
>>> > remote_ip="dc01-node01_IP"}
>>> > Port "ovn-be3abc-0"
>>> > Interface "ovn-be3abc-0"
>>> > type: geneve
>>> >