Re: [ovirt-users] Any monitoring tool provided?

[Shirly Radco]

Adding Rich Megginson.

--

SHIRLY RADCO

BI SeNIOR SOFTWARE ENGINEER

Red Hat Israel 

TRIED. TESTED. TRUSTED. 

On Wed, Mar 28, 2018 at 1:10 AM, Nicolas Vaye 
wrote:

> OK, i have removed all libvirt-* packages
>
> i have seen that in the playbook, firewalld will be disable and iptables
> manage the firewall.
>
> I have a problem because my metric server was behind a proxy web and when
> i run
>
> ANSIBLE_LOG_PATH=/tmp/ansible.log ansible-playbook -vvv -e
> @/root/vars.yaml -i /root/ansible-inventory-origin-37-aio
> playbooks/byo/config.yml
>
> i get
>
>
> CHECK [memory_availability : localhost] **
> 
> **
>
> fatal: [localhost]: FAILED! => {
>
> "changed": false,
>
> "checks": {
>
> "disk_availability": {},
>
> "docker_image_availability": {
>
> "failed": true,
>
> "failures": [
>
> [
>
> "OpenShiftCheckException",
>
> "One or more required container images are not
> available:\ncockpit/kubernetes:latest,\n
> openshift/origin-deployer:latest,\n
>   openshift/origin-docker-registry:latest,\n
> openshift/origin-haproxy-router:latest,\n
>   openshift/origin-pod:latest\nChecked with: skopeo inspect
> [--tls-verify=false] [--creds=:] 
> docker:///\nDefault
> registries searched: docker.io\nFailed connecting to: docker.io\n"
>
> ]
>
> ],
>
> "msg": "One or more required container images are not
> available:\ncockpit/kubernetes:latest,\n
> openshift/origin-deployer:latest,\n
>   openshift/origin-docker-registry:latest,\n
> openshift/origin-haproxy-router:latest,\n
>   openshift/origin-pod:latest\nChecked with: skopeo inspect
> [--tls-verify=false] [--creds=:] 
> docker:///\nDefault
> registries searched: docker.io\nFailed connecting to: docker.io\n"
>
> },
>
> "docker_storage": {
>
> "skipped": true,
>
> "skipped_reason": "Disabled by user request"
>
> },
>
> "memory_availability": {},
>
> "package_availability": {
>
> "changed": false,
>
> "invocation": {
>
> "module_args": {
>
> "packages": [
>
> "PyYAML",
>
> "bash-completion",
>
> "bind",
>
> "ceph-common",
>
> "cockpit-bridge",
>
> "cockpit-docker",
>
> "cockpit-system",
>
> "cockpit-ws",
>
> "dnsmasq",
>
> "docker",
>
> "etcd",
>
> "firewalld",
>
> "flannel",
>
> "glusterfs-fuse",
>
> "httpd-tools",
>
> "iptables",
>
> "iptables-services",
>
> "iscsi-initiator-utils",
>
> "libselinux-python",
>
> "nfs-utils",
>
> "ntp",
>
> "openssl",
>
> "origin",
>
> "origin-clients",
>
> "origin-master",
>
> "origin-node",
>
> "origin-sdn-ovs",
>
> "pyparted",
>
> "python-httplib2",
>
> "yum-utils"
>
> ]
>
> }
>
> }
>
> },
>
> "package_version": {
>
> "skipped": true,
>
> "skipped_reason": "Disabled by user request"
>
> }
>
> },
>
> "msg": "One or more checks failed",
>
> "playbook_context": "install"
>
> }
>
>
> NO MORE HOSTS LEFT **
> 
> ***
>
> to retry, use: --limit @/usr/share/ansible/openshift-
> ansible/playbooks/byo/config.retry
>
>
> PLAY RECAP 
> 
> *
>
> localhost  : ok=67   changed=4unreachable=0failed=1
>
>
>
> INSTALLER STATUS **
> 
> *
>
> Initialization : Complete
>
> Health Check   : In Progress
>
> This phase can be restarted by running: playbooks/byo/openshift-
> 

[ovirt-users] oVirt Node Resize tool for local storage

[Matt Simonsen]

Hello,

We have a development box with local storage, running ovirt Node 4.1

It appears that using the admin interface on port 9090 I can resize a 
live partition to a smaller size.


Our storage is a seperate LVM partition, ext4 formated.

My question is, both theoretically and practically, if anyone has 
feedback on:



#1: Does this work (ie- will it shrink the filesystem then shrink the LV)?

#2: May we do this with VMs running?


Thanks

Matt

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Testing oVirt 4.2

[wodel youchi]

Hi and thanks for your replies,

I cleaned up everything and started from scratch.
I using nested-kvm for my test with host-passthrough to expose vmx to the
VM hypervisor, my physical CPU is a Core i5 6500

This time I had another problem, the VM engine won't start because of this
error in vdsm.log
2018-03-27 22:48:31,893+0100 ERROR (vm/c9c0640e) [virt.vm]
(vmId='c9c0640e-d8f1-4ade-95f3-40f2982b1d8c') The vm start process failed
(vm:927)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 856, in
_startUnderlyingVm
self._run()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2756, in
_run
dom.createWithFlags(flags)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py",
line 130, in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92,
in wrapper
return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1069, in
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed',
dom=self)
libvirtError:* internal error: Unknown CPU model SkylakeClient*

The CPU model *SkylakeClient* presented to the VM engine is not recognized.
is there a way to bypass this?

Regards.

2018-03-24 16:25 GMT+01:00 Andrei Verovski :

> On 03/24/2018 01:40 PM, Andy Michielsen wrote:
>
> Hello,
>
> I also have done a installation on my host running KVM and I ‘m pretty
> sure my vm’s can only use the 192.168.122.0/24 range if you install them
> with NAT networking when creating them. So that might explain why you see
> that address appear in your log and also explain why the engine system
> can’t be reached.
>
>
> Can't tell fo sure about other installations, yet IMHO problem is with
> networking schema.
>
> One need to set bridge to real ethernet interface and add it to KVM VM
> definition.
>
> For example, my SuSE box have 2 ethernet cards, 192.168.0.aa for SMB fle
> server and another bridged with IP 192.168.0.bb defined within KVM guest
> (CentOS 7.4 with oVirt host engine). See configs below.
>
> Another SuSE box have 10 Ethernet interfaces, one for for its own needs,
> and 4 + 3 for VyOS routers running as KVM guests.
>
> **
>
> SU47:/etc/sysconfig/network # tail -n 100 ifcfg-br0
> BOOTPROTO='static'
> BRIDGE='yes'
> BRIDGE_FORWARDDELAY='0'
> BRIDGE_PORTS='eth0'
> BRIDGE_STP='off'
> BROADCAST=''
> DHCLIENT_SET_DEFAULT_ROUTE='no'
> ETHTOOL_OPTIONS=''
> IPADDR=''
> MTU=''
> NETWORK=''
> PREFIXLEN='24'
> REMOTE_IPADDR=''
> STARTMODE='auto'
> NAME=''
>
> SU47:/etc/sysconfig/network # tail -n 100 ifcfg-eth0
> BOOTPROTO='none'
> BROADCAST=''
> DHCLIENT_SET_DEFAULT_ROUTE='no'
> ETHTOOL_OPTIONS=''
> IPADDR=''
> MTU=''
> NAME='82579LM Gigabit Network Connection'
> NETMASK=''
> NETWORK=''
> REMOTE_IPADDR=''
> STARTMODE='auto'
> PREFIXLEN=''
>
>
>
>
> Kind regards.
>
> On 24 Mar 2018, at 12:13, wodel youchi  wrote:
>
> Hi,
>
> I am testing oVirt 4.2, I am using nested KVM for that.
> I am using two hypervisors Centos 7 updated and the hosted-Engine
> deployment using the ovirt appliance.
> For storage I am using iscsi and NFS4
>
> Versions I am using :
> ovirt-engine-appliance-4.2-20180214.1.el7.centos.noarch
> ovirt-hosted-engine-setup-2.2.9-1.el7.centos.noarch
> kernel-3.10.0-693.21.1.el7.x86_64
>
> I have a problem deploying the hosted-engine VM, when configuring the
> deployment (hosted-engine --deploy), it asks for the engine's hostname then
> the engine's IP address, I use static IP, in my lab I used *192.168.1.104* as
> IP for the VM engine, and I choose to add the it's hostname entry to the
> hypervisors's /etc/hosts
>
> But the deployment get stuck every time in the same place : *TASK [Wait
> for the host to become non operational]*
>
> After some time, it gave up and the deployment fails.
>
> I don't know the reason for now, but I have seen this behavior in */etc/hosts
> *of the hypervisor.
>
> In the beginning of the deployment the entry  *192.168.2.104
> engine01.example.local* is added, then sometime after that it's deleted,
> then a new entry is added with this IP *192.168.122.65 engine01.wodel.wd* 
> which
> has nothing to do with the network I am using.
>
> Here is the error I am seeing in the deployment log
>
> 2018-03-24 11:51:31,398+0100 INFO 
> otopi.ovirt_hosted_engine_setup.ansible_utils
> ansible_utils._process_output:100 TASK [Wait
> for the host to become non operational]
> 2018-03-24 12:02:07,284+0100 DEBUG 
> otopi.ovirt_hosted_engine_setup.ansible_utils
> ansible_utils._process_output:94 {u'_ansible
> _parsed': True, u'_ansible_no_log': False, u'changed': False, u'attempts':
> 150, u'invocation': {u'module_args': {u'pattern':
> u'name=hyperv01.wodel.wd', u'fetch_nested': False, u'nested_attributes':
> []}}, u'ansible_facts': {u'ovirt_hosts': []}}
> 2018-03-24 12:02:07,385+0100 ERROR 
> 

Re: [ovirt-users] Any monitoring tool provided?

[Nicolas Vaye]

OK, i have removed all libvirt-* packages

i have seen that in the playbook, firewalld will be disable and iptables manage 
the firewall.

I have a problem because my metric server was behind a proxy web and when i run

ANSIBLE_LOG_PATH=/tmp/ansible.log ansible-playbook -vvv -e @/root/vars.yaml -i 
/root/ansible-inventory-origin-37-aio playbooks/byo/config.yml

i get


CHECK [memory_availability : localhost] 


fatal: [localhost]: FAILED! => {

"changed": false,

"checks": {

"disk_availability": {},

"docker_image_availability": {

"failed": true,

"failures": [

[

"OpenShiftCheckException",

"One or more required container images are not available:\n 
   cockpit/kubernetes:latest,\nopenshift/origin-deployer:latest,\n
openshift/origin-docker-registry:latest,\n
openshift/origin-haproxy-router:latest,\n
openshift/origin-pod:latest\nChecked with: skopeo inspect [--tls-verify=false] 
[--creds=:] docker:///\nDefault registries 
searched: docker.io\nFailed connecting to: docker.io\n"

]

],

"msg": "One or more required container images are not available:\n  
  cockpit/kubernetes:latest,\nopenshift/origin-deployer:latest,\n
openshift/origin-docker-registry:latest,\n
openshift/origin-haproxy-router:latest,\n
openshift/origin-pod:latest\nChecked with: skopeo inspect [--tls-verify=false] 
[--creds=:] docker:///\nDefault registries 
searched: docker.io\nFailed connecting to: docker.io\n"

},

"docker_storage": {

"skipped": true,

"skipped_reason": "Disabled by user request"

},

"memory_availability": {},

"package_availability": {

"changed": false,

"invocation": {

"module_args": {

"packages": [

"PyYAML",

"bash-completion",

"bind",

"ceph-common",

"cockpit-bridge",

"cockpit-docker",

"cockpit-system",

"cockpit-ws",

"dnsmasq",

"docker",

"etcd",

"firewalld",

"flannel",

"glusterfs-fuse",

"httpd-tools",

"iptables",

"iptables-services",

"iscsi-initiator-utils",

"libselinux-python",

"nfs-utils",

"ntp",

"openssl",

"origin",

"origin-clients",

"origin-master",

"origin-node",

"origin-sdn-ovs",

"pyparted",

"python-httplib2",

"yum-utils"

]

}

}

},

"package_version": {

"skipped": true,

"skipped_reason": "Disabled by user request"

}

},

"msg": "One or more checks failed",

"playbook_context": "install"

}


NO MORE HOSTS LEFT 
*

to retry, use: --limit 
@/usr/share/ansible/openshift-ansible/playbooks/byo/config.retry


PLAY RECAP 
*

localhost  : ok=67   changed=4unreachable=0failed=1



INSTALLER STATUS 
***

Initialization : Complete

Health Check   : In Progress

This phase can be restarted by running: 
playbooks/byo/openshift-checks/pre-install.yml




Failure summary:



  1. Hosts:localhost

 Play: OpenShift Health Checks

 Task: Run health checks (install) - EL

 Message:  One or more checks failed

 Details:  check "docker_image_availability":

   One or more required container images are not available:

   cockpit/kubernetes:latest,

   openshift/origin-deployer:latest,

   openshift/origin-docker-registry:latest,

   openshift/origin-haproxy-router:latest,

   

[ovirt-users] Recovering oVirt-Engine with a backup before upgrading to 4.2

[Sven Achtelik]

Hi All,

I'm still facing issues with my HE engine. Here are the steps that I took to 
end up in this situation:


- Update Engine from 4.1.7 to 4.1.9

o   That worked as expected

- Automatic Backup of Engine DB in the night

- Upgraded Engine from 4.1.9 to 4.2.1

o   That worked fine

- Noticed Issues with the HA support for HE

o   Cause was not having the latest ovirt-ha agent/broker version on hosts

- After updating the first host with the latest packages for the 
Agent/Broker engine was started twice

o   As a result the Engine VM Disk was corrupted and there is no Backup of the 
Disk

o   There is also no Backup of the Engine DB with version 4.2

- VM disk was repaired with fsck.ext4, but DB is corrupt

o   Can't restore the Engine DB because the Backup DB from Engine V 4.1

- Rolled back all changes on Engine VM to 4.1.9 and imported Backup

o   Checked for HA VMs to set as disabled and started the Engine

- Login is fine but the Engine is having trouble picking up and 
information from the Hosts

o   No information on running VMs or hosts status

- Final Situation

o   2 Hosts have VMs still running and I can't stop those

o   I still have the image of my corrupted Engine VM (v4.2)

Since there were no major changes after upgrading from 4.1 to 4.2, would it be 
possible to manually restore the 4.1 DB to the 4.2 Engine VM to this up and 
running again or are there modifications made to the DB on upgrading that are 
relevant for this ? All my work on rolling back to 4.1.9 with the DB restore 
failed as the Engine is not capable of picking up information from the hosts. 
Lessons learned is to always make a copy/snapshot of the engine VM disk before 
upgrading anything. What are my options on getting back to a working 
environment ? Any help or hint is greatly appreciated.

Thank you,
Sven
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] overt-guest-agent Failure on latest Debian 9 Sretch

[Sandro Bonazzola]

Il mar 27 mar 2018, 18:40 Michal Skrivanek  ha
scritto:

>
>
> On 27 Mar 2018, at 09:20, Sandro Bonazzola  wrote:
>
> Tomas, anything we can do here?
>
>
> More people complaining the better chance it gets fixed, but that should
> happen within Debian community.
> Package updates are coming from debian package maintainer
>


Nicolas, can you please open a ticket on Debian and post here the link?





>
> Il lun 26 mar 2018, 22:18 Nicolas Vaye  ha
> scritto:
>
>> Hello Andrei,
>>
>> i have had the same problem and on Debian stretch the problem is the old
>> version of agent from stretch repository.
>>
>> I downloaded 1.0.13 from Debian testing repo as *.deb file.
>>
>> With these new versions of guest-agent then is also a udev rules issue.
>>
>> The serial channels have been renamed and the rules didn`t match for
>> ovirt.
>>
>> See the install script, as attachement (provided by > oliver%20riesener%20%3coliver.riese...@hs-bremen.de%3e>
>> oliver.riese...@hs-bremen.de).
>>
>> May be it can help you.
>>
>> Regards,
>>
>> Nicolas Vaye
>>
>>  Message initial 
>>
>> Date: Mon, 26 Mar 2018 17:29:16 +0300
>> Objet: [ovirt-users] overt-guest-agent Failure on latest Debian 9 Sretch
>> À: users@ovirt.org
>> De: Andrei Verovski  andrei%20verovski%20%3candre...@starlett.lv%3e>>
>>
>> Hi,
>>
>> I just installed latest Debian 9 Sretch under oVirt 4.2 and got this
>> error:
>>
>> # tail -n 1000 ovirt-guest-agent.log
>> MainThread::INFO::2018-03-26
>> 17:09:57,400::ovirt-guest-agent::59::root::Starting oVirt guest agent
>> MainThread::ERROR::2018-03-26
>> 17:09:57,402::ovirt-guest-agent::141::root::Unhandled exception in oVirt
>> guest agent!
>> Traceback (most recent call last):
>>   File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 135, in
>> 
>> agent.run(daemon, pidfile)
>>   File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 65, in
>> run
>> self.agent = LinuxVdsAgent(config)
>>   File "/usr/share/ovirt-guest-agent/GuestAgentLinux2.py", line 472, in
>> __init__
>> AgentLogicBase.__init__(self, config)
>>   File "/usr/share/ovirt-guest-agent/OVirtAgentLogic.py", line 188, in
>> __init__
>> self.vio = VirtIoChannel(config.get("virtio", "device"))
>>   File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 153, in
>> __init__
>> self._stream = VirtIoStream(vport_name)
>>   File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 134, in
>> __init__
>> self._vport = os.open(vport_name, os.O_RDWR)
>> OSError: [Errno 2] No such file or directory:
>> '/dev/virtio-ports/com.redhat.rhevm.vdsm’
>>
>> Followed this manual:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1472293
>> and run
>> touch /etc/udev/rules.d/55-ovirt-guest-agent.rules
>> # edit  /etc/udev/rules.d/55-ovirt-guest-agent.rules
>> SYMLINK=="virtio-ports/ovirt-guest-agent.0", OWNER="ovirtagent",
>> GROUP="ovirtagent"
>> udevadm trigger --subsystem-match="virtio-ports”
>>
>> AND this
>>
>> http://lists.ovirt.org/pipermail/users/2018-January/086101.html
>> touch /etc/ovirt-guest-agent/ovirt-guest-agent.conf# <— it didn't
>> existed so I created it.
>> # edit /etc/ovirt-guest-agent.conf
>> [virtio]
>> device = /dev/virtio-ports/ovirt-guest-agent.0
>>
>> reboot
>>
>> Yet still have same problem and error message.
>> How to solve it ?
>>
>> Thanks in advance
>> Andrei
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] vdi over wan optimation

[Christopher Cox]

On 03/27/2018 10:10 AM, Andreas Huser wrote:

Hi, i have a question about vdi over wan. The traffic is very high when i look 
videos or online streams. 100% of my capacity of Internet Bandwidth is used.

Does anyone an idea how can i optimise spice for wan?


You can always look into QoS, but might have to apply that uniformly to 
the guest spice traffic (likely).  And by QoS, that likely means 
something you do outside of oVirt (Internet vs Intranet).


Of course, applying QoS for "video" may make things horrible.  Pumping 
large amounts of "live" important synchronized data costs a lot, it's 
the nature of the beast.  Restrict it and you often end up with less 
than usable audio/video, especially if the data is unknown (e.g. a full 
remote desktop).


Ideally, from a thin client perspective, the solution is to run as much 
of that as possible outside of the remote desktop.


There's a reason why those very setup specific options exist out there 
for handling these types of VDI things (transparently).  They are very 
restricted and of course have a slew of dependencies and usually a lot 
of cost. (and IMHO, often times go "belly up" within 5 years)


I've seen some of these.  Basically the thin client uses remote desktop, 
but when an embedded video happens, that is offloaded as a direct 
connection handled by the thin client (kind of like "casting" in today's 
world).


I these VDI quests are Windows, RDP is likely going to do better than 
Spice, especially for remote audio and video.  Doesn't mean it won't 
occupy all your bandwidth, just saying it performs better.   With that 
said, remote desktop via other means, be that RDP, or NX, etc.. might be 
"better" than Spice.


PSA: If these are Windows, be aware of Microsoft's VDI tax (the VDA). 
This is an arbitrary invented tax that Microsoft created strictly to get 
people to only user their hypervisor platform.  It can cost a lot and 
it's required annually.


In the past I used NX for my Linux "desktops".  This worked well even 
over very low bandwidth connects, however, it assumed my business was 
not the source of network bottlenecks on the Internet.  Just saying. 
Even so, things that did massive amount of work, be that large AV or 
IntelliJ (which does a gazillion window creates/destroys) were still 
some concern.  We tweaked our IntelliJ profiles to help reduce the load 
there.  Not a whole lot we could do with regards to audio/video but 
educate people.


And no, I do not recommend 10 users playing PUBG via VDI. :-)

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] overt-guest-agent Failure on latest Debian 9 Sretch

[Michal Skrivanek]

> On 27 Mar 2018, at 09:20, Sandro Bonazzola  wrote:
> 
> Tomas, anything we can do here? 

More people complaining the better chance it gets fixed, but that should happen 
within Debian community.
Package updates are coming from debian package maintainer

> 
> Il lun 26 mar 2018, 22:18 Nicolas Vaye  > ha scritto:
> Hello Andrei,
> 
> i have had the same problem and on Debian stretch the problem is the old 
> version of agent from stretch repository.
> 
> I downloaded 1.0.13 from Debian testing repo as *.deb file.
> 
> With these new versions of guest-agent then is also a udev rules issue.
> 
> The serial channels have been renamed and the rules didn`t match for ovirt.
> 
> See the install script, as attachement (provided by 
>  %3e> 
> oliver.riese...@hs-bremen.de 
>  >).
> 
> May be it can help you.
> 
> Regards,
> 
> Nicolas Vaye
> 
>  Message initial 
> 
> Date: Mon, 26 Mar 2018 17:29:16 +0300
> Objet: [ovirt-users] overt-guest-agent Failure on latest Debian 9 Sretch
> À: users@ovirt.org  >
> De: Andrei Verovski    %3e>>
> 
> Hi,
> 
> I just installed latest Debian 9 Sretch under oVirt 4.2 and got this error:
> 
> # tail -n 1000 ovirt-guest-agent.log
> MainThread::INFO::2018-03-26 
> 17:09:57,400::ovirt-guest-agent::59::root::Starting oVirt guest agent
> MainThread::ERROR::2018-03-26 
> 17:09:57,402::ovirt-guest-agent::141::root::Unhandled exception in oVirt 
> guest agent!
> Traceback (most recent call last):
>   File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 135, in 
> 
> agent.run(daemon, pidfile)
>   File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 65, in run
> self.agent = LinuxVdsAgent(config)
>   File "/usr/share/ovirt-guest-agent/GuestAgentLinux2.py", line 472, in 
> __init__
> AgentLogicBase.__init__(self, config)
>   File "/usr/share/ovirt-guest-agent/OVirtAgentLogic.py", line 188, in 
> __init__
> self.vio = VirtIoChannel(config.get("virtio", "device"))
>   File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 153, in __init__
> self._stream = VirtIoStream(vport_name)
>   File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 134, in __init__
> self._vport = os.open(vport_name, os.O_RDWR)
> OSError: [Errno 2] No such file or directory: 
> '/dev/virtio-ports/com.redhat.rhevm.vdsm’
> 
> Followed this manual:
> https://bugzilla.redhat.com/show_bug.cgi?id=1472293 
> 
> and run
> touch /etc/udev/rules.d/55-ovirt-guest-agent.rules
> # edit  /etc/udev/rules.d/55-ovirt-guest-agent.rules
> SYMLINK=="virtio-ports/ovirt-guest-agent.0", OWNER="ovirtagent", 
> GROUP="ovirtagent"
> udevadm trigger --subsystem-match="virtio-ports”
> 
> AND this
> 
> http://lists.ovirt.org/pipermail/users/2018-January/086101.html 
> 
> touch /etc/ovirt-guest-agent/ovirt-guest-agent.conf# <— it didn't existed 
> so I created it.
> # edit /etc/ovirt-guest-agent.conf
> [virtio]
> device = /dev/virtio-ports/ovirt-guest-agent.0
> 
> reboot
> 
> Yet still have same problem and error message.
> How to solve it ?
> 
> Thanks in advance
> Andrei
> 
> ___
> Users mailing list
> Users@ovirt.org  >
> http://lists.ovirt.org/mailman/listinfo/users 
> 
> 
> ___
> Users mailing list
> Users@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/users 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] vdi over wan optimation

[Andreas Huser]

Hi, i have a question about vdi over wan. The traffic is very high when i look 
videos or online streams. 100% of my capacity of Internet Bandwidth is used.  

Does anyone an idea how can i optimise spice for wan?


Thanks a lot 
Andreas


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Snapshot of the Self-Hosted Engine

[FERNANDO FREDIANI]

Hello

Is it possible to snapshot the Self-Hosted Engine before an Upgrade ? If so
how ?

Thanks
Fernando
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] ovirt snapshot issue

[Sandro Bonazzola]

2018-03-27 14:34 GMT+02:00 Alex K :

> Hi All,
>
> Any idea on the below?
>
> I am using oVirt Guest Tools 4.2-1.el7.centos for the VM.
> The Window 2016 server VM (which it the one with the relatively big disks:
> 500 GB) it is consistently rendered unresponsive when trying to get a
> snapshot.
> I amy provide any other additional logs if needed.
>

Adding some people to the thread



>
> Alex
>
> On Sun, Mar 25, 2018 at 7:30 PM, Alex K  wrote:
>
>> Hi folks,
>>
>> I am facing frequently the following issue:
>>
>> On some large VMs (Windows 2016 with two disk drives, 60GB and 500GB)
>> when attempting to create a snapshot of the VM, the VM becomes
>> unresponsive.
>>
>> The errors that I managed to collect were:
>>
>> vdsm error at host hosting the VM:
>> 2018-03-25 14:40:13,442+ WARN  (vdsm.Scheduler) [Executor] Worker
>> blocked: > {u'frozen': False, u'vmID': u'a5c761a2-41cd-40c2-b65f-f3819293e8a4',
>> u'snapDrives': [{u'baseVolumeID': u'2a33e585-ece8-4f4d-b45d-5ecc9239200e',
>> u'domainID': u'888e3aae-f49f-42f7-a7fa-76700befabea', u'volumeID':
>> u'e9a01ebd-83dd-40c3-8c83-5302b0d15e04', u'imageID':
>> u'c75b8e93-3067-4472-bf24-dafada224e4d'}, {u'baseVolumeID':
>> u'3fb2278c-1b0d-4677-a529-99084e4b08af', u'domainID':
>> u'888e3aae-f49f-42f7-a7fa-76700befabea', u'volumeID':
>> u'78e6b6b1-2406-4393-8d92-831a6d4f1337', u'imageID':
>> u'd4223744-bf5d-427b-bec2-f14b9bc2ef81'}]}, 'jsonrpc': '2.0', 'method':
>> u'VM.snapshot', 'id': u'89555c87-9701-4260-9952-789965261e65'} at
>> 0x7fca4004cc90> timeout=60, duration=60 at 0x39d8210> task#=155842 at
>> 0x2240e10> (executor:351)
>> 2018-03-25 14:40:15,261+ INFO  (jsonrpc/3) [jsonrpc.JsonRpcServer]
>> RPC call VM.getStats failed (error 1) in 0.01 seconds (__init__:539)
>> 2018-03-25 14:40:17,471+ WARN  (jsonrpc/5) [virt.vm]
>> (vmId='a5c761a2-41cd-40c2-b65f-f3819293e8a4') monitor became
>> unresponsive (command timeout, age=67.910001) (vm:5132)
>>
>> engine.log:
>> 2018-03-25 14:40:19,875Z WARN  [org.ovirt.engine.core.dal.dbb
>> roker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler2)
>> [1d737df7] EVENT_ID: VM_NOT_RESPONDING(126), Correlation ID: null, Call
>> Stack: null, Custom ID: null, Custom Event ID: -1, Message: VM Data-Server
>> is not responding.
>>
>> 2018-03-25 14:42:13,708Z ERROR [org.ovirt.engine.core.dal.dbb
>> roker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler5)
>> [17789048-009a-454b-b8ad-2c72c7cd37aa] EVENT_ID:
>> VDS_BROKER_COMMAND_FAILURE(10,802), Correlation ID: null, Call Stack:
>> null, Custom ID: null, Custom Event ID: -1, Message: VDSM v1.cluster
>> command SnapshotVDS failed: Message timeout which can be caused by
>> communication issues
>> 2018-03-25 14:42:13,708Z ERROR [org.ovirt.engine.core.vdsbrok
>> er.vdsbroker.SnapshotVDSCommand] (DefaultQuartzScheduler5)
>> [17789048-009a-454b-b8ad-2c72c7cd37aa] Command
>> 'SnapshotVDSCommand(HostName = v1.cluster, 
>> SnapshotVDSCommandParameters:{runAsync='true',
>> hostId='a713d988-ee03-4ff0-a0cd-dc4cde1507f4',
>> vmId='a5c761a2-41cd-40c2-b65f-f3819293e8a4'})' execution failed:
>> VDSGenericException: VDSNetworkException: Message timeout which can be
>> caused by communication issues
>> 2018-03-25 14:42:13,708Z WARN  [org.ovirt.engine.core.bll.sna
>> pshots.CreateAllSnapshotsFromVmCommand] (DefaultQuartzScheduler5)
>> [17789048-009a-454b-b8ad-2c72c7cd37aa] Could not perform live snapshot
>> due to error, VM will still be configured to the new created snapshot:
>> EngineException: org.ovirt.engine.core.vdsbroke
>> r.vdsbroker.VDSNetworkException: VDSGenericException:
>> VDSNetworkException: Message timeout which can be caused by communication
>> issues (Failed with error VDS_NETWORK_ERROR and code 5022)
>> 2018-03-25 14:42:13,708Z WARN  [org.ovirt.engine.core.vdsbroker.VdsManager]
>> (org.ovirt.thread.pool-6-thread-15) [17789048-009a-454b-b8ad-2c72c7cd37aa]
>> Host 'v1.cluster' is not responding. It will stay in Connecting state for a
>> grace period of 61 seconds and after that an attempt to fence the host will
>> be issued.
>> 2018-03-25 14:42:13,725Z WARN  [org.ovirt.engine.core.dal.dbb
>> roker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-15)
>> [17789048-009a-454b-b8ad-2c72c7cd37aa] EVENT_ID:
>> VDS_HOST_NOT_RESPONDING_CONNECTING(9,008), Correlation ID: null, Call
>> Stack: null, Custom ID: null, Custom Event ID: -1, Message: Host v1.cluster
>> is not responding. It will stay in Connecting state for a grace period of
>> 61 seconds and after that an attempt to fence the host will be issued.
>> 2018-03-25 14:42:13,751Z WARN  [org.ovirt.engine.core.dal.dbb
>> roker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler5)
>> [17789048-009a-454b-b8ad-2c72c7cd37aa] EVENT_ID:
>> USER_CREATE_LIVE_SNAPSHOT_FINISHED_FAILURE(170), Correlation ID:
>> 17789048-009a-454b-b8ad-2c72c7cd37aa, Job ID:
>> 16e48c28-a8c7-4841-bd81-1f2d370f345d, Call Stack:
>> 

Re: [ovirt-users] ovirt snapshot issue

[Alex K]

Hi All,

Any idea on the below?

I am using oVirt Guest Tools 4.2-1.el7.centos for the VM.
The Window 2016 server VM (which it the one with the relatively big disks:
500 GB) it is consistently rendered unresponsive when trying to get a
snapshot.
I amy provide any other additional logs if needed.

Alex

On Sun, Mar 25, 2018 at 7:30 PM, Alex K  wrote:

> Hi folks,
>
> I am facing frequently the following issue:
>
> On some large VMs (Windows 2016 with two disk drives, 60GB and 500GB) when
> attempting to create a snapshot of the VM, the VM becomes unresponsive.
>
> The errors that I managed to collect were:
>
> vdsm error at host hosting the VM:
> 2018-03-25 14:40:13,442+ WARN  (vdsm.Scheduler) [Executor] Worker
> blocked:  {u'frozen': False, u'vmID': u'a5c761a2-41cd-40c2-b65f-f3819293e8a4',
> u'snapDrives': [{u'baseVolumeID': u'2a33e585-ece8-4f4d-b45d-5ecc9239200e',
> u'domainID': u'888e3aae-f49f-42f7-a7fa-76700befabea', u'volumeID':
> u'e9a01ebd-83dd-40c3-8c83-5302b0d15e04', u'imageID':
> u'c75b8e93-3067-4472-bf24-dafada224e4d'}, {u'baseVolumeID':
> u'3fb2278c-1b0d-4677-a529-99084e4b08af', u'domainID':
> u'888e3aae-f49f-42f7-a7fa-76700befabea', u'volumeID':
> u'78e6b6b1-2406-4393-8d92-831a6d4f1337', u'imageID':
> u'd4223744-bf5d-427b-bec2-f14b9bc2ef81'}]}, 'jsonrpc': '2.0', 'method':
> u'VM.snapshot', 'id': u'89555c87-9701-4260-9952-789965261e65'} at
> 0x7fca4004cc90> timeout=60, duration=60 at 0x39d8210> task#=155842 at
> 0x2240e10> (executor:351)
> 2018-03-25 14:40:15,261+ INFO  (jsonrpc/3) [jsonrpc.JsonRpcServer] RPC
> call VM.getStats failed (error 1) in 0.01 seconds (__init__:539)
> 2018-03-25 14:40:17,471+ WARN  (jsonrpc/5) [virt.vm]
> (vmId='a5c761a2-41cd-40c2-b65f-f3819293e8a4') monitor became unresponsive
> (command timeout, age=67.910001) (vm:5132)
>
> engine.log:
> 2018-03-25 14:40:19,875Z WARN  [org.ovirt.engine.core.dal.
> dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler2)
> [1d737df7] EVENT_ID: VM_NOT_RESPONDING(126), Correlation ID: null, Call
> Stack: null, Custom ID: null, Custom Event ID: -1, Message: VM Data-Server
> is not responding.
>
> 2018-03-25 14:42:13,708Z ERROR [org.ovirt.engine.core.dal.
> dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler5)
> [17789048-009a-454b-b8ad-2c72c7cd37aa] EVENT_ID:
> VDS_BROKER_COMMAND_FAILURE(10,802), Correlation ID: null, Call Stack:
> null, Custom ID: null, Custom Event ID: -1, Message: VDSM v1.cluster
> command SnapshotVDS failed: Message timeout which can be caused by
> communication issues
> 2018-03-25 14:42:13,708Z ERROR 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.SnapshotVDSCommand]
> (DefaultQuartzScheduler5) [17789048-009a-454b-b8ad-2c72c7cd37aa] Command
> 'SnapshotVDSCommand(HostName = v1.cluster, 
> SnapshotVDSCommandParameters:{runAsync='true',
> hostId='a713d988-ee03-4ff0-a0cd-dc4cde1507f4',
> vmId='a5c761a2-41cd-40c2-b65f-f3819293e8a4'})' execution failed:
> VDSGenericException: VDSNetworkException: Message timeout which can be
> caused by communication issues
> 2018-03-25 14:42:13,708Z WARN  [org.ovirt.engine.core.bll.snapshots.
> CreateAllSnapshotsFromVmCommand] (DefaultQuartzScheduler5)
> [17789048-009a-454b-b8ad-2c72c7cd37aa] Could not perform live snapshot
> due to error, VM will still be configured to the new created snapshot:
> EngineException: 
> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
> VDSGenericException: VDSNetworkException: Message timeout which can be
> caused by communication issues (Failed with error VDS_NETWORK_ERROR and
> code 5022)
> 2018-03-25 14:42:13,708Z WARN  [org.ovirt.engine.core.vdsbroker.VdsManager]
> (org.ovirt.thread.pool-6-thread-15) [17789048-009a-454b-b8ad-2c72c7cd37aa]
> Host 'v1.cluster' is not responding. It will stay in Connecting state for a
> grace period of 61 seconds and after that an attempt to fence the host will
> be issued.
> 2018-03-25 14:42:13,725Z WARN  [org.ovirt.engine.core.dal.
> dbbroker.auditloghandling.AuditLogDirector] 
> (org.ovirt.thread.pool-6-thread-15)
> [17789048-009a-454b-b8ad-2c72c7cd37aa] EVENT_ID: 
> VDS_HOST_NOT_RESPONDING_CONNECTING(9,008),
> Correlation ID: null, Call Stack: null, Custom ID: null, Custom Event ID:
> -1, Message: Host v1.cluster is not responding. It will stay in Connecting
> state for a grace period of 61 seconds and after that an attempt to fence
> the host will be issued.
> 2018-03-25 14:42:13,751Z WARN  [org.ovirt.engine.core.dal.
> dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler5)
> [17789048-009a-454b-b8ad-2c72c7cd37aa] EVENT_ID:
> USER_CREATE_LIVE_SNAPSHOT_FINISHED_FAILURE(170), Correlation ID:
> 17789048-009a-454b-b8ad-2c72c7cd37aa, Job ID: 
> 16e48c28-a8c7-4841-bd81-1f2d370f345d,
> Call Stack: org.ovirt.engine.core.common.errors.EngineException:
> EngineException: 
> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
> VDSGenericException: VDSNetworkException: Message timeout which can be
> caused by 

[ovirt-users] Host non-responsive after engine failure

[spfma . tech]

Hi,

I had an electrical failure on the server hosting the engine.
After the reboot it was able to gain access to it again, log into the GUI, but 
the currently online node is not leaving "not responsive" status.
Of course, the network storage paths are still mounted, the VMs are running, 
but I can't gain control again.

In vdsmd.log, I have a lot of messages like this one :
2018-03-27 12:03:11,281+0200 INFO (vmrecovery) [vds] recovery: waiting for 
storage pool to go up (clientIF:674)
2018-03-27 12:03:16,286+0200 INFO (vmrecovery) [vdsm.api] START 
getConnectedStoragePoolsList(options=None) from=internal, 
task_id=b90f550e-ee68-4a91-a7c6-3b60f11c3978 (api:46)
2018-03-27 12:03:16,286+0200 INFO (vmrecovery) [vdsm.api] FINISH 
getConnectedStoragePoolsList return={'poollist': []} from=internal, 
task_id=b90f550e-ee68-4a91-a7c6-3b60f11c3978 (api:52)
2018-03-27 12:03:16,287+0200 INFO (vmrecovery) [vds] recovery: waiting for 
storage pool to go up (clientIF:674)
2018-03-27 12:03:18,413+0200 INFO (periodic/3) [vdsm.api] START 
repoStats(domains=()) from=internal, 
task_id=067714b4-8172-4eec-92bb-6ac16586a657 (api:46)
2018-03-27 12:03:18,413+0200 INFO (periodic/3) [vdsm.api] FINISH repoStats 
return={} from=internal, task_id=067714b4-8172-4eec-92bb-6ac16586a657 (api:52)
2018-03-27 12:03:18,413+0200 INFO (periodic/3) [vdsm.api] START 
multipath_health() from=internal, task_id=e97421fb-5d5a-4291-9231-94bc1961cc49 
(api:46)
2018-03-27 12:03:18,413+0200 INFO (periodic/3) [vdsm.api] FINISH 
multipath_health return={} from=internal, 
task_id=e97421fb-5d5a-4291-9231-94bc1961cc49 (api:52)
2018-03-27 12:03:20,458+0200 INFO (jsonrpc/6) [api.host] START getAllVmStats() 
from=::1,57576 (api:46)
2018-03-27 12:03:20,462+0200 INFO (jsonrpc/6) [api.host] FINISH getAllVmStats 
return={'status': {'message': 'Done', 'code': 0}, 'statsList': (suppressed)} 
from=::1,57576 (api:52)
2018-03-27 12:03:20,464+0200 INFO (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC call 
Host.getAllVmStats succeeded in 0.01 seconds (__init__:573)
2018-03-27 12:03:20,474+0200 INFO (jsonrpc/7) [api.host] START 
getAllVmIoTunePolicies() from=::1,57576 (api:46)
2018-03-27 12:03:20,475+0200 INFO (jsonrpc/7) [api.host] FINISH 
getAllVmIoTunePolicies return={'status': {'message': 'Done', 'code': 0}, 
'io_tune_policies_dict': {'c33a30ba-7fe8-4ff4-aeac-80cb396b9670': {'policy': 
[], 'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 
'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 
'total_bytes_sec': 0L}, 'path': 
'/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/593f6f61-cb7f-4c53-b6e7-617964c222e9/329b2e8b-6cf9-4b39-9190-14a32697ce44',
 'name': 'sda'}]}, 'e8a90739-7737-413e-8edc-a373192f4476': {'policy': [], 
'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 
'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 
'total_bytes_sec': 0L}, 'path': 
'/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/97e078f7-69c6-46c2-b620-26474cd65929/bbb4a1fb-5594-4750-be71-c6b55dca3257',
 'name': 'vda'}]}, '3aec5ce4-691f-487c-a916-aa7f7a664d8c': {'policy': [], 
'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 
'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 
'total_bytes_sec': 0L}, 'path': 
'/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/46a65a1b-d00a-452d-ab9b-70862bb5c053/a4d2ad44-5577-4412-9a8c-819d1f12647a',
 'name': 'sda'}, {'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 
'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 
'total_bytes_sec': 0L}, 'path': 
'/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/0c3a13ce-8f7a-4034-a8cc-12f795b8aa17/c48e0e37-e54b-4ca3-b3ed-b66ead9fad44',
 'name': 'sdb'}]}, '5de1de8f-ac01-459f-b4b8-6d1ed05c8ca3': {'policy': [], 
'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 
'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 
'total_bytes_sec': 0L}, 'path': 
'/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/320ac81c-7db7-4ec0-a271-755e91442b6a/8bfc95c5-318c-43dd-817f-6c7a8a7a5b43',
 'name': 'sda'}, {'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 
'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 
'total_bytes_sec': 0L}, 'path': 
'/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/e7ad86bb-3c63-466b-82cf-687164c46f7b/613ea0ce-ed14-4185-b3fd-36490441f889',
 'name': 'sdb'}]}, '5d548a09-a397-4aac-8b1f-39002e014f5f': {'policy': [], 
'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 
'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 
'total_bytes_sec': 0L}, 'path': 

Re: [ovirt-users] Workflow after restoring engine from backup

[Sven Achtelik]

I did look at this, for the VMs in question there are no entries on the 
run_on_vds and migrating_to_vds fields. I'm thinking of giving this a try. 

-Ursprüngliche Nachricht-
Von: Yedidyah Bar David [mailto:d...@redhat.com] 
Gesendet: Sonntag, 25. März 2018 07:46
An: Sven Achtelik
Cc: users@ovirt.org
Betreff: Re: [ovirt-users] Workflow after restoring engine from backup

On Fri, Mar 23, 2018 at 10:35 AM, Sven Achtelik  wrote:
> It looks like I can't get a chance to shut down the HA VMs. I check the 
> restore log and it did mention that it change the HA-VM entries. Just to make 
> sure I looked at the DB and for the vms in question it looks like this.
>
> engine=# select vm_guid,status,vm_host,exit_status,exit_reason from 
> vm_dynamic Where vm_guid IN (SELECT vm_guid FROM vm_static WHERE 
> auto_startup='t' AND lease_sd_id is NULL);
>vm_guid| status | vm_host | 
> exit_status | exit_reason
> --++-+-+-
>  8733d4a6-0844--804f-6b919e93e076 |  0 | D  |   2 
> |  -1
>  4eeaa622-17f9--b99a-cddb3ad942de |  0 | APP|   2 
> |  -1
>  fbbdc0a0-23a4-4d32--a35c59eb790d |  0 | DB0 |   2 |  
> -1
>  45a4e7ce-19a9-4db9-x-66bd1b9d83af |  0 | xWOR |   2 |
>   -1
> (4 rows)
>
> Should that be enough to have a safe start of the engine without any HA 
> action kicking in. ?

Looks ok, but check also run_on_vds and migrating_to_vds. See also bz 1446055.

Best regards,

>
>
> -Ursprüngliche Nachricht-
> Von: Yedidyah Bar David [mailto:d...@redhat.com]
> Gesendet: Montag, 19. März 2018 10:18
> An: Sven Achtelik
> Cc: users@ovirt.org
> Betreff: Re: [ovirt-users] Workflow after restoring engine from backup
>
> On Mon, Mar 19, 2018 at 11:03 AM, Sven Achtelik  
> wrote:
>> Hi Didi,
>>
>> my backups where taken with the end. Backup utility. I have 3 Data 
>> centers, two of them with just one host and the third one with 3 
>> hosts running the engine.  The backup three days old, was taken on 
>> engine version 4.1 (4.1.7) and the restored engine is running on 4.1.9.
>
> Since the bug I mentioned was fixed in 4.1.3, you should be covered.
>
>> I have three HA VMs that would
>> be affected. All others are just normal vms. Sounds like it would be 
>> the safest to shut down the HA vm S to make sure that nothing happens ?
>
> If you can have downtime, I agree it sounds safer to shutdown the VMs.
>
>> Or can I
>> disable the HA action in the DB for now ?
>
> No need to. If you restored with 4.1.9 engine-backup, it should have done 
> this for you. If you still have the restore log, you can verify this by 
> checking it. It should contain 'Resetting HA VM status', and then the result 
> of the sql that it ran.
>
> Best regards,
>
>>
>> Thank you,
>>
>> Sven
>>
>>
>>
>> Von meinem Samsung Galaxy Smartphone gesendet.
>>
>>
>>  Ursprüngliche Nachricht 
>> Von: Yedidyah Bar David 
>> Datum: 19.03.18 07:33 (GMT+01:00)
>> An: Sven Achtelik 
>> Cc: users@ovirt.org
>> Betreff: Re: [ovirt-users] Workflow after restoring engine from 
>> backup
>>
>> On Sun, Mar 18, 2018 at 11:45 PM, Sven Achtelik 
>> 
>> wrote:
>>> Hi All,
>>>
>>>
>>>
>>> I had issue with the storage that hosted my engine vm. The disk got 
>>> corrupted and I needed to restore the engine from a backup.
>>
>> How did you backup, and how did you restore?
>>
>> Which version was used for each?
>>
>>> That worked as
>>> expected, I just didn’t start the engine yet.
>>
>> OK.
>>
>>> I know that after the backup
>>> was taken some machines where migrated around before the engine 
>>> disks failed.
>>
>> Are these machines HA?
>>
>>> My question is what will happen once I start the engine service 
>>> which has the restored backup on it ? Will it query the hosts for 
>>> the running VMs
>>
>> It will, but HA machines are handled differently.
>>
>> See also:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1441322
>> https://bugzilla.redhat.com/show_bug.cgi?id=1446055
>>
>>> or will it assume that the VMs are still on the hosts as they 
>>> resided at the point of backup ?
>>
>> It does, initially, but then updates status according to what it gets 
>> from hosts.
>>
>> But polling the hosts takes time, especially if you have many, and HA 
>> policy might require faster handling. So if it polls first a host 
>> that had a machine on it during backup, and sees that it's gone, and 
>> didn't yet poll the new host, HA handling starts immediately, which 
>> eventually might lead to starting the VM on another host.
>>
>> To prevent that, the fixes to above bugs make the restore process 
>> mark HA VMs that do not have leases on the storage as "dead".
>>
>>> Would I need to change the DB manual to let the 

Re: [ovirt-users] overt-guest-agent Failure on latest Debian 9 Sretch

[Sandro Bonazzola]

Tomas, anything we can do here?

Il lun 26 mar 2018, 22:18 Nicolas Vaye  ha
scritto:

> Hello Andrei,
>
> i have had the same problem and on Debian stretch the problem is the old
> version of agent from stretch repository.
>
> I downloaded 1.0.13 from Debian testing repo as *.deb file.
>
> With these new versions of guest-agent then is also a udev rules issue.
>
> The serial channels have been renamed and the rules didn`t match for ovirt.
>
> See the install script, as attachement (provided by  oliver%20riesener%20%3coliver.riese...@hs-bremen.de%3e>
> oliver.riese...@hs-bremen.de).
>
> May be it can help you.
>
> Regards,
>
> Nicolas Vaye
>
>  Message initial 
>
> Date: Mon, 26 Mar 2018 17:29:16 +0300
> Objet: [ovirt-users] overt-guest-agent Failure on latest Debian 9 Sretch
> À: users@ovirt.org
> De: Andrei Verovski >
>
> Hi,
>
> I just installed latest Debian 9 Sretch under oVirt 4.2 and got this error:
>
> # tail -n 1000 ovirt-guest-agent.log
> MainThread::INFO::2018-03-26
> 17:09:57,400::ovirt-guest-agent::59::root::Starting oVirt guest agent
> MainThread::ERROR::2018-03-26
> 17:09:57,402::ovirt-guest-agent::141::root::Unhandled exception in oVirt
> guest agent!
> Traceback (most recent call last):
>   File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 135, in
> 
> agent.run(daemon, pidfile)
>   File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 65, in run
> self.agent = LinuxVdsAgent(config)
>   File "/usr/share/ovirt-guest-agent/GuestAgentLinux2.py", line 472, in
> __init__
> AgentLogicBase.__init__(self, config)
>   File "/usr/share/ovirt-guest-agent/OVirtAgentLogic.py", line 188, in
> __init__
> self.vio = VirtIoChannel(config.get("virtio", "device"))
>   File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 153, in
> __init__
> self._stream = VirtIoStream(vport_name)
>   File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 134, in
> __init__
> self._vport = os.open(vport_name, os.O_RDWR)
> OSError: [Errno 2] No such file or directory:
> '/dev/virtio-ports/com.redhat.rhevm.vdsm’
>
> Followed this manual:
> https://bugzilla.redhat.com/show_bug.cgi?id=1472293
> and run
> touch /etc/udev/rules.d/55-ovirt-guest-agent.rules
> # edit  /etc/udev/rules.d/55-ovirt-guest-agent.rules
> SYMLINK=="virtio-ports/ovirt-guest-agent.0", OWNER="ovirtagent",
> GROUP="ovirtagent"
> udevadm trigger --subsystem-match="virtio-ports”
>
> AND this
>
> http://lists.ovirt.org/pipermail/users/2018-January/086101.html
> touch /etc/ovirt-guest-agent/ovirt-guest-agent.conf# <— it didn't
> existed so I created it.
> # edit /etc/ovirt-guest-agent.conf
> [virtio]
> device = /dev/virtio-ports/ovirt-guest-agent.0
>
> reboot
>
> Yet still have same problem and error message.
> How to solve it ?
>
> Thanks in advance
> Andrei
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Any monitoring tool provided?

[Shirly Radco]

--

SHIRLY RADCO

BI SeNIOR SOFTWARE ENGINEER

Red Hat Israel 

TRIED. TESTED. TRUSTED. 

On Tue, Mar 27, 2018 at 8:32 AM, Nicolas Vaye 
wrote:

> Hi Shirly,
>
> I'm trying to install ovirt metric store with ViaQ on Origin.
>
> And on https://github.com/oVirt/ovirt-site/pull/1551/files, you mention
> **WARNING** DO NOT INSTALL `libvirt` on the OpenShift machine!
>
>
> on my VM "metric store", i requested rpm for libvirt and here are the
> results :
>
> [root@ometricstore .ssh]# rpm -qa | grep libvirt
> libvirt-daemon-driver-secret-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-storage-core-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-storage-logical-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-config-network-3.2.0-14.el7_4.9.x86_64
> libvirt-gconfig-1.0.0-1.el7.x86_64
> libvirt-daemon-driver-storage-disk-3.2.0-14.el7_4.9.x86_64
> libvirt-glib-1.0.0-1.el7.x86_64
> libvirt-libs-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-nwfilter-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-storage-rbd-3.2.0-14.el7_4.9.x86_64
> libvirt-gobject-1.0.0-1.el7.x86_64
> libvirt-daemon-driver-interface-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-storage-scsi-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-qemu-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-kvm-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-network-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-storage-iscsi-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-nodedev-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-storage-mpath-3.2.0-14.el7_4.9.x86_64
> libvirt-daemon-driver-storage-3.2.0-14.el7_4.9.x86_64
>
> should i remove all this package ?
>

Yes. You will need to remove them.

>
>
> Also on the web page https://www.ovirt.org/develop/
> release-management/features/metrics/metrics-store-installation/#run-ovirt-
> metrics-store-installation-playbook, you mention
>
> /usr/share/ovirt-engine-metrics/setup/ansible/configure_ovirt_hosts_for_metrics.sh
> --playbook=ovirt-metrics-store-installation.yml
>

I apologise for that. It is indeed a documentation bug.
Its should be

/usr/share/ovirt-engine-metrics/setup/ansible/configure_ovirt_machines_for_metrics.sh
--playbook=ovirt-metrics-store-installation.yml

as you mentioned.
I'll fix it asap.

>
>
> But on my hosted engine 4.2.1.7 with 
> ovirt-engine-metrics-1.1.3.3-1.el7.centos.noarch,
> i notice that the script
>
> configure_ovirt_hosts_for_metrics.sh doesn't exist but there is a
> configure_ovirt_machines_for_metrics.sh script.
>
> Is it the good one ?
>
>
>
> Next, you mention :
> Allow connections on the following ports/protocols:
>
>
> + * tcp ports 22, 80, 443, 8443 (openshift console), 9200 (Elasticsearch)
>
>
> following by
>
> ViaQ on Origin requires these [Yum Repos](centos7-viaq.repo).
>
>
>
>
>
>
>
>
>
>
> +You will need to install the following packages: docker,
> iptables-services.
>
>
> That means that i must uninstall firewalld ? And the ports/protocols will
> be managed by iptables-services ?
>

No , you can just open the ports in firewalld.



>
> What is the command to allow connections on tcp ports 22,80, 443 etc ?
>

To open a Port on CentOS/RHEL 7 run

sudo firewall-cmd --zone=public --add-port=80/tcp --permanent

for each port and

sudo firewall-cmd --reload

Check the updated rules with:

firewall-cmd --list-all

>
> Is it managed automatically with  docker or openshift or other program ?
>

The metrics store is managed by OpenShift.


>
>
> Thanks for all.
>
>
> Nicolas VAYE
>
>
>  Message initial 
>
> Date: Sun, 25 Mar 2018 12:01:23 +0300
> Objet: Re: [ovirt-users] Any monitoring tool provided?
> Cc: users >
> À: Marcelo Leandro  3cmarcelol...@gmail.com%3e>>
> De: Shirly Radco  ly%20radco%20%3csra...@redhat.com%3e>>
>
>
>
> --
>
> SHIRLY RADCO
>
> BI SeNIOR SOFTWARE ENGINEER
>
> Red Hat Israel
>
> [https://www.redhat.com/files/brand/email/sig-redhat.png] tps://red.ht/sig>
> TRIED. TESTED. TRUSTED.
>
>
> On Fri, Mar 23, 2018 at 10:29 PM, Marcelo Leandro  > wrote:
> Hello,
>
> I am try this how to:
>
> https://www.ovirt.org/develop/release-management/features/
> metrics/metrics-store-installation/
>
> but when i run this command:
> /usr/share/ovirt-engine-metrics/setup/ansible/
> configure_ovirt_machines_for_metrics.sh  --playbook=ovirt-metrics-
> store-installation.yml
>
> I am had this error mensagem:
> ansible-playbook: error: no such option: --playbook
>
> my version:
>
> ovirt-engine-metrics-1.0.8-1.el7.centos.noarch
>
>
> Hi,
>
> You are using an old rpm.
>
> Please upgrade to latest, 

Re: [ovirt-users] virtual machine actual size is not right

[Terry hey]

Hello, thank you for helping me.

On the storage domain size:
Alias: host1
Disk: 1
Template: Blank
Virtual Size: 30 GB
Actual Size: 13 GB
Creation Date: Jan 29,2018 11:22:54 AM

On the server size:
# df -h
Filesystem   Size  Used Avail Use% Mounted on
/dev/mapper/vg01-root 10G  7.2G  2.9G  72% /
devtmpfs 1.9G 0  1.9G   0% /dev
tmpfs1.9G  4.0K  1.9G   1% /dev/shm
tmpfs1.9G   17M  1.9G   1% /run
tmpfs1.9G 0  1.9G   0% /sys/fs/cgroup
/dev/sda1   1014M  188M  827M  19% /boot
/dev/mapper/vg01-var  15G  996M   15G   7% /var
XXX.XXX.XXX.XXX:/nfs_share  249G   96G  141G  41% /mnt/nfs_share
tmpfs379M 0  379M   0% /run/user/0

# parted -l /dev/[sv]d[a-z] | grep ^Disk
Disk /dev/sda: 32.2GB
Disk Flags:
Disk /dev/mapper/vg01-var: 16.1GB
Disk Flags:
Disk /dev/mapper/vg01-swap: 2147MB
Disk Flags:
Disk /dev/mapper/vg01-root: 10.7GB
Disk Flags:
#

It still not the same. Also, do you know the upper limitation for thin
provision?
For example, if i allocated 30 GB to the hosts, what is the upper
limitation that the host can use?

Regards,
Terry

2018-03-23 18:45 GMT+08:00 Pavol Brilla :

> Hi
>
> For such big difference between size outside of VM and inside, it looks
> more that disk is not fully partioned.
> df is providing you information only about mounted filesystems.
> Could you try to run inside VM should match all local disks, and you
> should see size of disk :
> # parted -l /dev/[sv]d[a-z] | grep ^Disk
>
> ( Output of 1 of my VMs ):
> # parted -l /dev/[sv]d[a-z] | grep ^Disk
> Disk /dev/sda: 26.8GB
> Disk Flags:
> Disk /dev/mapper/rootvg-lv_tmp: 2147MB
> Disk Flags:
> Disk /dev/mapper/rootvg-lv_home: 210MB
> Disk Flags:
> Disk /dev/mapper/rootvg-lv_swap: 2147MB
> Disk Flags:
> Disk /dev/mapper/rootvg-lv_root: 21.8GB
>
> So I see that VM has 26.8GB big disk.
>
> On Thu, Mar 22, 2018 at 5:56 PM, Terry hey  wrote:
>
>> Hello~
>> i type this command on the running vm, not the hypervisor ( ovirt node).
>>
>
>
>
> --
>
> PAVOL BRILLA
>
> RHV QUALITY ENGINEER, CLOUD
>
> Red Hat Czech Republic, Brno 
> 
> TRIED. TESTED. TRUSTED. 
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Ping::(action) Failed to ping x.x.x.x, (4 out of 5)

[i...@linuxfabrik.ch]

Hi all,

we randomly and constantly have this message in our /var/log/ovirt-
hosted-engine-ha/broker.log:

/var/log/ovirt-hosted-engine-ha/broker.log:Thread-1::WARNING::2018-03-
27 08:17:25,891::ping::63::ping.Ping::(action) Failed to ping x.x.x.x,
(4 out of 5)

The pinged device is a switch (not a gateway). We know that a switch
might drop icmp packets if it needs to. The interesting thing about
that is if it fails it fails always at "4 out of 5", but in the end (5
of 5) it always succeeds.

Is there a way to increase the amount of pings or to have another way
instead of ping?


Regards
Markus
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users