[ovirt-users] Re: iSCSI multipath with separate subnets... still not possible in 4.4.x?

[Uwe Laverenz]

Am 22.07.20 um 21:55 schrieb Mark R:


Thanks, Uwe. Am I understanding correctly that you're just letting
your nodes attach to the iSCSI storage on their own by leaving
"node.startup = automatic" in /etc/iscsi/iscsid.conf so the hosts
attach to all known targets as they boot, long before oVirt services
ever attempt to connect them? I've considered flipping that to


No, I use OVirt to connect to the iSCSI targets, this works as expected. 
The thing I do not use are OVirt's iSCSI bonds.


What I configure manually is multipathd in order to use round robin policy.


As another poster below mentioned, going the route of two separate
iSCSI bonds in the "iSCSI Multipath" section does work when you're
adding new storage domains. The aspect he talks about, where you
connect both paths and save it, isn't possible if you import an
existing storage domain. When importing, the UI won't expose the
"Add" button that's available when creating a new domain, so you
can't add redundant paths. You can import the storage, then edit it
and discover/login to the other path, but that does _not_ save to the
database and will not persist across reboots or connect on other
hosts you add to the cluster (have to login manually on each). You
can't edit your iSCSI bonds and check the box for these manually
logged in targets either, they'll never populate in that part of the
UI so can't be selected. I think it's just a UI issue because some
very easy fidling in the database makes it work exactly as you'd
expect (and as it does for domains you newly add instead of
importing ).


This sounds quite ugly, I wasn't aware of this.


Sorry, rambling, but I am curious about your "node.startup" setting
in iscid.conf.  If left at 'automatic' (the default), are your hosts
attaching all the disks as they boot and oVirt doesn't mind that? It
could be the path I'll take as honestly I'd much prefer configuring
the storage connections directly.


As I said, the only thing I change is /etc/multipath.conf:

https://lists.ovirt.org/pipermail/users/2017-July/083308.html

cu,
Uwe
___
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/VDWAU4TE5UY5Z3LQYFWMBIFFCLCFKMQ3/

[ovirt-users] Re: Hosted Engine 4.4.1

[Strahil Nikolov via Users]

It's  not yet fixed.  Either check the  other  threads for the  bug id  and fix 
manually  or wait a while for the  fix  to be released.

Best Regards,
Strahil Nikolov

На 22 юли 2020 г. 22:43:22 GMT+03:00, Vijay Sachdeva via Users 
 написа:
>Which version to use for Self-hosted deployment?
>
>Thanks
>Vijay Sachdeva
> 
>
>On 23/07/20, 1:12 AM, "Strahil Nikolov"  wrote:
>
>There  is a bug whose fix is pending release.
>
>Best Regards,
>Strahil Nikolov
>
>На 22 юли 2020 г. 17:54:11 GMT+03:00, Vijay Sachdeva via Users
> написа:
>>Hello Everyone,
>>
>> 
>>
>>Waiting for host to be up task is stuck for hours and when checked
>>engine log found this below:
>>
>> 
>>
>>2020-07-22 16:50:35,717+02 ERROR
>>[org.ovirt.engine.core.sso.utils.SsoUtils] (default task-1) []
> >OAuthException access_denied: Cannot authenticate user 'None@N/A': No
>>valid profile found in credentials..
>>
>> 
>>
>> 
>>
>>Has anyone faced such issue then please help me out..!!
>>
>> 
>>
>>Thanks
>>
>>Vijay Sachdeva
>>
>> 
>
>
>___
>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/H2NG5WBEBAOQKQSN7TE5MGPRB6XFIQEC/
___
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/PLWVU2SJWM3TGMDTX43HCQA7GAJZQCYP/

[ovirt-users] Re: Hosted Engine 4.4.1

[Strahil Nikolov via Users]

It's  not yet fixed.  Either check the  other  threads for the  bug id  and fix 
manually  or wait a while for the  fix  to be released.

Best Regards,
Strahil Nikolov

На 22 юли 2020 г. 22:43:22 GMT+03:00, Vijay Sachdeva via Users 
 написа:
>Which version to use for Self-hosted deployment?
>
>Thanks
>Vijay Sachdeva
> 
>
>On 23/07/20, 1:12 AM, "Strahil Nikolov"  wrote:
>
>There  is a bug whose fix is pending release.
>
>Best Regards,
>Strahil Nikolov
>
>На 22 юли 2020 г. 17:54:11 GMT+03:00, Vijay Sachdeva via Users
> написа:
>>Hello Everyone,
>>
>> 
>>
>>Waiting for host to be up task is stuck for hours and when checked
>>engine log found this below:
>>
>> 
>>
>>2020-07-22 16:50:35,717+02 ERROR
>>[org.ovirt.engine.core.sso.utils.SsoUtils] (default task-1) []
> >OAuthException access_denied: Cannot authenticate user 'None@N/A': No
>>valid profile found in credentials..
>>
>> 
>>
>> 
>>
>>Has anyone faced such issue then please help me out..!!
>>
>> 
>>
>>Thanks
>>
>>Vijay Sachdeva
>>
>> 
>
>
>___
>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/H2NG5WBEBAOQKQSN7TE5MGPRB6XFIQEC/
___
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/S4Q3H2XURMIDMHQLK5UC7LIR4PZCN4ME/

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

[Strahil Nikolov via Users]

You need to keep the  ssh root access  from the engine , so you will need a  
'Match' stanza for the engine.

Of course testing is very important,  but in case you got no test setup - you 
can set a  node in maintenance and experiment  a  little  bit.

Best Regards,
Strahil Nikolov

На 23 юли 2020 г. 21:29:06 GMT+03:00, "Morris, Roy"  
написа:
>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.
>
>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/ZHXS4Y264GG6ZC2G2DPNMQFSBNOF4TDT/

[ovirt-users] Re: RDP

[eevans]

We are talking about the VM portal and SSO and RDP, and it is still not working 
for users. admin@internal can get an RDP login screen and I can use domain 
credentials and login. Users, however, never get the RDP window, even though 
spice comes right up. I even created a test user and made them a SuperUser and 
still no RDP through the portal.
When logged into the vm portal as a normal user I can see the vm's, whick I 
would like the user assigned to that specific vm to only see that machine and 
not all of them. Either way, I click on the console options button and chose 
RDP and nothing happens. if I chose spice, it comes right up. 
There is something some where missing in permissions.
Also, 99% of the time, if I try to add a user from AD,  the ui logged in as 
admin@internal can't find it. i can reboot the Engine host and they are in the 
Users list. not always, but usually. Almost like the ldap portion is shutting 
down or timing out. 
Whatever you need, let me know. I've look at logs and there are errors related 
but googling them hasn't helped.
Just some background: The engine host is separate from the other hosts, it is 
logged into the domain using samba winbind following Red Hat's instructions, as 
are all my hosts and vm's. sssd and kerberos are working without a problem. 
I can do anything on the domain I want to do with the engine host, except use 
RDP SSO to login to a vm. I am very frustrated at this point and need some 
guidance.
Any help would be appreciated.
___
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/WF4YJO37PMZH6B37SUPGXOG4K65REGWD/

[ovirt-users] oVirt 4.3 ssh passwordless setup guide

[Morris, Roy]

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.

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/

[ovirt-users] Re: Upgrade from 4.3 to 4.4 fails with db or user ovirt_engine_history already exists

[Carlos C]

Hi wilderink＠triplon.nl

Could you please share the steps that you usage to do the upgrade from oVirt 
4.3.x to 4.4.x ?
I dont get success in my previous tests, once the current oVirt documentation 
show the steps to Upgrade from Standalone Engine and not Hosted Engine.

Regards
Carlos
___
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/WT3QAPWWOUBK55XJ5JDGRBQIVDCM2FVR/

[ovirt-users] Re: PKI Problem

[Nir Soffer]

On Thu, Jul 23, 2020 at 5:14 PM Yedidyah Bar David  wrote:
>
> On Sun, Jul 19, 2020 at 5:23 PM  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,
> > 

[ovirt-users] Re: PKI Problem

[Nir Soffer]

On Sun, Jul 19, 2020 at 5:22 PM  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.

Right

>  But that needs to be set to my own authority ca file.

Right, but you should not modify this file, it is owned by engine and
your changes will be lost
on the next upgrade.

As documented in the top of the file, you need to create a drop in file:

$ cat /etc/ovirt-imageio/cond.d/99-local.conf
[tls]
ca_file = ...

I think you need to change the key_file and cert_file, otherwise
clients connected
to imageio server may fail to verify the server certificate.

And restart the ovirt-imageio service.

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

[ovirt-users] Re: very very bad iscsi performance

[Paolo Bonzini]

Getting meaningful results is more important than getting good results. If
the benchmark is not meaningful, it is not useful towards fixing the issue.

Did you try virtio-blk with direct LUN?

Paolo

Il gio 23 lug 2020, 16:35 Philip Brown  ha scritto:

> Im in the middle of a priority issue right now, so cant take time out to
> rerun the bench, but...
> Usually in that kind of situation, if you dont turn on sync-to-disk on
> every write, you get benchmarks that are artificially HIGH.
> Forcing O_DIRECT slows throughput down.
> Dont you think the results are bad enough already? :-}
>
> - Original Message -
> From: "Stefan Hajnoczi" 
> To: "Philip Brown" 
> Cc: "Nir Soffer" , "users" ,
> "qemu-block" , "Paolo Bonzini" ,
> "Sergio Lopez Pascual" , "Mordechai Lehrer" <
> mleh...@redhat.com>, "Kevin Wolf" 
> Sent: Thursday, July 23, 2020 6:09:39 AM
> Subject: Re: [BULK]  Re: [ovirt-users] very very bad iscsi performance
>
>
> Hi,
> At first glance it appears that the filebench OLTP workload does not use
> O_DIRECT, so this isn't a measurement of pure disk I/O performance:
> https://github.com/filebench/filebench/blob/master/workloads/oltp.f
>
> If you suspect that disk performance is the issue please run a benchmark
> that bypasses the page cache using O_DIRECT.
>
> The fio setting is direct=1.
>
> Here is an example fio job for 70% read/30% write 4KB random I/O:
>
>   [global]
>   filename=/path/to/device
>   runtime=120
>   ioengine=libaio
>   direct=1
>   ramp_time=10# start measuring after warm-up time
>
>   [read]
>   readwrite=randrw
>   rwmixread=70
>   rwmixwrite=30
>   iodepth=64
>   blocksize=4k
>
> (Based on
> https://blog.vmsplice.net/2017/11/common-disk-benchmarking-mistakes.html)
>
> Stefan
>
>
___
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/SENWWFESXYPGJY3IOV276RQDRMX6GDTH/

[ovirt-users] Adding hypervisor fails, yum links deprecated (Centos 7.7/ oVirt 4.3)

[wjb2130]

Greetings. In a multi-hypervisor environment, we are running Centos 7.7.1908, 
with ovirt-4.3. There are problems adding a new hypervisor, because all the yum 
resources have switched in favor of newer versions.

Is there a proceedure to add a hypervisor under the oVirt Virtualization 
manager while retaining an older, known working OS version like Centos 7.7.1908 
? Upgrading everything across the board isn't an immediate option. There are 
many VMs and hypervisors in production, and can't be disturbed.

In sum: is it still possible to install known working 4.30.33-1.el7? All that 
is presented now is 4.30.46-1.el7
I ran: yum install vdsm-4.30.33-1.el7.x86_64. This completed. However, when I 
tried to add the resulting hypservisor using the oVirt web UI, that fails. Logs 
on that management server showed that the install process insists on using 
4.30.46-1.el7. Any way to avoid this?

2020-07-22 20:30:58,621-04 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(VdsDeploy) [45782a5f] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error 
has occurred during installation of Host hypervisor7: Failed to execute stage 
'Package installation': [u'vdsm-4.30.46-1.el7.x86_64 requires lvm2 >= 
7:2.02.186-7.el7_8.1'].
___
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/ZL45VXRLE2ENWNSWVCIBWYJQQZUECQIP/

[ovirt-users] Re: very very bad iscsi performance

[Philip Brown]

Im in the middle of a priority issue right now, so cant take time out to rerun 
the bench, but...
Usually in that kind of situation, if you dont turn on sync-to-disk on every 
write, you get benchmarks that are artificially HIGH.
Forcing O_DIRECT slows throughput down.
Dont you think the results are bad enough already? :-}

- Original Message -
From: "Stefan Hajnoczi" 
To: "Philip Brown" 
Cc: "Nir Soffer" , "users" , "qemu-block" 
, "Paolo Bonzini" , "Sergio Lopez 
Pascual" , "Mordechai Lehrer" , "Kevin 
Wolf" 
Sent: Thursday, July 23, 2020 6:09:39 AM
Subject: Re: [BULK]  Re: [ovirt-users] very very bad iscsi performance


Hi,
At first glance it appears that the filebench OLTP workload does not use
O_DIRECT, so this isn't a measurement of pure disk I/O performance:
https://github.com/filebench/filebench/blob/master/workloads/oltp.f

If you suspect that disk performance is the issue please run a benchmark
that bypasses the page cache using O_DIRECT.

The fio setting is direct=1.

Here is an example fio job for 70% read/30% write 4KB random I/O:

  [global]
  filename=/path/to/device
  runtime=120
  ioengine=libaio
  direct=1
  ramp_time=10# start measuring after warm-up time

  [read]
  readwrite=randrw
  rwmixread=70
  rwmixwrite=30
  iodepth=64
  blocksize=4k

(Based on 
https://blog.vmsplice.net/2017/11/common-disk-benchmarking-mistakes.html)

Stefan
___
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/5LCSEPHJP4GW6PAUN4ZUAJWEQUEJ6J7F/

[ovirt-users] Re: PKI Problem

[Yedidyah Bar David]

On Sun, Jul 19, 2020 at 5:23 PM  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
> )
>
> Now the image upload works, but obviously this is not the way to fix things. 
> Is there an other way to make image-io accept the certificate from the engine 
> setup, while using my custom certificate? I don't want to replace the 
> 

[ovirt-users] Re: Hosted Engine Ovirt 4.3.8

[Yedidyah Bar David]

On Tue, Jul 21, 2020 at 12:30 AM Vijay Sachdeva via Users
 wrote:
>
> Hi Everyone,
>
>
>
> Does anyone has any idea why hosted engine setup stuck at “Wait for host to 
> be up”.
>
>
>
> It’s been 4 hours deployment is going on and got stuck. Any help  please..!!

Please check/share relevant logs. /var/log/ovirt-hosted-engine-setup
on the host, /var/log/ovirt-engine on the engine. You can find the
engine's address, in order to ssh to it, if it still runs with its
private IP address, by searching the host logs for "local_vm_ip".

Thanks and best regards,


>
>
>
>
>
> Thanks
>
> Vijay Sachdeva
>
>
>
> ___
> 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/XJOXTAN434KIIBPIDBHLHZQRAKCOATKE/



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

[ovirt-users] Re: 4.4.x - VLAN-based logical network can't attach to bonds?

[Mark R]

Hello Ales,

> can you please share supervdsm.log from the relevant host?

Absolutely! Here is the log from the point of opening the "Setup Host Networks" 
UI, as I just drag the "LegacyDMZ" network over onto the same bond that's 
running ovirtmgmt and click "OK".

#-8<--8<-8<

MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,627::supervdsm_server::93::SuperVdsm.ServerCallback::(wrapper) call 
get_lldp_info with ({'devices': []},) {}
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,631::routes::115::root::(get_gateway) The gateway 172.17.96.1 is 
duplicated for the device ovirtmgmt
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,634::routes::115::root::(get_gateway) The gateway 172.17.96.1 is 
duplicated for the device ovirtmgmt
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,635::cmdutils::130::root::(exec_cmd) /sbin/tc qdisc show (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,643::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,644::cmdutils::130::root::(exec_cmd) /sbin/tc class show dev eno34np1 
classid 0:1388 (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,649::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,649::cmdutils::130::root::(exec_cmd) /sbin/tc class show dev ens2f1np1 
classid 0:1388 (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,655::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,699::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-lldp -i 
eno33np0 adminStatus (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,706::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,706::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-tlv -n -i 
eno33np0 (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,712::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,713::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-lldp -i 
eno34np1 adminStatus (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,718::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,719::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-tlv -n -i 
eno34np1 (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,724::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,725::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-lldp -i 
ens2f0np0 adminStatus (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,729::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,730::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-tlv -n -i 
ens2f0np0 (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,735::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,736::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-lldp -i 
ens2f1np1 adminStatus (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,740::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,741::cmdutils::130::root::(exec_cmd) /usr/sbin/lldptool get-tlv -n -i 
ens2f1np1 (cwd None)
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,745::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/4::DEBUG::2020-07-23 
13:37:35,746::supervdsm_server::100::SuperVdsm.ServerCallback::(wrapper) return 
get_lldp_info with {'eno33np0': {'enabled': True, 'tlvs': [{'type': 1, 'name': 
'Chassis ID', 'properties': {'chassis ID subtype': 'MAC', 'chassis ID': 
'8c:04:ba:e9:21:40'}}, {'type': 2, 'name': 'Port ID', 'properties': {'port ID 
subtype': 'Ifname', 'port ID': 'ethernet1/1/16'}}, {'type': 3, 'name': 'Time to 
Live', 'properties': {'time to live': '120'}}, {'type': 4, 'name': 'Port 
Description', 'properties': {'port description': 'Part of VLT LACP trunk to 
rack4slot15 - em3'}}, {'type': 5, 'name': 'System Name', 'properties': {'system 
name': 'TOR-4-A'}}, {'type': 6, 'name': 'System Description', 'properties': 
{'system description': 'Dell EMC Networking OS10 Enterprise.'}}, {'type': 7, 
'name': 'System Capabilities', 'properties': {'system capabilities': 'Repeater, 
Bridge, Router', 'enabled capabilities': 'Repeater, Bridge, Router'}}, {'type': 
8, 'name': 'Management Add
 ress', 'properties': {'management address subtype': 'IPv4', 'management 
address': '192.168.3.1', 'interface numbering subtype': 'Ifindex', 'interface 
numbering': '9'}}, {'type': 8, 'name': 'Management Address', 'properties': 
{'management address subtype': 'IPv6', 'management address': 
'fe80::8e04:baff:fee9:2140', 'interface numbering 

[ovirt-users] Re: oVirt 4.4 Engine data migration & GUI notes

[Yedidyah Bar David]

On Wed, Jul 22, 2020 at 4:41 PM Andrei Verovski  wrote:
>
>
>
> > On 22 Jul 2020, at 13:05, Yedidyah Bar David  wrote:
> >
> > On Wed, Jul 22, 2020 at 12:50 PM Andrei Verovski  
> > wrote:
> >>
> >> Hi !
> >>
> >> I have installed new oVirt 4.4 Engine (as separate entity, not hosted 
> >> engine) and migrated data from old 4.3 installation.
> >> Everything went smooth.
> >
> > Can you please clarify exactly what you did? Did you use engine-backup
> > backup/restore?
>
> Yes, ovirt built-in backup/restore
>
> engine-backup --mode=restore --log=restore1.log 
> --file=ovirt-engine-backup-20200721122423.backup --provision-db 
> --provision-dwh-db --no-restore-permissions
>
> >
> >>
> >> Q: Which PostgreSQL password now active - new one I entered during install 
> >> or old which could migrate with old data?
> >
> > I do not think you should have been prompted for a password during
> > install, unless you refer to Grafana's admin. Please clarify.
> >
> > Perhaps you used a remote database?
>
> Database local, not remote.
> I had a prompt for postgresql password during install.

When exactly?

>
> oVirt Engine 4.4 fresh install on CentOS 8.2 appliance, with these command, 
> instruction from official web site, then restore from backup (snippet above)
>
> yum install https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm
> yum module -y enable javapackages-tools
> yum module -y enable pki-deps
> yum module -y enable postgresql:12
> yum install postgresql-server postgresql-contrib
> postgresql-setup --initdb
> systemctl enable postgresql; systemctl start postgresql
>
> su - postgres -c psql
> create role engine with login encrypted password ‘my password';
> create role ovirt_engine_history with login encrypted password 'my password';
>
> create database engine owner engine template template0 encoding 'UTF8' 
> lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';
> create database ovirt_engine_history owner ovirt_engine_history template 
> template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';
>
> \c engine
> CREATE EXTENSION "uuid-ossp";
> CREATE LANGUAGE plpgsql;
>
> \c ovirt_engine_history
> CREATE EXTENSION "uuid-ossp";
> CREATE LANGUAGE plpgsql;

Sorry, I do not understand.

Please explain the issue with more details - what did you do, what happened.

Please attach relevant logs, e.g. from /var/log/ovirt-engine/setup/* .

Generally speaking, you do not need to create databases or users
manually before restore. Using --provision* options should do that for
you.

In principle, depending on exact conditions, it indeed can happen that
you'll be prompted for DB credentials. It's hard to guess, though,
what was the exact issue, without more details and logs.

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

[ovirt-users] Re: HostedEngine start error: could not find capabilities for arch=x86_64 domaintype=kvm

[Gianluca Cecchi]

On Thu, Jul 23, 2020 at 2:55 PM Gianluca Cecchi 
wrote:

> Hello,
> I'm importing a VM into a new oVirt environment that is in 4.3.10: the new
> host is the same as the previous one (only difference it is in 4.3.10 while
> the old one in 4.3.9).
> This VM acted as a single host HCI environment (with 4.3.9). I imported
> the storage domain containing the VM and its disks and the VM boots ok.
> Now its Hosted Engine VM (that is so a nested VM) doesn't start.
> I think it was good when I stopped/detached it... and so I would like to
> cross check and verify if I missed something configuring the new
> environment or something changed from 4.3.9 to 4.3.10
>
> In vdsm.log I see this reason:
>
> [snip]

> libvirtError: invalid argument: could not find capabilities for
> arch=x86_64 domaintype=kvm
>
> The relevant parts of the generated xml in vdsm.log seems:
>
>
> [snip]

> 
> Skylake-Server
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ...
> 
> destroydestroydestroy
> (vm:2890)
>
> Any insights?
> The configuration of the new 4.3.10 physical oVirt environment that
> contains the VM has this cluster cpu type:
>
> Intel Skylake Server IBRS SSBD MDS Family
>
> Do I have to change it to anything else? I don't remember how it was set
> in 4.3.9
>
> Thanks in advance,
> Gianluca
>
>
It seems that the process of:
put storage domain into maintenance mode
detach storage domain
import storage domain
import virtual machine

didn't preserve the "Pass-Through Host CPU" option that was set for the
original VM... is this expected?
Anyway also setting host cpu passthrough it seems I have the same problem

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

[ovirt-users] Re: [BULK] Re: very very bad iscsi performance

[Stefan Hajnoczi]

On Tue, Jul 21, 2020 at 07:14:53AM -0700, Philip Brown wrote:
> Thank you for the analysis. I have some further comments:
> 
> First off, filebench pre-writes the files before doing oltp benchmarks, so I 
> dont think the thin provisioning is at play here.
> I will double check this, but if you dont hear otherwise, please presume that 
> is the case :)
> 
> Secondly, I am surprised at  your recommendation to use virtio instead of 
> virtio-scsi. since the writeup for virtio-scsi claims it has equivalent 
> performance in general, and adds better scaling
> https://www.ovirt.org/develop/release-management/features/storage/virtio-scsi.html
> 
> As far as your suggestion for using multiple disks for scaling higher:
> We are using an SSD. Isnt the whole advantage of using SSD drives, that you 
> can get the IOP/s performance of 10 drives, out of a single drive?
> We certainly get that using it natively, outside of a VM.
> SO it would be nice to see performance approaching that within an ovirt VM.

Hi,
At first glance it appears that the filebench OLTP workload does not use
O_DIRECT, so this isn't a measurement of pure disk I/O performance:
https://github.com/filebench/filebench/blob/master/workloads/oltp.f

If you suspect that disk performance is the issue please run a benchmark
that bypasses the page cache using O_DIRECT.

The fio setting is direct=1.

Here is an example fio job for 70% read/30% write 4KB random I/O:

  [global]
  filename=/path/to/device
  runtime=120
  ioengine=libaio
  direct=1
  ramp_time=10# start measuring after warm-up time

  [read]
  readwrite=randrw
  rwmixread=70
  rwmixwrite=30
  iodepth=64
  blocksize=4k

(Based on 
https://blog.vmsplice.net/2017/11/common-disk-benchmarking-mistakes.html)

Stefan


signature.asc
Description: PGP signature
___
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/SSXTL4OJ3PNWUEQVA7KJYIKDF74VO34N/

[ovirt-users] HostedEngine start error: could not find capabilities for arch=x86_64 domaintype=kvm

[Gianluca Cecchi]

Hello,
I'm importing a VM into a new oVirt environment that is in 4.3.10: the new
host is the same as the previous one (only difference it is in 4.3.10 while
the old one in 4.3.9).
This VM acted as a single host HCI environment (with 4.3.9). I imported the
storage domain containing the VM and its disks and the VM boots ok.
Now its Hosted Engine VM (that is so a nested VM) doesn't start.
I think it was good when I stopped/detached it... and so I would like to
cross check and verify if I missed something configuring the new
environment or something changed from 4.3.9 to 4.3.10

In vdsm.log I see this reason:

2020-07-23 14:38:20,489+0200 ERROR (vm/9233dc8b) [virt.vm]
(vmId='9233dc8b-7a4d-4fac-8551-dc7407f36548') The vm start process failed
(vm:
934)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 868, in
_startUnderlyingVm
self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2892, in
_run
dom = self._connection.defineXML(self._domain.xml)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py",
line 131, in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 94,
in wrapper
return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3743, in
defineXML
if ret is None:raise libvirtError('virDomainDefineXML() failed',
conn=self)
libvirtError: invalid argument: could not find capabilities for arch=x86_64
domaintype=kvm

The relevant parts of the generated xml in vdsm.log seems:

2020-07-23 14:38:20,487+0200 INFO  (vm/9233dc8b) [virt.vm]
(vmId='9233dc8b-7a4d-4fac-8551-dc7407f36548') http://ovirt.org/vm/tune/1.0;
xmlns:ovirt-vm="http://ovirt.org/vm/1.0;>
HostedEngine
9233dc8b-7a4d-4fac-8551-dc7407f36548
16777216
16777216
1
67108864
32


oVirt
oVirt Node
7-7.1908.0.el7.centos
704e1338-5dec-46f8-a186-8c2080dcefd8
9233dc8b-7a4d-4fac-8551-dc7407f36548











Skylake-Server









...

destroydestroydestroy
(vm:2890)

Any insights?
The configuration of the new 4.3.10 physical oVirt environment that
contains the VM has this cluster cpu type:

Intel Skylake Server IBRS SSBD MDS Family

Do I have to change it to anything else? I don't remember how it was set in
4.3.9

Thanks in advance,
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/ZTANM6XYRNSWXUHV5DIAZ7GVYY6DVOHT/

[ovirt-users] Re: VM Snapshot inconsistent

[Benny Zlotnik]

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

On Wed, Jul 22, 2020 at 1:32 PM Arsène Gschwind 
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 
> 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 
> | ---- | ---- 
> |   1 | 2020-07-06 20:38:36.093+02 | 
> 6bc03db7-82a3-4b7e-9674-0bdd76933eb8 |   2 |
>
>   4 | 

[ovirt-users] Re: problem with custom bond options

[Jiří Sléžka]

On 7/23/20 12:35 PM, Ales Musil wrote:
> 
> 
> On Thu, Jul 23, 2020 at 11:50 AM Jiří Sléžka  > wrote:
> 
> On 7/23/20 11:03 AM, Ales Musil wrote:
> >
> >
> > On Thu, Jul 23, 2020 at 10:35 AM Jiří Sléžka  
> > >> wrote:
> >
> >     Hi,
> >
> >     On 7/23/20 8:38 AM, Ales Musil wrote:
> >     >
> >     >
> >     > On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka
> mailto:jiri.sle...@slu.cz>
> >     >
> >     > 
>  >     >
> >     >     Hello,
> >     >
> >     >
> >     > Hi,
> >     >
> >     >
> >     >     CentOS8, oVirt 4.4.1.10-1.el8
> >     >
> >     >     I am trying to setup active-backup (mode=1) bonding mode
> with
> >     custom
> >     >     properties. I have one 10GE switch, the second is just 1G.
> >     10GE link is
> >     >     the primary one.
> >     >
> >     >     cat /etc/sysconfig/network-scripts/ifcfg-bond0
> >     >
> >     >
> >     > first of all in oVirt 4.4 the network-scripts are not relevant
> >     anymore.
> >     > More relevant is output from 'nmstatectl show'.
> >
> >     thanks, I believed that ifcfg files still describes saved
> interface
> >     configuration (even on nm managed interfaces)...
> >
> >
> > It does but it might not be that detailed as we would have hoped for.
> > Another reason why I said that it is not relevant is of course if
> > someone tries
> > reconfigure the interface through network-scripts.
> 
> well, honestly I did that (modified ifcfg and then use nmcli con
> reload). So right way is using nmcli con modify command?
> 
> 
> Yes or nmstate. Just be aware that anything that you do to interface
> outside of oVirt can have harmful impacts on the host and overall oVirt
> state.
>  
> 
> 
> >     from nmstatectl show I can see that bond0 has specified mac
> address
> >
> >   
>  
> https://paste.slu.cz/?d363cf2c029f6b83#Ew2rCiYyNGrdfffy6bvzSjbb8x4jJsaUdhxkjwThMFka
> >
> >     >     BONDING_OPTS="active_slave=ens5 downdelay=0 miimon=100
> >     >     mode=active-backup primary=ens5 updelay=0"
> >     >     TYPE=Bond
> >     >     BONDING_MASTER=yes
> >     >     PROXY_METHOD=none
> >     >     BROWSER_ONLY=no
> >     >     IPV4_FAILURE_FATAL=no
> >     >     IPV6_DISABLED=yes
> >     >     IPV6INIT=no
> >     >     NAME=bond0
> >     >     UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
> >     >     DEVICE=bond0
> >     >     ONBOOT=yes
> >     >     MTU=9000
> >     >
> >     >     When I try to add a custom parameter "fail_over_mac=active"
> >     (which I
> >     >     believe could solve my problems with stalled mac
> addresses in
> >     switch's
> >     >     cam table in case of failover) I got...
> >     >
> >     >     "Error while executing action HostSetupNetworks: Unexpected
> >     exception"
> >     >
> >     >     ...in manager. In the engine.log it looks like
> >     >
> >     >     2020-07-22 21:20:35,774+02 WARN
> >     >   
> >   
>   [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> >     >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
> Unexpected
> >     >     return value: Status [code=-32603, message=Internal JSON-RPC
> >     error:
> >     >     {'reason': 'MAC address cannot be specified in bond
> interface
> >     along with
> >     >     specified bond options'}]
> >     >     2020-07-22 21:20:35,774+02 ERROR
> >     >   
> >   
>   [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> >     >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
> Failed in
> >     >     'HostSetupNetworksVDS' method
> >     >     2020-07-22 21:20:35,774+02 WARN
> >     >   
> >   
>   [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> >     >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
> Unexpected
> >     >     return value: Status [code=-32603, message=Internal JSON-RPC
> >     error:
> >     >     {'reason': 'MAC address cannot be specified in bond
> interface
> >     along with
> >     >     specified bond options'}]
> >     >     2020-07-22 21:20:35,811+02 ERROR
> >     >   
> >   
>   [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> >     >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
> EVENT_ID:
> >     >     VDS_BROKER_COMMAND_FAILURE(10,802), 

[ovirt-users] Re: problem with custom bond options

[Ales Musil]

On Thu, Jul 23, 2020 at 11:50 AM Jiří Sléžka  wrote:

> On 7/23/20 11:03 AM, Ales Musil wrote:
> >
> >
> > On Thu, Jul 23, 2020 at 10:35 AM Jiří Sléžka  > > wrote:
> >
> > Hi,
> >
> > On 7/23/20 8:38 AM, Ales Musil wrote:
> > >
> > >
> > > On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka  > 
> > > >> wrote:
> > >
> > > Hello,
> > >
> > >
> > > Hi,
> > >
> > >
> > > CentOS8, oVirt 4.4.1.10-1.el8
> > >
> > > I am trying to setup active-backup (mode=1) bonding mode with
> > custom
> > > properties. I have one 10GE switch, the second is just 1G.
> > 10GE link is
> > > the primary one.
> > >
> > > cat /etc/sysconfig/network-scripts/ifcfg-bond0
> > >
> > >
> > > first of all in oVirt 4.4 the network-scripts are not relevant
> > anymore.
> > > More relevant is output from 'nmstatectl show'.
> >
> > thanks, I believed that ifcfg files still describes saved interface
> > configuration (even on nm managed interfaces)...
> >
> >
> > It does but it might not be that detailed as we would have hoped for.
> > Another reason why I said that it is not relevant is of course if
> > someone tries
> > reconfigure the interface through network-scripts.
>
> well, honestly I did that (modified ifcfg and then use nmcli con
> reload). So right way is using nmcli con modify command?
>

Yes or nmstate. Just be aware that anything that you do to interface
outside of oVirt can have harmful impacts on the host and overall oVirt
state.


>
> > from nmstatectl show I can see that bond0 has specified mac address
> >
> >
> https://paste.slu.cz/?d363cf2c029f6b83#Ew2rCiYyNGrdfffy6bvzSjbb8x4jJsaUdhxkjwThMFka
> >
> > > BONDING_OPTS="active_slave=ens5 downdelay=0 miimon=100
> > > mode=active-backup primary=ens5 updelay=0"
> > > TYPE=Bond
> > > BONDING_MASTER=yes
> > > PROXY_METHOD=none
> > > BROWSER_ONLY=no
> > > IPV4_FAILURE_FATAL=no
> > > IPV6_DISABLED=yes
> > > IPV6INIT=no
> > > NAME=bond0
> > > UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
> > > DEVICE=bond0
> > > ONBOOT=yes
> > > MTU=9000
> > >
> > > When I try to add a custom parameter "fail_over_mac=active"
> > (which I
> > > believe could solve my problems with stalled mac addresses in
> > switch's
> > > cam table in case of failover) I got...
> > >
> > > "Error while executing action HostSetupNetworks: Unexpected
> > exception"
> > >
> > > ...in manager. In the engine.log it looks like
> > >
> > > 2020-07-22 21:20:35,774+02 WARN
> > >
> >
>   [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> > > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
> Unexpected
> > > return value: Status [code=-32603, message=Internal JSON-RPC
> > error:
> > > {'reason': 'MAC address cannot be specified in bond interface
> > along with
> > > specified bond options'}]
> > > 2020-07-22 21:20:35,774+02 ERROR
> > >
> >
>   [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> > > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Failed
> in
> > > 'HostSetupNetworksVDS' method
> > > 2020-07-22 21:20:35,774+02 WARN
> > >
> >
>   [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> > > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
> Unexpected
> > > return value: Status [code=-32603, message=Internal JSON-RPC
> > error:
> > > {'reason': 'MAC address cannot be specified in bond interface
> > along with
> > > specified bond options'}]
> > > 2020-07-22 21:20:35,811+02 ERROR
> > >
> >
>   [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> > > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0]
> EVENT_ID:
> > > VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ovirt-hci01.mch.local
> > command
> > > HostSetupNetworksVDS failed: Internal JSON-RPC error:
> > {'reason': 'MAC
> > > address cannot be specified in bond interface along with
> > specified bond
> > > options'}
> > >
> > >
> > > Can you please share supervdsm.log from the relevant host?
> >
> > here it is
> >
> >
> https://paste.slu.cz/?ef8bd7eeae8eeaed#Ej3MXRufm6Y9qjKCkgCXXieP132kRAiswR17ygxQDhft
> >
> >
> > This indeed seems to be a bug. Can you please open BZ
> > ?
>
> done
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1859890
>
> > Only workaround that comes to my mind is to break the bond and define it
> > again with specified mode.
>
> just for sure - do you mean on 

[ovirt-users] CentOS 8.2, ovVirt 4.4.1.8, SHE -- kernel: device-mapper: core: ovirt-ha-broker: sending ioctl 5401 to DM device without required privilege

[Dmitry Kharlamov]

Good day!
CentOS 8.2.2004 (Core), ovVirt 4.4.1.8-1.el8, storage type FC with multipathing.

Please tell me what could be the problem.

Messages are constantly poured into the console and / var / log / messages:
kernel: device-mapper: core: ovirt-ha-broker: sending ioctl 5401 to DM device 
without required privilege

Messages appeared during the installation process (SHE via CLI), during the LUN 
partitioning phase, and after that they do not stop.
At the same time, the installation was successful and now everything is working 
fine.

A similar problem is described here, but no solution has been proposed:
https://bugzilla.redhat.com/show_bug.cgi?id=1838453

Best regards, Dmitry
___
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/CPYAZ7IWJEGDQMNB2E5W6LYN77VTLMEK/

[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

[Yedidyah Bar David]

On Thu, Jul 23, 2020 at 10:23 AM Florian Schmid  wrote:
>
> Hello Yedidyah,
>
> thank you for this great answer.
>
> I will answer in the text below.
>
> BR Florian
>
>
> - Ursprüngliche Mail -
> Von: "Yedidyah Bar David" 
> An: "Florian Schmid" 
> CC: "Tomas Golembiovsky" , "Sandro Bonazzola" 
> , "users" 
> Gesendet: Donnerstag, 23. Juli 2020 08:37:21
> Betreff: Re: [ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN
>
> On Wed, Jul 22, 2020 at 5:34 PM Florian Schmid via Users
>  wrote:
> >>
> >> Hi,
> >>
> >> after digging a bit deeper, it looks like it is the problem with the 
> >> qemu-guest-agent.
> >>
> >> It does only report the hostname and nothing more. It uses this function: 
> >> g_get_host_name ()
> >>
> >> This function always returns the value in /etc/hostname and this is 
> >> normally the short name of the VM without the domain part.
> >>
> >> It looks like, that the ovirt-guest-agent made this different,
> >
> >Indeed, and from checking the git log, it seems like it did this since
> >the very first commit - already then,
> >ovirt-guest-agent/GuestAgentLinux2.py had:
> >def getMachineName(self):
> >return socket.getfqdn()
>
> Correct, this is what I wanted back.
>
> >
> >> but this is not working anymore with python 3.
> >
> >If in "this" you refer to ovirt-guest-agent, then it's deprecated:
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=1672732
>
> Yes, I know. Now using the QGA with oVirt 4.3 reports only the short hostname.
>
> >
> >>
> >> There was a recent patch for qga -> 
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1845127
> >
> >This bug seems to discuss something else, not directly related to your
> >own issue.
> >
> >> but this won't help me, because even when this patch would add the FQDN to 
> >> oVirt back, there won't be a package for this for Ubuntu 20.04 and 
> >> probably also not for RedHat/CentOS 8.
> >
> >Not sure what you mean here. The bug is on qga, and fixing it (or your
> >own issue) is unrelated to oga's deprecation.
>
> I wanted to say, that this change might also impact the reported hostname, 
> but I don't think so...
>
> >
> >Your issue seems to be, to me:
> >
> >1. oga used to report the FQDN, as returned by python's socket.getfqdn()
> >2. qga returns something else (and this something else might be
> >changed, following above bug, but likely not to what you want).
> >3. oVirt now uses qga instead of oga, thus changing its past behavior.
> >4. You want the old behavior back - basically, claiming this is a regression.
>
> Yes, exactly.
>
> >
> >If so, then:
> >
> >1. You are welcome to open a bug about this, on qga.
> >2. Your request *might* be rejected, on the ground of breaking
> >compatibility for existing/old users of qga (say, using virt-manager
> >or whatever other virt tool, without oga installed)
>
> I'm 100 % sure, that they will reject this.
>
> >
> >Alternatively, or if this bug is rejected, you can open two new bugs:
> >
> >1. one on qga, to provide the fqdn (using, hopefully, logic similar to
> >python's getfqdn, although qga is written in C)
>
> Possible, but this won't help me a lot, because even if they add a new 
> function to qga, oVirt would need to be changed too, to access this function 
> instead of the one it is using now.
>
> >2. other on the oVirt engine, to use this new functionality of qga
> >instead of the existing one.
>
> Yes.
>
> >
> >You also have another alternative - just adapt your machines to have
> >the fqdn as the hostname. I personally think this is the best way to
> >go. Have 'hostname' return the FQDN you want, and only use 'hostname
> >-s' where you really want it to be short. How do you set the hostnames
> >of your machines?
>
> This is what I don't know, if this has some drawbacks.
> I have checked this on internet, but haven't find a lot about it, what is 
> digging deeper.
>
> Maybe someone here has some experience with using FQDN for hostname?

I use this on all my machines (CentOS/RHEL ones, anyway) and all seems ok.
I do recommend, obviously, that you do your own research/testing.

>
> I can live with such a solution, when it doesn't have big drawbacks...

The only actual drawback I can think of is that the hostname is limited
to 64 chars, whereas the FQDN can be up to 255 chars. So if you want a
longer FQDN, you can't use it as the hostname.

Another obvious drawback is that applications that use the full hostname
for reporting, as opposed to explicitly using 'hostname -s', will now
have the FQDN in their reports, which you might find too long etc.
I personally consider this an advantage, not a drawback. Memory and disk
space are cheap these days, but time is still expensive - if you get a
report about "servera" instead of "servera.somedomain" and it causes you
to spend time understanding what server this is, it's more waste, IMO,
than having "servera.somedomain" everywhere. But that's obviously a
personal matter...

Best regards,
-- 
Didi

[ovirt-users] Re: problem with custom bond options

[Jiří Sléžka]

On 7/23/20 11:03 AM, Ales Musil wrote:
> 
> 
> On Thu, Jul 23, 2020 at 10:35 AM Jiří Sléžka  > wrote:
> 
> Hi,
> 
> On 7/23/20 8:38 AM, Ales Musil wrote:
> >
> >
> > On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka  
> > >> wrote:
> >
> >     Hello,
> >
> >
> > Hi,
> >
> >
> >     CentOS8, oVirt 4.4.1.10-1.el8
> >
> >     I am trying to setup active-backup (mode=1) bonding mode with
> custom
> >     properties. I have one 10GE switch, the second is just 1G.
> 10GE link is
> >     the primary one.
> >
> >     cat /etc/sysconfig/network-scripts/ifcfg-bond0
> >
> >
> > first of all in oVirt 4.4 the network-scripts are not relevant
> anymore.
> > More relevant is output from 'nmstatectl show'.
> 
> thanks, I believed that ifcfg files still describes saved interface
> configuration (even on nm managed interfaces)...
> 
> 
> It does but it might not be that detailed as we would have hoped for.
> Another reason why I said that it is not relevant is of course if
> someone tries
> reconfigure the interface through network-scripts.

well, honestly I did that (modified ifcfg and then use nmcli con
reload). So right way is using nmcli con modify command?

> from nmstatectl show I can see that bond0 has specified mac address
> 
> 
> https://paste.slu.cz/?d363cf2c029f6b83#Ew2rCiYyNGrdfffy6bvzSjbb8x4jJsaUdhxkjwThMFka
> 
> >     BONDING_OPTS="active_slave=ens5 downdelay=0 miimon=100
> >     mode=active-backup primary=ens5 updelay=0"
> >     TYPE=Bond
> >     BONDING_MASTER=yes
> >     PROXY_METHOD=none
> >     BROWSER_ONLY=no
> >     IPV4_FAILURE_FATAL=no
> >     IPV6_DISABLED=yes
> >     IPV6INIT=no
> >     NAME=bond0
> >     UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
> >     DEVICE=bond0
> >     ONBOOT=yes
> >     MTU=9000
> >
> >     When I try to add a custom parameter "fail_over_mac=active"
> (which I
> >     believe could solve my problems with stalled mac addresses in
> switch's
> >     cam table in case of failover) I got...
> >
> >     "Error while executing action HostSetupNetworks: Unexpected
> exception"
> >
> >     ...in manager. In the engine.log it looks like
> >
> >     2020-07-22 21:20:35,774+02 WARN
> >   
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Unexpected
> >     return value: Status [code=-32603, message=Internal JSON-RPC
> error:
> >     {'reason': 'MAC address cannot be specified in bond interface
> along with
> >     specified bond options'}]
> >     2020-07-22 21:20:35,774+02 ERROR
> >   
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Failed in
> >     'HostSetupNetworksVDS' method
> >     2020-07-22 21:20:35,774+02 WARN
> >   
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Unexpected
> >     return value: Status [code=-32603, message=Internal JSON-RPC
> error:
> >     {'reason': 'MAC address cannot be specified in bond interface
> along with
> >     specified bond options'}]
> >     2020-07-22 21:20:35,811+02 ERROR
> >   
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> >     (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] EVENT_ID:
> >     VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ovirt-hci01.mch.local
> command
> >     HostSetupNetworksVDS failed: Internal JSON-RPC error:
> {'reason': 'MAC
> >     address cannot be specified in bond interface along with
> specified bond
> >     options'}
> >
> >
> > Can you please share supervdsm.log from the relevant host?
> 
> here it is
> 
> 
> https://paste.slu.cz/?ef8bd7eeae8eeaed#Ej3MXRufm6Y9qjKCkgCXXieP132kRAiswR17ygxQDhft
> 
> 
> This indeed seems to be a bug. Can you please open BZ
> ?

done

https://bugzilla.redhat.com/show_bug.cgi?id=1859890

> Only workaround that comes to my mind is to break the bond and define it
> again with specified mode.

just for sure - do you mean on the live host which hosts running HE vm
or on a new installation?

It looks like there is the same o similar bug while installing hosted
engine via ovirt-hosted-engine-setup. I tried it many times yesterday
and installation failed with the same error

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The
host has been set in non_operational status, deployment errors:   code
505: Host ovirt-hci01.stud.slu.cz 

[ovirt-users] Re: problem with custom bond options

[Ales Musil]

On Thu, Jul 23, 2020 at 10:35 AM Jiří Sléžka  wrote:

> Hi,
>
> On 7/23/20 8:38 AM, Ales Musil wrote:
> >
> >
> > On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka  > > wrote:
> >
> > Hello,
> >
> >
> > Hi,
> >
> >
> > CentOS8, oVirt 4.4.1.10-1.el8
> >
> > I am trying to setup active-backup (mode=1) bonding mode with custom
> > properties. I have one 10GE switch, the second is just 1G. 10GE link
> is
> > the primary one.
> >
> > cat /etc/sysconfig/network-scripts/ifcfg-bond0
> >
> >
> > first of all in oVirt 4.4 the network-scripts are not relevant anymore.
> > More relevant is output from 'nmstatectl show'.
>
> thanks, I believed that ifcfg files still describes saved interface
> configuration (even on nm managed interfaces)...
>

It does but it might not be that detailed as we would have hoped for.
Another reason why I said that it is not relevant is of course if someone
tries
reconfigure the interface through network-scripts.


>
> from nmstatectl show I can see that bond0 has specified mac address
>
>
> https://paste.slu.cz/?d363cf2c029f6b83#Ew2rCiYyNGrdfffy6bvzSjbb8x4jJsaUdhxkjwThMFka
>
> > BONDING_OPTS="active_slave=ens5 downdelay=0 miimon=100
> > mode=active-backup primary=ens5 updelay=0"
> > TYPE=Bond
> > BONDING_MASTER=yes
> > PROXY_METHOD=none
> > BROWSER_ONLY=no
> > IPV4_FAILURE_FATAL=no
> > IPV6_DISABLED=yes
> > IPV6INIT=no
> > NAME=bond0
> > UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
> > DEVICE=bond0
> > ONBOOT=yes
> > MTU=9000
> >
> > When I try to add a custom parameter "fail_over_mac=active" (which I
> > believe could solve my problems with stalled mac addresses in
> switch's
> > cam table in case of failover) I got...
> >
> > "Error while executing action HostSetupNetworks: Unexpected
> exception"
> >
> > ...in manager. In the engine.log it looks like
> >
> > 2020-07-22 21:20:35,774+02 WARN
> >
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Unexpected
> > return value: Status [code=-32603, message=Internal JSON-RPC error:
> > {'reason': 'MAC address cannot be specified in bond interface along
> with
> > specified bond options'}]
> > 2020-07-22 21:20:35,774+02 ERROR
> >
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Failed in
> > 'HostSetupNetworksVDS' method
> > 2020-07-22 21:20:35,774+02 WARN
> >
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Unexpected
> > return value: Status [code=-32603, message=Internal JSON-RPC error:
> > {'reason': 'MAC address cannot be specified in bond interface along
> with
> > specified bond options'}]
> > 2020-07-22 21:20:35,811+02 ERROR
> >
>  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> > (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] EVENT_ID:
> > VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ovirt-hci01.mch.local
> command
> > HostSetupNetworksVDS failed: Internal JSON-RPC error: {'reason': 'MAC
> > address cannot be specified in bond interface along with specified
> bond
> > options'}
> >
> >
> > Can you please share supervdsm.log from the relevant host?
>
> here it is
>
>
> https://paste.slu.cz/?ef8bd7eeae8eeaed#Ej3MXRufm6Y9qjKCkgCXXieP132kRAiswR17ygxQDhft


This indeed seems to be a bug. Can you please open BZ
?

Only workaround that comes to my mind is to break the bond and define it
again with specified mode.

Let me know if it works.

Thanks,
Ales


>
>
> Cheers,
>
> Jiri
>
>
> > Could anybody explain me what 'MAC address cannot be specified in
> bond
> > interface along with specified bond options' means? I believe a MAC
> > address is not configured in interface configuration.
> >
> > Or does it mean 'fail_over_mac=active' is not supported in oVirt?
> >
> > Thanks in advance,
> >
> > Jiri
> >
> >
> >
> >
> >
> > ___
> > 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/BUGNSEBD3OBSUPASLJQYYJIF5767XMDE/
> >
> >
> >
> > Thank you.
> > Regards,
> > Ales
> >
> > --
> >
> > Ales Musil
> >
> > Software Engineer - RHV Network
> >
> > Red Hat EMEA 
> >
> > amu...@redhat.com IM: amusil
> >
> > 
> >
>
>
>

[ovirt-users] Re: problem with custom bond options

[Jiří Sléžka]

Hi,

On 7/23/20 8:38 AM, Ales Musil wrote:
> 
> 
> On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka  > wrote:
> 
> Hello,
> 
> 
> Hi,
> 
> 
> CentOS8, oVirt 4.4.1.10-1.el8
> 
> I am trying to setup active-backup (mode=1) bonding mode with custom
> properties. I have one 10GE switch, the second is just 1G. 10GE link is
> the primary one.
> 
> cat /etc/sysconfig/network-scripts/ifcfg-bond0
> 
> 
> first of all in oVirt 4.4 the network-scripts are not relevant anymore.
> More relevant is output from 'nmstatectl show'.

thanks, I believed that ifcfg files still describes saved interface
configuration (even on nm managed interfaces)...

from nmstatectl show I can see that bond0 has specified mac address

https://paste.slu.cz/?d363cf2c029f6b83#Ew2rCiYyNGrdfffy6bvzSjbb8x4jJsaUdhxkjwThMFka

> BONDING_OPTS="active_slave=ens5 downdelay=0 miimon=100
> mode=active-backup primary=ens5 updelay=0"
> TYPE=Bond
> BONDING_MASTER=yes
> PROXY_METHOD=none
> BROWSER_ONLY=no
> IPV4_FAILURE_FATAL=no
> IPV6_DISABLED=yes
> IPV6INIT=no
> NAME=bond0
> UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
> DEVICE=bond0
> ONBOOT=yes
> MTU=9000
> 
> When I try to add a custom parameter "fail_over_mac=active" (which I
> believe could solve my problems with stalled mac addresses in switch's
> cam table in case of failover) I got...
> 
> "Error while executing action HostSetupNetworks: Unexpected exception"
> 
> ...in manager. In the engine.log it looks like
> 
> 2020-07-22 21:20:35,774+02 WARN
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Unexpected
> return value: Status [code=-32603, message=Internal JSON-RPC error:
> {'reason': 'MAC address cannot be specified in bond interface along with
> specified bond options'}]
> 2020-07-22 21:20:35,774+02 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Failed in
> 'HostSetupNetworksVDS' method
> 2020-07-22 21:20:35,774+02 WARN
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Unexpected
> return value: Status [code=-32603, message=Internal JSON-RPC error:
> {'reason': 'MAC address cannot be specified in bond interface along with
> specified bond options'}]
> 2020-07-22 21:20:35,811+02 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] EVENT_ID:
> VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ovirt-hci01.mch.local command
> HostSetupNetworksVDS failed: Internal JSON-RPC error: {'reason': 'MAC
> address cannot be specified in bond interface along with specified bond
> options'}
> 
> 
> Can you please share supervdsm.log from the relevant host?

here it is

https://paste.slu.cz/?ef8bd7eeae8eeaed#Ej3MXRufm6Y9qjKCkgCXXieP132kRAiswR17ygxQDhft

Cheers,

Jiri


> Could anybody explain me what 'MAC address cannot be specified in bond
> interface along with specified bond options' means? I believe a MAC
> address is not configured in interface configuration.
> 
> Or does it mean 'fail_over_mac=active' is not supported in oVirt?
> 
> Thanks in advance,
> 
> Jiri
> 
> 
> 
> 
> 
> ___
> 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/BUGNSEBD3OBSUPASLJQYYJIF5767XMDE/
> 
> 
> 
> Thank you.
> Regards,
> Ales
> 
> -- 
> 
> Ales Musil
> 
> Software Engineer - RHV Network
> 
> Red Hat EMEA 
> 
> amu...@redhat.com     IM: amusil
> 
> 
> 




smime.p7s
Description: S/MIME Cryptographic Signature
___
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/YQ5SW7FIHB57UIDB37WEHEIFKZOXVA6F/

[ovirt-users] Re: New ovirt 4.4.0.3-1.el8 leaves disks in illegal state on all snapshot actions

[Benny Zlotnik]

it was fixed[1], you need to upgrade to libvirt 6+ and qemu 4.2+


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1785939


On Thu, Jul 23, 2020 at 9:59 AM Henri Aanstoot  wrote:

>
>
>
>
> Hi all,
>
> I've got 2 two node setup, image based installs.
> When doing ova exports or generic snapshots, things seem in order.
> Removing snapshots shows warning 'disk in illegal state'
>
> Mouse hover shows .. please do not shutdown before succesfully remove
> snapshot
>
>
> ovirt-engine log
> 2020-07-22 16:40:37,549+02 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedExecutorService-commandCoordinator-Thread-2)
> [264b0047-5aa6-4380-9d32-eb328fd6bed0] EVENT_ID:
> VDS_BROKER_COMMAND_FAILURE(10,802), VDSM node2.lab command MergeVDS failed:
> Merge failed
> 2020-07-22 16:40:37,549+02 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.MergeVDSCommand]
> (EE-ManagedExecutorService-commandCoordinator-Thread-2)
> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Command 'MergeVDSCommand(HostName =
> node2.lab,
> MergeVDSCommandParameters:{hostId='02df5213-1243-4671-a1c6-6489d7146319',
> vmId='64c25543-bef7-4fdd-8204-6507046f5a34',
> storagePoolId='5a4ea80c-b3b2-11ea-a890-00163e3cb866',
> storageDomainId='9a12f1b2-5378-46cc-964d-3575695e823f',
> imageGroupId='3f7ac8d8-f1ab-4c7a-91cc-f34d0b8a1cb8',
> imageId='c757e740-9013-4ae0-901d-316932f4af0e',
> baseImageId='ebe50730-dec3-4f29-8a38-9ae7c59f2aef',
> topImageId='c757e740-9013-4ae0-901d-316932f4af0e', bandwidth='0'})'
> execution failed: VDSGenericException: VDSErrorException: Failed to
> MergeVDS, error = Merge failed, code = 52
> 2020-07-22 16:40:37,549+02 ERROR [org.ovirt.engine.core.bll.MergeCommand]
> (EE-ManagedExecutorService-commandCoordinator-Thread-2)
> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Engine exception thrown while
> sending merge command: org.ovirt.engine.core.common.errors.EngineException:
> EngineException:
> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
> VDSGenericException: VDSErrorException: Failed to MergeVDS, error = Merge
> failed, code = 52 (Failed with error mergeErr and code 52)
> Caused by: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
> VDSGenericException: VDSErrorException: Failed to MergeVDS, error = Merge
> failed, code = 52
>   
>io='threads'/>
> 2020-07-22 16:40:39,659+02 ERROR
> [org.ovirt.engine.core.bll.MergeStatusCommand]
> (EE-ManagedExecutorService-commandCoordinator-Thread-3)
> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Failed to live merge. Top volume
> c757e740-9013-4ae0-901d-316932f4af0e is still in qemu chain
> [ebe50730-dec3-4f29-8a38-9ae7c59f2aef, c757e740-9013-4ae0-901d-316932f4af0e]
> 2020-07-22 16:40:41,524+02 ERROR
> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand]
> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-58)
> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Command id:
> 'e0b2bce7-afe0-4955-ae46-38bcb8719852 failed child command status for step
> 'MERGE_STATUS'
> 2020-07-22 16:40:42,597+02 ERROR
> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand]
> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-53)
> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Merging of snapshot
> 'ef8f7e06-e48c-4a8c-983c-64e3d4ebfcf9' images
> 'ebe50730-dec3-4f29-8a38-9ae7c59f2aef'..'c757e740-9013-4ae0-901d-316932f4af0e'
> failed. Images have been marked illegal and can no longer be previewed or
> reverted to. Please retry Live Merge on the snapshot to complete the
> operation.
> 2020-07-22 16:40:42,603+02 ERROR
> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand]
> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-53)
> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Ending command
> 'org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand'
> with failure.
> 2020-07-22 16:40:43,679+02 ERROR
> [org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand]
> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-15)
> [264b0047-5aa6-4380-9d32-eb328fd6bed0] Ending command
> 'org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand' with failure.
> 2020-07-22 16:40:43,774+02 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-15)
> [264b0047-5aa6-4380-9d32-eb328fd6bed0] EVENT_ID:
> USER_REMOVE_SNAPSHOT_FINISHED_FAILURE(357), Failed to delete snapshot
> 'Auto-generated for Export To OVA' for VM 'Adhoc'.
>
>
> VDSM on hypervisor
> 2020-07-22 14:14:30,220+0200 ERROR (jsonrpc/5) [virt.vm]
> (vmId='14283e6d-c3f0-4011-b90f-a1272f0fbc10') Live merge failed (job:
> e59c54d9-b8d3-44d0-9147-9dd40dff57b9) (vm:5381)
> if ret == -1: raise libvirtError ('virDomainBlockCommit() failed',
> dom=self)
> libvirt.libvirtError: internal error: qemu block name 'json:{"backing":
> {"driver": "qcow2", "file": {"driver": "file", "filename":
> 

[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

[Florian Schmid via Users]

Hello Yedidyah, 

thank you for this great answer. 

I will answer in the text below. 

BR Florian


- Ursprüngliche Mail -
Von: "Yedidyah Bar David" 
An: "Florian Schmid" 
CC: "Tomas Golembiovsky" , "Sandro Bonazzola" 
, "users" 
Gesendet: Donnerstag, 23. Juli 2020 08:37:21
Betreff: Re: [ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

On Wed, Jul 22, 2020 at 5:34 PM Florian Schmid via Users
 wrote:
>>
>> Hi,
>>
>> after digging a bit deeper, it looks like it is the problem with the 
>> qemu-guest-agent.
>>
>> It does only report the hostname and nothing more. It uses this function: 
>> g_get_host_name ()
>>
>> This function always returns the value in /etc/hostname and this is normally 
>> the short name of the VM without the domain part.
>>
>> It looks like, that the ovirt-guest-agent made this different,
>
>Indeed, and from checking the git log, it seems like it did this since
>the very first commit - already then,
>ovirt-guest-agent/GuestAgentLinux2.py had:
>def getMachineName(self):
>return socket.getfqdn()

Correct, this is what I wanted back.

>
>> but this is not working anymore with python 3.
>
>If in "this" you refer to ovirt-guest-agent, then it's deprecated:
>
>https://bugzilla.redhat.com/show_bug.cgi?id=1672732

Yes, I know. Now using the QGA with oVirt 4.3 reports only the short hostname.

>
>>
>> There was a recent patch for qga -> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1845127
>
>This bug seems to discuss something else, not directly related to your
>own issue.
>
>> but this won't help me, because even when this patch would add the FQDN to 
>> oVirt back, there won't be a package for this for Ubuntu 20.04 and probably 
>> also not for RedHat/CentOS 8.
>
>Not sure what you mean here. The bug is on qga, and fixing it (or your
>own issue) is unrelated to oga's deprecation.

I wanted to say, that this change might also impact the reported hostname, but 
I don't think so...

>
>Your issue seems to be, to me:
>
>1. oga used to report the FQDN, as returned by python's socket.getfqdn()
>2. qga returns something else (and this something else might be
>changed, following above bug, but likely not to what you want).
>3. oVirt now uses qga instead of oga, thus changing its past behavior.
>4. You want the old behavior back - basically, claiming this is a regression.

Yes, exactly.

>
>If so, then:
>
>1. You are welcome to open a bug about this, on qga.
>2. Your request *might* be rejected, on the ground of breaking
>compatibility for existing/old users of qga (say, using virt-manager
>or whatever other virt tool, without oga installed)

I'm 100 % sure, that they will reject this.

>
>Alternatively, or if this bug is rejected, you can open two new bugs:
>
>1. one on qga, to provide the fqdn (using, hopefully, logic similar to
>python's getfqdn, although qga is written in C)

Possible, but this won't help me a lot, because even if they add a new function 
to qga, oVirt would need to be changed too, to access this function instead of 
the one it is using now.

>2. other on the oVirt engine, to use this new functionality of qga
>instead of the existing one.

Yes.

>
>You also have another alternative - just adapt your machines to have
>the fqdn as the hostname. I personally think this is the best way to
>go. Have 'hostname' return the FQDN you want, and only use 'hostname
>-s' where you really want it to be short. How do you set the hostnames
>of your machines?

This is what I don't know, if this has some drawbacks.
I have checked this on internet, but haven't find a lot about it, what is 
digging deeper.

Maybe someone here has some experience with using FQDN for hostname?

I can live with such a solution, when it doesn't have big drawbacks...

I can set the hostname via ansible, so this would not be a big problem for 
doing it.

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

[ovirt-users] Re: 4.4.x - VLAN-based logical network can't attach to bonds?

[Ales Musil]

On Wed, Jul 22, 2020 at 9:49 PM Mark R  wrote:

> Hello all,
>

Hi,


> New 4.4.1 hosted-engine install. Pre-deploy, the host already had bond0
> and its iSCSI interfaces configured. The deploy correctly sets up the
> ovirtmgmt interface using the bond, and when everything finishes up it's
> working as expected.  However, I then need to create a VLAN-based network
> and attach to the same bond0 interface. Editing the host networks and
> dragging the VLAN 102 interface to the bond alongside ovirtmgmt, then
> clicking "OK" results in a failure every time. The error returned is:
>
> VDSM ovirt5.domain.com command HostSetupNetworksVDS failed: Internal
> JSON-RPC error: {'reason': 'Unexpected failure of libnm when running the
> mainloop: run execution'}
>

can you please share supervdsm.log from the relevant host?



> I can break the bond and apply this an any other VLAN-based network at
> will, but then it's not possible to add the interface I removed to create
> the bond again. That may be by design and it's not supposed to be possible
> to attach an interface and create a bond once you've already assigned
> logical networks to it. The error there is "Error while executing action
> HostSetupNetworks: Interface already in use".
>

This is in fact desired by design as we do not support having an interface
under bond and at the same time have a network defined over it.


>
> I'm just putting out feelers to see if this is a known issue that other
> people are hitting, or are other folks with hosted-engine 4.4.x deploys
> readily creating that initial bond0 interface and assigning any VLAN-based
> logical networks they want w/o issue?  These same hosts (they still aren't
> in prod so I rebuild them at will) run 4.3 with no issues and setting up
> the exact same network configurations works flawlessly, it just becomes an
> issue on 4.4.1. This host was freshly installed today and has all updates.
>
> Thanks,
> Mark
> ___
> 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/XF7PANDZBAH5J7FSJFUEUAOL6T7XBRHL/
>


-- 

Ales Musil

Software Engineer - RHV Network

Red Hat EMEA 

amu...@redhat.comIM: amusil

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

[ovirt-users] New ovirt 4.4.0.3-1.el8 leaves disks in illegal state on all snapshot actions

[Henri Aanstoot]

Hi all,

I've got 2 two node setup, image based installs.
When doing ova exports or generic snapshots, things seem in order.
Removing snapshots shows warning 'disk in illegal state'

Mouse hover shows .. please do not shutdown before succesfully remove
snapshot


ovirt-engine log
2020-07-22 16:40:37,549+02 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedExecutorService-commandCoordinator-Thread-2)
[264b0047-5aa6-4380-9d32-eb328fd6bed0] EVENT_ID:
VDS_BROKER_COMMAND_FAILURE(10,802), VDSM node2.lab command MergeVDS failed:
Merge failed
2020-07-22 16:40:37,549+02 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.MergeVDSCommand]
(EE-ManagedExecutorService-commandCoordinator-Thread-2)
[264b0047-5aa6-4380-9d32-eb328fd6bed0] Command 'MergeVDSCommand(HostName =
node2.lab,
MergeVDSCommandParameters:{hostId='02df5213-1243-4671-a1c6-6489d7146319',
vmId='64c25543-bef7-4fdd-8204-6507046f5a34',
storagePoolId='5a4ea80c-b3b2-11ea-a890-00163e3cb866',
storageDomainId='9a12f1b2-5378-46cc-964d-3575695e823f',
imageGroupId='3f7ac8d8-f1ab-4c7a-91cc-f34d0b8a1cb8',
imageId='c757e740-9013-4ae0-901d-316932f4af0e',
baseImageId='ebe50730-dec3-4f29-8a38-9ae7c59f2aef',
topImageId='c757e740-9013-4ae0-901d-316932f4af0e', bandwidth='0'})'
execution failed: VDSGenericException: VDSErrorException: Failed to
MergeVDS, error = Merge failed, code = 52
2020-07-22 16:40:37,549+02 ERROR [org.ovirt.engine.core.bll.MergeCommand]
(EE-ManagedExecutorService-commandCoordinator-Thread-2)
[264b0047-5aa6-4380-9d32-eb328fd6bed0] Engine exception thrown while
sending merge command: org.ovirt.engine.core.common.errors.EngineException:
EngineException:
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
VDSGenericException: VDSErrorException: Failed to MergeVDS, error = Merge
failed, code = 52 (Failed with error mergeErr and code 52)
Caused by: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
VDSGenericException: VDSErrorException: Failed to MergeVDS, error = Merge
failed, code = 52
  
  
2020-07-22 16:40:39,659+02 ERROR
[org.ovirt.engine.core.bll.MergeStatusCommand]
(EE-ManagedExecutorService-commandCoordinator-Thread-3)
[264b0047-5aa6-4380-9d32-eb328fd6bed0] Failed to live merge. Top volume
c757e740-9013-4ae0-901d-316932f4af0e is still in qemu chain
[ebe50730-dec3-4f29-8a38-9ae7c59f2aef, c757e740-9013-4ae0-901d-316932f4af0e]
2020-07-22 16:40:41,524+02 ERROR
[org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand]
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-58)
[264b0047-5aa6-4380-9d32-eb328fd6bed0] Command id:
'e0b2bce7-afe0-4955-ae46-38bcb8719852 failed child command status for step
'MERGE_STATUS'
2020-07-22 16:40:42,597+02 ERROR
[org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand]
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-53)
[264b0047-5aa6-4380-9d32-eb328fd6bed0] Merging of snapshot
'ef8f7e06-e48c-4a8c-983c-64e3d4ebfcf9' images
'ebe50730-dec3-4f29-8a38-9ae7c59f2aef'..'c757e740-9013-4ae0-901d-316932f4af0e'
failed. Images have been marked illegal and can no longer be previewed or
reverted to. Please retry Live Merge on the snapshot to complete the
operation.
2020-07-22 16:40:42,603+02 ERROR
[org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand]
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-53)
[264b0047-5aa6-4380-9d32-eb328fd6bed0] Ending command
'org.ovirt.engine.core.bll.snapshots.RemoveSnapshotSingleDiskLiveCommand'
with failure.
2020-07-22 16:40:43,679+02 ERROR
[org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand]
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-15)
[264b0047-5aa6-4380-9d32-eb328fd6bed0] Ending command
'org.ovirt.engine.core.bll.snapshots.RemoveSnapshotCommand' with failure.
2020-07-22 16:40:43,774+02 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-15)
[264b0047-5aa6-4380-9d32-eb328fd6bed0] EVENT_ID:
USER_REMOVE_SNAPSHOT_FINISHED_FAILURE(357), Failed to delete snapshot
'Auto-generated for Export To OVA' for VM 'Adhoc'.


VDSM on hypervisor
2020-07-22 14:14:30,220+0200 ERROR (jsonrpc/5) [virt.vm]
(vmId='14283e6d-c3f0-4011-b90f-a1272f0fbc10') Live merge failed (job:
e59c54d9-b8d3-44d0-9147-9dd40dff57b9) (vm:5381)
if ret == -1: raise libvirtError ('virDomainBlockCommit() failed',
dom=self)
libvirt.libvirtError: internal error: qemu block name 'json:{"backing":
{"driver": "qcow2", "file": {"driver": "file", "filename":
"/rhev/data-center/mnt/10.12.0.9:_exports_data/9a12f1b2-5378-46cc-964d-3575695e823f/images/3206de41-ccdc-4f2d-a968-5e4da6c2ca3e/bb3aed4b-fc41-456a-9c18-1409a9aa6d14"}},
"driver": "qcow2", "file": {"driver": "file", "filename":
"/rhev/data-center/mnt/10.12.0.9:_exports_data/9a12f1b2-5378-46cc-964d-3575695e823f/images/3206de41-ccdc-4f2d-a968-5e4da6c2ca3e/3995b256-2afb-4853-9360-33d0c12e5fd1"}}'
doesn't 

[ovirt-users] Re: problem with custom bond options

[Ales Musil]

On Wed, Jul 22, 2020 at 9:41 PM Jiří Sléžka  wrote:

> Hello,
>

Hi,


> CentOS8, oVirt 4.4.1.10-1.el8
>
> I am trying to setup active-backup (mode=1) bonding mode with custom
> properties. I have one 10GE switch, the second is just 1G. 10GE link is
> the primary one.
>
> cat /etc/sysconfig/network-scripts/ifcfg-bond0
>

first of all in oVirt 4.4 the network-scripts are not relevant anymore.
More relevant is output from 'nmstatectl show'.


>
> BONDING_OPTS="active_slave=ens5 downdelay=0 miimon=100
> mode=active-backup primary=ens5 updelay=0"
> TYPE=Bond
> BONDING_MASTER=yes
> PROXY_METHOD=none
> BROWSER_ONLY=no
> IPV4_FAILURE_FATAL=no
> IPV6_DISABLED=yes
> IPV6INIT=no
> NAME=bond0
> UUID=c054364e-47cf-47ee-a7fc-70b37c9977e7
> DEVICE=bond0
> ONBOOT=yes
> MTU=9000
>
> When I try to add a custom parameter "fail_over_mac=active" (which I
> believe could solve my problems with stalled mac addresses in switch's
> cam table in case of failover) I got...
>
> "Error while executing action HostSetupNetworks: Unexpected exception"
>
> ...in manager. In the engine.log it looks like
>
> 2020-07-22 21:20:35,774+02 WARN
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Unexpected
> return value: Status [code=-32603, message=Internal JSON-RPC error:
> {'reason': 'MAC address cannot be specified in bond interface along with
> specified bond options'}]
> 2020-07-22 21:20:35,774+02 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Failed in
> 'HostSetupNetworksVDS' method
> 2020-07-22 21:20:35,774+02 WARN
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand]
> (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] Unexpected
> return value: Status [code=-32603, message=Internal JSON-RPC error:
> {'reason': 'MAC address cannot be specified in bond interface along with
> specified bond options'}]
> 2020-07-22 21:20:35,811+02 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-8) [da1984f3-f38b-4e0a-ac80-a81e67d73ff0] EVENT_ID:
> VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ovirt-hci01.mch.local command
> HostSetupNetworksVDS failed: Internal JSON-RPC error: {'reason': 'MAC
> address cannot be specified in bond interface along with specified bond
> options'}
>
>
Can you please share supervdsm.log from the relevant host?


>
> Could anybody explain me what 'MAC address cannot be specified in bond
> interface along with specified bond options' means? I believe a MAC
> address is not configured in interface configuration.
>
> Or does it mean 'fail_over_mac=active' is not supported in oVirt?
>
> Thanks in advance,
>
> Jiri
>
>
>
>
>
> ___
> 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/BUGNSEBD3OBSUPASLJQYYJIF5767XMDE/
>


Thank you.
Regards,
Ales

-- 

Ales Musil

Software Engineer - RHV Network

Red Hat EMEA 

amu...@redhat.comIM: amusil

___
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/32UM7RWI5WAN2L2OT7D4PZLCBUWVLDQZ/

[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

[Yedidyah Bar David]

On Wed, Jul 22, 2020 at 5:34 PM Florian Schmid via Users
 wrote:
>
> Hi,
>
> after digging a bit deeper, it looks like it is the problem with the 
> qemu-guest-agent.
>
> It does only report the hostname and nothing more. It uses this function: 
> g_get_host_name ()
>
> This function always returns the value in /etc/hostname and this is normally 
> the short name of the VM without the domain part.
>
> It looks like, that the ovirt-guest-agent made this different,

Indeed, and from checking the git log, it seems like it did this since
the very first commit - already then,
ovirt-guest-agent/GuestAgentLinux2.py had:
def getMachineName(self):
return socket.getfqdn()

> but this is not working anymore with python 3.

If in "this" you refer to ovirt-guest-agent, then it's deprecated:

https://bugzilla.redhat.com/show_bug.cgi?id=1672732

>
> There was a recent patch for qga -> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1845127

This bug seems to discuss something else, not directly related to your
own issue.

> but this won't help me, because even when this patch would add the FQDN to 
> oVirt back, there won't be a package for this for Ubuntu 20.04 and probably 
> also not for RedHat/CentOS 8.

Not sure what you mean here. The bug is on qga, and fixing it (or your
own issue) is unrelated to oga's deprecation.

Your issue seems to be, to me:

1. oga used to report the FQDN, as returned by python's socket.getfqdn()
2. qga returns something else (and this something else might be
changed, following above bug, but likely not to what you want).
3. oVirt now uses qga instead of oga, thus changing its past behavior.
4. You want the old behavior back - basically, claiming this is a regression.

If so, then:

1. You are welcome to open a bug about this, on qga.
2. Your request *might* be rejected, on the ground of breaking
compatibility for existing/old users of qga (say, using virt-manager
or whatever other virt tool, without oga installed)

Alternatively, or if this bug is rejected, you can open two new bugs:

1. one on qga, to provide the fqdn (using, hopefully, logic similar to
python's getfqdn, although qga is written in C)
2. other on the oVirt engine, to use this new functionality of qga
instead of the existing one.

You also have another alternative - just adapt your machines to have
the fqdn as the hostname. I personally think this is the best way to
go. Have 'hostname' return the FQDN you want, and only use 'hostname
-s' where you really want it to be short. How do you set the hostnames
of your machines?

Best regards,

>
> BR Florian
>
>
> 
> Von: "users" 
> An: "Sandro Bonazzola" 
> CC: "users" 
> Gesendet: Montag, 20. Juli 2020 09:06:30
> Betreff: [ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN
>
> Hi,
>
> when setting hostnamectl set-hostname "FQDN", then engine will report the 
> real and correct "FQDN", but this is not a good fix.
>
> With our older Debian and Ubuntu VMs, it is working correctly, although 
> hostname is only reporting the short hostname. hostname -f is reporting here 
> the correct FQDN.
>
> BR Florian
>
>
> 
> UBIMET GmbH - weather matters
> Ing. Florian Schmid • IT Infrastruktur Austria
>
> A-1220 Wien • Donau-City-Straße 11 • Tel +43 1 263 11 22 DW 469 • Fax +43 1 
> 263 11 22 219
> fsch...@ubimet.com • www.ubimet.com • Mobile: +43 664 8323379
>
> Sitz: Wien • Firmenbuchgericht: Handelsgericht Wien • FN 248415 t
>
> 
>
>
> The information contained in this message (including any attachments) is 
> confidential and may be legally privileged or otherwise protected from 
> disclosure. This message is intended solely for the addressee(s). If you are 
> not the intended recipient, please notify the sender by return e-mail and 
> delete this message from your system. Any unauthorized use, reproduction, or 
> dissemination of this message is strictly prohibited. Please note that 
> e-mails are susceptible to change. UBIMET GmbH shall not be liable for the 
> improper or incomplete transmission of the information contained in this 
> communication, nor shall it be liable for any delay in its receipt. UBIMET 
> GmbH accepts no liability for loss or damage caused by software viruses and 
> you are advised to carry out a virus check on any attachments contained in 
> this message.
>
>
>
> 
> Von: "Sandro Bonazzola" 
> An: "Florian Schmid" , "Tomas Golembiovsky" 
> 
> CC: "users" 
> Gesendet: Freitag, 17. Juli 2020 09:21:37
> Betreff: Re: [ovirt-users] qemu-guest-agent on Ubuntu doesn't report FQDN
>
>
>
> Il giorno gio 16 lug 2020 alle ore 15:55 Florian Schmid via Users 
>  ha scritto:
>>
>> Hi,
>>
>> I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the