April 2017 - Users - oVirt List Archives

Feature: Hosted engine VM management
by Roy Golan 27 Feb '19

27 Feb '19

Hi all, Upcoming in 3.6 is enhancement for managing the hosted engine VM. In short, we want to: * Allow editing the Hosted engine VM, storage domain, disks, networks etc * Have a shared configuration for the hosted engine VM * Have a backup for the hosted engine VM configuration please review and comment on the wiki below: http://www.ovirt.org/Hosted_engine_VM_management Thanks, Roy

2 3

Re: [ovirt-users] Large DWH Database, how to empty
by Matt . 26 Feb '19

26 Feb '19

Hi, OK thanks! I saw that after upgrading to 4.0.5 from 4.0.4 the DB already dropped with around 500MB directly and is now at 2GB smaller. Does this sounds familiar to you with other settings in 4.0.5 ? Thanks, Matt 2017-01-08 10:45 GMT+01:00 Shirly Radco <sradco(a)redhat.com>: > No. That will corrupt your database. > > Are you using the full dwh or the smaller version for the dashboards? > > Please set the delete thresholds to save less data and the data older then > the time you set will be deleted. > Add a file to /ovirt-engine-dwhd.conf.d/ > update_time_to_keep_records.conf > > Add these lines with the new configurations. The numbers represent the hours > to keep the data. > > DWH_TABLES_KEEP_SAMPLES=24 > DWH_TABLES_KEEP_HOURLY=1440 > DWH_TABLES_KEEP_DAILY=43800 > > > These are the configurations for a full dwh. > > The smaller version configurations are: > DWH_TABLES_KEEP_SAMPLES=24 > DWH_TABLES_KEEP_HOURLY=720 > DWH_TABLES_KEEP_DAILY=0 > > The delete process by default at 3am every day (DWH_DELETE_JOB_HOUR=3) > > Best regards, > > Shirly Radco > > BI Software Engineer > Red Hat Israel Ltd. > 34 Jerusalem Road > Building A, 4th floor > Ra'anana, Israel 4350109 > > > On Fri, Jan 6, 2017 at 6:35 PM, Matt . <yamakasi.014(a)gmail.com> wrote: >> >> Hi, >> >> I seem to have some large database for the DWH logging and I wonder >> how I can empty it safely. >> >> Can I just simply empty the database ? >> >> Have a good weekend! >> >> Cheers, >> >> Matt >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > >

1 0

Re: [ovirt-users] Packet loss
by Doron Fediuck 26 Feb '19

26 Feb '19

----_com.android.email_640187878761650 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgS3lsZSzCoApXZSBtYXkgaGF2ZSBzZWVuIHNvbWV0aGluZyBzaW1pbGFyIGluIHRoZSBwYXN0 IGJ1dCBJIHRoaW5rIHRoZXJlIHdlcmUgdmxhbnMgaW52b2x2ZWQuwqAKSXMgaXQgdGhlIHNhbWUg Zm9yIHlvdT/CoApUb255IC8gRGFuLCBkb2VzIGl0IHJpbmcgYSBiZWxsP8Kg ----_com.android.email_640187878761650 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5IaSBLeWxlLCZuYnNwOzwv ZGl2PjxkaXY+V2UgbWF5IGhhdmUgc2VlbiBzb21ldGhpbmcgc2ltaWxhciBpbiB0aGUgcGFzdCBi dXQgSSB0aGluayB0aGVyZSB3ZXJlIHZsYW5zIGludm9sdmVkLiZuYnNwOzwvZGl2PjxkaXY+SXMg aXQgdGhlIHNhbWUgZm9yIHlvdT8mbmJzcDs8L2Rpdj48ZGl2PlRvbnkgLyBEYW4sIGRvZXMgaXQg cmluZyBhIGJlbGw/Jm5ic3A7PC9kaXY+PC9ib2R5PjwvaHRtbD4= ----_com.android.email_640187878761650--

2 1

Unable to backend oVirt with Cinder
by Logan Kuhn 21 Jun '18

21 Jun '18

------=_Part_51316288_608143832.1472587678781 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I've got Cinder configured and pointed at Ceph for it's back end storage. I can run ceph commands on the cinder machine and cinder is configured for noauth and I've also tried it with Keystone for auth. I can run various cinder commands and it'll return as expected. When I configure it in oVirt it'll add the external provider fine, but when I go to create a disk it doesn't populate the volume type field, it's just empty. The corresponding command for cinder: cinder type-list and cinder type-show <name> returns fine and it is public. Ovirt and Cinder are on the same host so it isn't a firewall issue. Cinder config: [DEFAULT] rpc_backend = rabbit #auth_strategy = keystone auth_strategy = noauth enabled_backends = ceph #glance_api_servers = http://10.128.7.252:9292 #glance_api_version = 2 #[keystone_authtoken] #auth_uri = http://10.128.7.252:5000/v3 #auth_url = http://10.128.7.252:35357/v3 #auth_type = password #memcached_servers = localhost:11211 #project_domain_name = default #user_domain_name = default #project_name = services #username = user #password = pass [ceph] volume_driver = cinder.volume.drivers.rbd.RBDDriver volume_backend_name = ceph rbd_pool = ovirt-images rbd_user = cinder rbd_secret_uuid = <secret> rbd_ceph_conf = /etc/ceph/ceph.conf rbd_flatten_volume_from_snapshot = true rbd_max_clone_depth = 5 rbd_store_chunk_size = 4 rados_connect_timeout = -1 #glance_api_version = 2 [database] connection = postgresql://user:pass@10.128.2.33/cinder [oslo_concurrency] lock_path = /var/lib/cinder/tmp [oslo_messaging_rabbit] rabbit_host = localhost rabbit_port = 5672 rabbit_userid = user rabbit_password = pass Regards, Logan ------=_Part_51316288_608143832.1472587678781 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: Arial; font-size: 12pt; color: #0000= 00"><div>I've got Cinder configured and pointed at Ceph for it's back end s= torage.  I can run ceph commands on the cinder machine and cinder is c= onfigured for noauth and I've also tried it with Keystone for auth.  I= can run various cinder commands and it'll return as expected. </= div><div><br data-mce-bogus=3D"1"></div><div>When I configure it in oVirt i= t'll add the external provider fine, but when I go to create a disk it does= n't populate the volume type field, it's just empty.  The correspondin= g command for cinder: cinder type-list and cinder type-show <name> re= turns fine and it is public. </div><div><br data-mce-bogus=3D"1"></div= ><div>Ovirt and Cinder are on the same host so it isn't a firewall issue.</= div><div><br data-mce-bogus=3D"1"></div><div>Cinder config:</div><div>[DEFA= ULT]<br>rpc_backend =3D rabbit<br>#auth_strategy =3D keystone<br>auth_strat= egy =3D noauth<br>enabled_backends =3D ceph<br>#glance_api_servers =3D http= ://10.128.7.252:9292<br>#glance_api_version =3D 2<br><br>#[keystone_authtok= en]<br>#auth_uri =3D http://10.128.7.252:5000/v3<br>#auth_url =3D http://10= .128.7.252:35357/v3<br>#auth_type =3D password<br>#memcached_servers =3D lo= calhost:11211<br>#project_domain_name =3D default<br>#user_domain_name =3D = default<br>#project_name =3D services<br>#username =3D user<br>#passwo= rd =3D pass<br><br>[ceph]<br>volume_driver =3D cinder.volume.drivers.rbd.RB= DDriver<br>volume_backend_name =3D ceph<br>rbd_pool =3D ovirt-images<br>rbd= _user =3D cinder<br>rbd_secret_uuid =3D <secret><br>rbd_ceph_con= f =3D /etc/ceph/ceph.conf<br>rbd_flatten_volume_from_snapshot =3D true<br>r= bd_max_clone_depth =3D 5<br>rbd_store_chunk_size =3D 4<br>rados_connect_tim= eout =3D -1<br>#glance_api_version =3D 2<br><br>[database]<br>connection = =3D postgresql://user:pass@10.128.2.33/cinder<br><br>[oslo_concurrency]<br>= lock_path =3D /var/lib/cinder/tmp<br><br>[oslo_messaging_rabbit]<br>rabbit_= host =3D localhost<br>rabbit_port =3D 5672<br>rabbit_userid =3D <span = style=3D"color: #000000; font-family: Arial; font-size: 16px; font-style: n= ormal; font-variant-ligatures: normal; font-variant-caps: normal; font-weig= ht: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-a= lign: start; text-indent: 0px; text-transform: none; white-space: normal; w= idows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inlin= e !important; float: none; background-color: #ffffff;" data-mce-style=3D"co= lor: #000000; font-family: Arial; font-size: 16px; font-style: normal; font= -variant-ligatures: normal; font-variant-caps: normal; font-weight: normal;= letter-spacing: normal; line-height: normal; orphans: 2; text-align: start= ; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; w= ord-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !importan= t; float: none; background-color: #ffffff;">user</span><br>rabbit_password = =3D <span style=3D"color: #000000; font-family: Arial; font-size: 16px= ; font-style: normal; font-variant-ligatures: normal; font-variant-caps: no= rmal; font-weight: normal; letter-spacing: normal; line-height: normal; orp= hans: 2; text-align: start; text-indent: 0px; text-transform: none; white-s= pace: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;= display: inline !important; float: none; background-color: #ffffff;" data-= mce-style=3D"color: #000000; font-family: Arial; font-size: 16px; font-styl= e: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-= weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; te= xt-align: start; text-indent: 0px; text-transform: none; white-space: norma= l; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: i= nline !important; float: none; background-color: #ffffff;">pass</span></div= ><div><br></div><div data-marker=3D"__SIG_PRE__">Regards,<br>Logan</div></d= iv></body></html> ------=_Part_51316288_608143832.1472587678781--

4 4

vdsClient is removed and replaced by vdsm-client
by Irit Goihman 16 Apr '18

16 Apr '18

Hi All, vdsClient will be removed from master branch today. It is using XMLRPC protocol which has been deprecated and replaced by JSON-RPC. A new client for vdsm was introduced in 4.1: vdsm-client. This is a simple client that uses JSON-RPC protocol which was introduced in ovirt 3.5. The client is not aware of the available methods and parameters, and you should consult the schema [1] in order to construct the desired command. Future version should parse the schema and provide online help. If you're using vdsClient, we will be happy to assist you in migrating to the new vdsm client. *vdsm-client usage:* vdsm-client [-h] [-a ADDRESS] [-p PORT] [--unsecure] [--timeout TIMEOUT] [-f FILE] namespace method [name=value [name=value] ...] Invoking simple methods: # vdsm-client Host getVMList ['b3f6fa00-b315-4ad4-8108-f73da817b5c5'] For invoking methods with many or complex parameters, you can read the parameters from a JSON format file: # vdsm-client Lease info -f lease.json where lease.json file content is: { "lease": { "sd_id": "75ab40e3-06b1-4a54-a825-2df7a40b93b2", "lease_id": "b3f6fa00-b315-4ad4-8108-f73da817b5c5" } } It is also possible to read parameters from standard input, creating complex parameters interactively: # cat <<EOF | vdsm-client Lease info -f - { "lease": { "sd_id": "75ab40e3-06b1-4a54-a825-2df7a40b93b2", "lease_id": "b3f6fa00-b315-4ad4-8108-f73da817b5c5" } } EOF *Constructing a command from vdsm schema:* Let's take VM.getStats as an example. This is the entry in the schema: VM.getStats: added: '3.1' description: Get statistics about a running virtual machine. params: - description: The UUID of the VM name: vmID type: *UUID return: description: An array containing a single VmStats record type: - *VmStats namespace: VM method name: getStats params: vmID The vdsm-client command is: # vdsm-client VM getStats vmID=b3f6fa00-b315-4ad4-8108-f73da817b5c5 *Invoking getVdsCaps command:* # vdsm-client Host getCapabilities Please consult vdsm-client help and man page for further details and options. [1] https://github.com/oVirt/vdsm/blob/master/lib/api/vdsm-api.yml -- Irit Goihman Software Engineer Red Hat Israel Ltd.

4 7

Passing VLAN trunk to VM
by Simon Vincent 26 Mar '18

26 Mar '18

Is it possible to pass multiple VLANs to a VM (pfSense) using a single virtual NIC? All my existing oVirt networks are setup as a single tagged VLAN. I know this didn't used to be supported but wondered if this has changed. My other option is to pass each VLAN as a separate NIC to the VM however if I needed to add a new VLAN I would have to add a new interface and reboot the VM as hot-add of NICs is not supported by pfSense.

6 14

HostedEngine with HA
by Carlos Rodrigues 22 Mar '18

22 Mar '18

Hello, I have one cluster with two hosts with power management correctly configured and one virtual machine with HostedEngine over shared storage with FiberChannel. When i shutdown the network of host with HostedEngine VM, it should be possible the HostedEngine VM migrate automatically to another host? What is the expected behaviour on this HA scenario? Regards, -- Carlos Rodrigues Engenheiro de Software Sénior Eurotux Informática, S.A. | www.eurotux.com (t) +351 253 680 300 (m) +351 911 926 110

4 30

Official Hyperconverged Gluster oVirt upgrade procedure?
by Hanson 23 Jan '18

23 Jan '18

Hi Guys, Just wondering if we have an updated manual or whats the current procedure for upgrading the nodes in a hyperconverged ovirt gluster pool? Ie Nodes run 4.0 oVirt, as well as GlusterFS, and hosted-engine running in a gluster storage domain. Put node in maintenance mode and disable glusterfs from ovirt gui, run yum update? Thanks!

4 4

[vdsm] status update: running containers alongside VMs
by Francesco Romani 05 Jan '18

05 Jan '18

Hi everyone, I'm happy to share some progress about the former "convirt"[1] project, which aims to let Vdsm containers alongside VMs, on bare metal. In the last couple of months I kept updating the patch series, which is approaching the readiness to be merged in Vdsm. Please read through this mail to see what the patchset can do now, how you could try it *now*, even before it is merged. Everyone is invited to share thoughts and ideas about how this effort could evolve. This will be a long mail; I will amend, enhance and polish the content and make a blog post (on https://mojaves.github.io) to make it easier to consume and to have some easy-to-find documentation. Later on the same content will appear also on the oVirt blog. Happy hacking! +++ # How to try how the experimental container support for Vdsm. Vdsm is gaining *experimental* support to run containers alongside VMs. Vdsm had since long time the ability to manage VMs which run containers, and recently gained support for [atomic guests](http://www.projectatomic.io/blog/2015/01/running-ovirt-guest-agent-as-privileged-container/). With the new support we are describing, you will be able to manage containers with the same, proven infrastructure that let you manage VMs. This feature is currently being developed and it is still not merged in the Vdsm codebase, so some extra work is needed if you want to try it out. We aiming to merge it in the oVirt 4.1.z cycle. ## What works, aka what to expect The basic features are expected to work: 1. Run any docker image on the public docker registry 2. Make the container accessible from the outside (aka not just from localhost) 3. Use file-based storage for persistent volumes ## What does not yet work, aka what NOT to expect Few things are planned and currently under active development: 1. Monitoring. Engine will not get any update from the container besides "VM" status (Up, Down...) One important drawback is that you will not be told the IP of the container from Engine, you will need to connect to the Vdsm host to discover it using standard docker tools. 2. Proper network integration. Some steps still need manual intervention 3. Stability and recovery - it's pre-alpha software after all! :) ## 1. Introduction and prerequisites Trying out container support affects only the host and the Vdsm. Besides add few custom properties (totally safe and supported since early 3.z), there are zero changes required to the DB and to Engine. Nevertheless, we recommend to dedicate one oVirt 4.y environment, or at least one 4.y host, to try out the container feature. To get started, first thing you need is to setup a vanilla oVirt 4.y installation. We will need to make changes to the Vdsm and to the Vdsm host, so hosted engine and/or oVirt node may add extra complexity, better to avoid them at the moment. The reminder of this tutorial assumes you are using two hosts, one for Vdsm (will be changed) and one for Engine (will require zero changes); furthermore, we assume the Vdsm host is running on CentOS 7.y. We require: - one test host for Vdsm. This host need to have one NIC dedicated to containers. We will use the [docker macvlan driver](https://raesene.github.io/blog/2016/07/23/Docker-MacVLAN/), so this NIC *must not be* part of one bridge. - docker >= 1.12 - oVirt >= 4.0.5 (Vdsm >= 4.18.15) - CentOS >= 7.2 Docker >= 1.12 is avaialable for download [here](https://docs.docker.com/engine/installation/linux/centos/) Caveats: 1. docker from official rpms conflicts con docker from CentOS, and has a different package name: docker-engine vs docker. Please note that the kubernetes package from CentOS, for example, require 'docker', not 'docker-engine'. 2. you may want to replace the default service file [with this one](https://github.com/mojaves/convirt/blob/master/patches/centos72/system… and to use this [sysconfig file](https://github.com/mojaves/convirt/blob/master/patches/centos72/syste…. Here I'm just adding the storage options docker requires, much like the CentOS docker is configured. Configuring docker like this can save you some troubleshooting, especially if you had docker from CentOS installed on the testing box. ## 2. Patch Vdsm to support containers You need to patch and rebuild Vdsm. Fetch [this patch](https://github.com/mojaves/convirt/blob/master/patches/vdsm/4.18.15.… and apply it against Vdsm 4.18.15.1. Vdsm 4.18.15.{1,2,...} are supported as well. Rebuild Vdsm and reinstall on your box. [centos 7.2 packages are here](https://github.com/mojaves/convirt/tree/master/rpms/centos72) Make sure you install the Vdsm command line client (vdsm-cli) Restart *both* Vdsm and Supervdsm, make sure Engine still works flawlessly with patched Vdsm. This ensure that no regression is introduced, and that your environment can run VMs just as before. Now we can proceed adding the container support. start docker: # systemctl start docker-engine (optional) # systemctl enable docker-engine Restart Vdsm again # systemctl restart vdsm Now we can check if Vdsm detects docker, so you can use it: still on the same Vdsm host, run $ vdsClient -s 0 getVdsCaps | grep containers containers = ['docker', 'fake'] This means this Vdsm can run containers using 'docker' and 'fake' runtimes. Ignore the 'fake' runtime; as the name suggests, is a test driver, kinda like /dev/null. Now we need to make sure the host network configuration is fine. ### 2.1. Configure the docker network for Vdsm PLEASE NOTE that the suggested network configuration assumes that * you have one network, `ovirtmgmt` (the default one) you use for everything * you have one Vdsm host with at least two NICs, one bound to the `ovirtmgmt` network, and one spare _This step is not yet automated by Vdsm_, so manual action is needed; Vdsm will take care of this automatically in the future. You can use [this helper script](https://github.com/mojaves/convirt/blob/master/patches/vdsm/cont-se…, which reuses the Vdsm libraries. Make sure you have patched Vdsm to support container before to use it. Let's review what the script needs: # ./cont-setup-net -h usage: cont-setup-net [-h] [--name [NAME]] [--bridge [BRIDGE]] [--interface [INTERFACE]] [--gateway [GATEWAY]] [--subnet [SUBNET]] [--mask [MASK]] optional arguments: -h, --help show this help message and exit --name [NAME] network name to use --bridge [BRIDGE] bridge to use --interface [INTERFACE] interface to use --gateway [GATEWAY] address of the gateway --subnet [SUBNET] subnet to use --mask [MASK] netmask to use So we need to feed --name, --interface, --gateway, --subnet and optionally --mask (default, /24, is often fine). For my case the default mask was indeed fine, so I used the script like this: # ./cont-setup-net --name ovirtmgmt --interface enp3s0 --gateway 192.168.1.1 --subnet 192.168.1.0 Thhis is the output I got: DEBUG:virt.containers.runtime:configuring runtime 'docker' DEBUG:virt.containers.command:* calling ['/bin/docker', 'network', 'inspect', 'ovirtmgmt'] Error: No such network: ovirtmgmt DEBUG:virt.containers.command:* called ['/bin/docker', 'network', 'inspect', 'ovirtmgmt'] DEBUG:virt.containers.runtime.Docker:config: cannot load 'ovirtmgmt', ignored DEBUG:virt.containers.command:* calling ['/bin/docker', 'network', 'create', '-d', 'macvlan', '--subnet=192.168.1.0/24', '--gateway=192.168.1.1', '--ip-range=192.168.1.0/24', '-o', 'parent=enp3s0', 'ovirtmgmt'] DEBUG:virt.containers.command:* called ['/bin/docker', 'network', 'create', '-d', 'macvlan', '--subnet=192.168.1.0/24', '--gateway=192.168.1.1', '--ip-range=192.168.1.0/24', '-o', 'parent=enp3s0', 'ovirtmgmt'] DEBUG:virt.containers.runtime:configuring runtime 'fake' You can clearly see what the script did, and why it needed the root privileges. Let's deoublecheck using the docker tools: # docker network ls NETWORK ID NAME DRIVER SCOPE 91535f3425a8 bridge bridge local d42f7e5561b5 host host local 621ab6dd49b1 none null local f4b88e4a67eb ovirtmgmt macvlan local # docker network inspect ovirtmgmt [ { "Name": "ovirtmgmt", "Id": "f4b88e4a67ebb7886ec74073333d613b1893272530cae4d407c95ab587c5fea1", "Scope": "local", "Driver": "macvlan", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "192.168.1.0/24", "IPRange": "192.168.1.0/24", "Gateway": "192.168.1.1" } ] }, "Internal": false, "Containers": {}, "Options": { "parent": "enp3s0" }, "Labels": {} } ] Looks good! the host configuration is completed. Let's move to the Engine side. ## 3. Configure Engine As mentioned above, we need now to configure Engine. This boils down to: Add a few custom properties for VMs: In case you were already using custom properties, you need to amend the command line to not overwrite your existing ones. # engine-config -s UserDefinedVMProperties='volumeMap=^[a-zA-Z_-]+:[a-zA-Z_-]+$;containerImage=^[a-zA-Z]+(://|)[a-zA-Z]+$;containerType=^(docker|rkt)$' --cver=4.0 It is worth stressing that while the variables are container-specific, the VM custom properties are totally inuntrusive and old concept in oVirt, so this step is totally safe. Now restart Engine to let it use the new variables: # systemctl restart ovirt-engine The next step is actually configure one "container VM" and run it. ## 4. Create the container "VM" To finally run a container, you start creating a VM much like you always did, with few changes 1. most of the hardware-related configuration isn't relevant for container "VMs", besides cpu share and memory limits; this will be better documented in the future; unneeded configuration will just be ignored 2. You need to set some custom properties for your container "VM". Those are actually needed to enable the container flow, and they are documented in the next section. You *need* to set at least `containerType` and `containerImage`. ### 4.2. Custom variables for container support The container support needs some custom properties to be properly configured: 1. `containerImage` (*needed* to enable the container system). Just select the target image you want to run. You can use the standard syntax of the container runtimes. 2. `containerType` (*needed* to enable the container system). Selects the container runtime you want to use. All the available options are always showed. Please note that unavailable container options are not yet grayed out. If you *do not* have rkt support on your host, you still can select it, but it won't work. 3. `volumeMap` key:value like. You can map one "VM" disk (key) to one container volume (value), to have persistent storage. Only file-based storage is supported. Example configuration: `containerImage = redis` `containerType = docker` `volumeMap = vda:data` (this may not be needed, and the volume label is just for illustrative purposes) ### 4.2. A little bit of extra work: preload the images on the Vdsm host This step is not needed by the flow, and will be handled by oVirt in the future. The issue is how the container image are handled. They are stored by the container management system (rkt, docker) on each host, and they are not pre-downloaded. To shorten the duration of the first boot, you are advised to pre-download the image(s) you want to run. For example ## on the Vdsm host you want to use with containers # docker pull redis ## 5. Run the container "VM" You are now all set to run your "VM" using oVirt Engine, just like any existing VM. Some actions doesn't make sense for a container "VM", like live migration. Engine won't stop you to try to do those actions, but they will fail gracefully using the standard errors. ## 6. Next steps What to expect from this project in the future? For the integration with Vdsm, we want to fix the existing known issues, most notably: * add proper monitoring/reporting of the container health * ensure proper integration of the container image store with oVirt storage management * streamline the network configuration What is explicitely excluded yet is any Engine change. This is a Vdsm-only change at the moment, so fixing the following is currently unplanned: * First and foremost, Engine will not distinguish between real VMs and container VMs. Actions unavailable to container will not be hidden from UI. Same for monitoring and configuration data, which will be ignored. * Engine is NOT aware of the volumes one container can use. You must inspect and do the mapping manually. * Engine is NOT aware of the available container runtimes. You must select it carefully Proper integration with Engine may be added in the future once this feature exits from the experimental/provisional stage. Thanks for reading, make sure to share your thoughts on the oVirt mailing lists! +++ [1] we keep calling it that way _only_ internally, because it's a short name we are used to. After the merge/once we release it, we will use a different name, like "vdsm-containers" or something like it. -- Francesco Romani Red Hat Engineering Virtualization R & D Phone: 8261328 IRC: fromani

3 2

Re: [ovirt-users] iSCSI domain on 4kn drives
by Martijn Grendelman 13 Nov '17

13 Nov '17

--------------DE48748F7C67E1FABE46EEAF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Op 7-8-2016 om 8:19 schreef Yaniv Kaul: > > On Fri, Aug 5, 2016 at 4:42 PM, Martijn Grendelman > <martijn.grendelman(a)isaac.nl <mailto:martijn.grendelman@isaac.nl>> wrote: > > Op 4-8-2016 om 18:36 schreef Yaniv Kaul: >> On Thu, Aug 4, 2016 at 11:49 AM, Martijn Grendelman >> <martijn.grendelman(a)isaac.nl >> <mailto:martijn.grendelman@isaac.nl>> wrote: >> >> Hi, >> >> Does oVirt support iSCSI storage domains on target LUNs using >> a block >> size of 4k? >> >> >> No, we do not - not if it exposes 4K blocks. >> Y. > > Is this on the roadmap? > > > Not in the short term roadmap. > Of course, patches are welcome. It's mainly in VDSM. > I wonder if it'll work in NFS. > Y. I don't think I ever replied to this, but I can confirm that in RHEV 3.6 it works with NFS. Best regards, Martijn. --------------DE48748F7C67E1FABE46EEAF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Op 7-8-2016 om 8:19 schreef Yaniv Kaul:<br> <blockquote cite="mid:280cfbd3a16ad1b76cc7de56bda88f45,CAJgorsbJHLV1e3fH4b4AR3GBp1oi44fDhfeii+PQ1iY1RwUStw@mail.gmail.com" type="cite"> <div dir="ltr"><br> <div class="gmail_extra">On Fri, Aug 5, 2016 at 4:42 PM, Martijn Grendelman <span dir="ltr"><<a moz-do-not-send="true" href="mailto:martijn.grendelman@isaac.nl" target="_blank">martijn.grendelman(a)isaac.nl</a>></span> wrote:<br> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div bgcolor="#FFFFFF" text="#000000"> Op 4-8-2016 om 18:36 schreef Yaniv Kaul:<br> <blockquote type="cite"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"><span class="">On Thu, Aug 4, 2016 at 11:49 AM, Martijn Grendelman <span dir="ltr"><<a moz-do-not-send="true" href="mailto:martijn.grendelman@isaac.nl" target="_blank">martijn.grendelman(a)isaac.nl</a>></span> wrote:<br> </span><span class=""> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br> <br> Does oVirt support iSCSI storage domains on target LUNs using a block<br> size of 4k?<br> </blockquote> <div><br> </div> </span><span class=""> <div>No, we do not - not if it exposes 4K blocks.</div> <div>Y.</div> </span></div> </div> </div> </blockquote> <br> Is this on the roadmap?<br> </div> </blockquote> <div><br> </div> <div>Not in the short term roadmap.</div> <div>Of course, patches are welcome. It's mainly in VDSM.</div> <div>I wonder if it'll work in NFS.</div> <div>Y.</div> </div> </div> </div> </blockquote> <br> I don't think I ever replied to this, but I can confirm that in RHEV 3.6 it works with NFS.<br> <br> Best regards,<br> Martijn.<br> </body> </html> --------------DE48748F7C67E1FABE46EEAF--

4 4

Re: [ovirt-users] How to import a qcow2 disk into ovirt
by Martín Follonier 04 Oct '17

04 Oct '17

Hi, I've done all the recommendations in this thread, and I'm still getting the "Paused by System" message just after the transfer starts. Honestly I don't know were else to look at, cause I don't find any log entry or packet capture that give me a hint about what is happening. I'll appreciate any help! Thank you in advance! Regards Martin On Thu, Sep 1, 2016 at 5:01 PM, Amit Aviram <aavi...(a)redhat.com> wrote: > You can do both, > Through the database, the table is "vdc_options". change "option_value" > where "option_name" = 'ImageProxyAddress' . > > On Thu, Sep 1, 2016 at 4:56 PM, Gianluca Cecchi <gianluca.cec...(a)gmail.com > > wrote: > >> On Thu, Sep 1, 2016 at 3:53 PM, Amit Aviram <aavi...(a)redhat.com> wrote: >> >>> You can just replace this value in the DB and change it to the right >>> FQDN, it is a config value named "ImageProxyAddress". replace "localhost" >>> with the right address (notice that the port is there too). >>> >>> If this will keep happen after users will have the latest version, we >>> will have to open a bug and fix whatever causes the URL to be "localhost". >>> >>> >> Do you mean through "engine-config" or directly into database? >> In this second case which is the table involved? >> >> Gianluca >> > > [root@ractorshe bin]# systemctl stop ovirt-imageio-proxy engine=# select * from vdc_options where option_name='ImageProxyAddress'; option_id | option_name | option_value | version -----------+-------------------+-----------------+--------- 950 | ImageProxyAddress | localhost:54323 | general (1 row) engine=# update vdc_options set option_value='ractorshe.mydomain:54323' where option_name='ImageProxyAddress'; UPDATE 1 engine=# select * from vdc_options where option_name='ImageProxyAddress'; option_id | option_name | option_value | version -----------+-------------------+--------------------------------------+--------- 950 | ImageProxyAddress | ractorshe.mydomain:54323 | general (1 row) engine=# engine=# select * from vdc_options where option_name='ImageProxyAddress'; option_id | option_name | option_value | version -----------+-------------------+--------------------------------------+--------- 950 | ImageProxyAddress | ractorshe.mydomain:54323 | general (1 row) systemctl stop ovirt-engine (otherwise it remained localhost) systemctl start ovirt-engine systemctl start ovirt-imageio-proxy Now transfer is ok. I tried a qcow2 disck configured as 40Gb but containing about 1.6Gb of data. I'm going to connect it to a VM and see if all is ok also from a contents point of view. Gianluca _______________________________________________ Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users

5 6

ovirt-hosted-engine state transition messages
by Jim Kusznir 23 Jul '17

23 Jul '17

Hello: I find that I often get random-seeming messages. A lot of them mention "ReintializeFSM", but I also get engine down, engine start, etc. messages. All the time, nothing appears to be happening on the cluster, and I rarely can find anything wrong or any trigger/cause. Is this normal? What causes this (beyond obvious hardware issues / hosts rebooting)? Most of the time when I get these, my cluster is going along smoothly, and nothing (not even administrative access) is interrupted. Could ISP issues cause these messages to be generated? Thanks! --Jim

5 7

iSCSI storage domain and multipath when adding node
by Gianluca Cecchi 27 Jun '17

27 Jun '17

Hello, my configuration is what described here: http://lists.ovirt.org/pipermail/users/2017-March/080992.html So I'm using iSCSI multipath and not bonding can anyone reproduce? Initial situation is only one node configured and active with some VMS I go and configure a second node; it tries to activate but networks are not all already mapped and so gies to non operational. I setup all networks and activate the node It happens that: - on the first node where I currently have 2 iSCSI connections and 2multipath lines (with p1p1.100 and p1p2) it is instantiated a new iSCSI SID using interface "default" and in multipath -l output I see now 3 lines - on the newly added node I only see 1 iSCSI SID using interface default My way to solve the situation was to go inside iscsi multipath section do nothing but save the same config brutally on first node iscsiadm -m session -u --> all iscsi sessions are closed after a while I see again the original 2 connections recovered, with correct interface names used - on second node iscsiadm -m session -u --> the only session is cloed nothing happens if I set to maintenance the node and then activate the node --> the 2 correct iscsi sessions are activated... Thanks Gianluca

2 5

Lowering the bar for wiki contribution?
by Roy Golan 22 Jun '17

22 Jun '17

I'm getting the feeling I'm not alone in this, authoring and publishing a wiki page isn't as used to be for long time. I want to suggest a bit lighter workflow: 1. Everyone can merge their page - (it's a wiki) Same as with (public and open) code, no one has the motivation to publish a badly written wiki page under their name. True, it can have an impact, but not as with broken code 2. Use Page-Status marker The author first merges the draft. Its now out there and should be updated as time goes and its status is DRAFT. Maintainers will come later and after review would change the status to PUBLISH. That could be a header in on the page: --- page status: DRAFT/PUBLISH --- Simple I think, and should work.

14 23

engine upgrade 4.1.0 => 4.1.1, no more engine console available
by Nelson Lameiras 18 Jun '17

18 Jun '17

------=_Part_30901168_366908900.1490364694843 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,=20 When upgrading my test setup from 4.0 to 4.1, my engine vm lost it's consol= e (from SPICE to None in GUI)=20 My test setup :=20 2 manually built hosts using centos 7.3, ovirt 4.1=20 1 manually built hosted engine centos 7.3, oVirt 4.1.0.4-el7, accessible wi= th SPICE console via GUI=20 I updated ovirt-engine from 4.1.0 to 4.1.1 by doing on engine :=20 - yum update=20 - engine-setup=20 - reboot engine=20 When accessing 4.1.1 GUI, Graphics is set to "None" on "Virtual Machines" p= age, with "console button" greyed out (all other VMs have the same Graphics= set to the same value as before)=20 I tried to edit engine VM settings, and console options are same as before = (SPLICE, QXL).=20 I'm hopping this is not a new feature, since if we loose network on engine,= console is the only way to debug...=20 Is this a bug?=20 ps. I was able to reproduce this bug 2 times=20 cordialement, regards,=20 =09Nelson LAMEIRAS=20 Ing=C3=A9nieur Syst=C3=A8mes et R=C3=A9seaux / Systems and Networks enginee= r=20 Tel: +33 5 32 09 09 70=20 nelson.lameiras(a)lyra-network.com=20 www.lyra-network.com | www.payzen.eu=20 =09 =09 =09 Lyra Network, 109 rue de l'innovation, 31670 Lab=C3=A8ge, FRANCE=20 ------=_Part_30901168_366908900.1490364694843 Content-Type: multipart/related; boundary="----=_Part_30901169_712869510.1490364694843" ------=_Part_30901169_712869510.1490364694843 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s= ize: 12pt; color: #000000"><div data-marker=3D"__QUOTED_TEXT__"><div style= =3D"font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000= 000"><div>Hello,<br></div><div><br data-mce-bogus=3D"1"></div><div>When upg= rading my test setup from 4.0 to 4.1, my engine vm lost it's console (from = SPICE to None in GUI)<br data-mce-bogus=3D"1"></div><br><div>My test setup = :<br></div><div>2 manually built hosts using centos 7.3, ovirt 4.1<br></div= ><div>1 manually built hosted engine centos 7.3, oVirt 4.1.0.4-el7, accessi= ble with SPICE console via GUI<br></div><br><div>I updated ovirt-engine fro= m 4.1.0 to 4.1.1 by doing on engine :<br></div><div>- yum update<br></div><= div>- engine-setup<br></div><div>- reboot engine<br></div><br><div>When acc= essing 4.1.1 GUI, Graphics is set to "None" on "Virtual Machines" page, wit= h "console button" greyed out (all other VMs have the same Graphics set to = the same value as before)<br></div><div>I tried to edit engine VM settings,= and console options are same as before (SPLICE, QXL).<br></div><br><div>I'= m hopping this is not a new feature, since if we loose network on engine, c= onsole is the only way to debug...<br></div><div><br data-mce-bogus=3D"1"><= /div><div>Is this a bug?<br></div></div><div style=3D"font-family: arial, h= elvetica, sans-serif; font-size: 12pt; color: #000000"><br data-mce-bogus= =3D"1"></div><div style=3D"font-family: arial, helvetica, sans-serif; font-= size: 12pt; color: #000000">ps. I was able to reproduce this bug 2 times<br= data-mce-bogus=3D"1"></div><div style=3D"font-family: arial, helvetica, sa= ns-serif; font-size: 12pt; color: #000000"><br><div><div>cordialement, rega= rds,</div><br><table style=3D"margin: 0px; table-layout: fixed; border: non= e; width: 345pt; padding: 0px;" width=3D"460" cellspacing=3D"0" cellpadding= =3D"0" border=3D"0"><tbody><tr><td style=3D"margin: 0; font-size: 11px; fon= t-family: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 86.25= pt; text-align: left;" width=3D"115" valign=3D"top"><a href=3D"https://www.= lyra-network.com/" style=3D"border: none; text-decoration: none; width: 100= %; display: block; clear: both;" target=3D"_blank"><img src=3D"cid:6213d478= 56c2194cb43f7fbca7fede42d2bbb872@zimbra" alt=3D"" height=3D"94" width=3D"11= 5" border=3D"0"></a><br></td><td style=3D"margin: 0; font-size: 11px; font-= family: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 258.75p= t;" width=3D"345" valign=3D"top"><table style=3D"margin: 0; width: 258.75pt= ; table-layout: fixed; border: none;" width=3D"345" cellspacing=3D"0" cellp= adding=3D"0" border=3D"0"><tbody><tr><td style=3D"font-size: 16px; font-fam= ily: Arial,sans-serif; color: #2b3c7a; line-height: 18px; font-weight: bold= ;">Nelson LAMEIRAS</td></tr><tr><td style=3D"font-family: Arial,sans-serif;= color: #2b3c7a; font-size: 11px; line-height: 16px;">Ing=C3=A9nieur Syst= =C3=A8mes et R=C3=A9seaux<span style=3D"font-family: Arial,sans-serif; colo= r: #337ab7; font-size: 11px;"> / Systems and Networks engineer</span></td><= /tr><tr><td style=3D"line-height: 16px; font-family: 'Arial',sans-serif; co= lor: #2b3c7a; font-size: 11px;"><span style=3D"font-family: Arial,sans-seri= f; color: #2b3c7a; font-size: 11px;">Tel: +33 5 32 09 09 70</span></td></tr= ><tr><td style=3D"line-height: 16px; font-family: 'Arial',sans-serif; color= : #2b3c7a; font-size: 11px;"><a href=3D"mailto:nelson.lameiras@lyra-network= .com" style=3D"font-size: 11px; font-family: Arial,sans-serif; line-height:= 16px; text-decoration: none;" target=3D"_blank">nelson.lameiras@lyra-netwo= rk.com</a><br></td></tr><tr><td style=3D"line-height: 16px; font-family: 'A= rial',sans-serif; color: #2b3c7a; font-size: 11px;"><a href=3D"https://www.= lyra-network.com/" style=3D"font-size: 11px; font-family: Arial,sans-serif;= line-height: 16px; border: none; text-decoration: none;" target=3D"_blank"= >www.lyra-network.com</a> <a href=3D"https://payzen.eu" style=3D"font-size:= 11px; font-family: Arial,sans-serif; line-height: 16px; border: none; text= -decoration: none;" target=3D"_blank"> | www.payzen.eu</a><br></td></tr></t= body></table></td></tr></tbody></table><table style=3D"margin: 0; table-lay= out: fixed; border: none; width: 345pt;" width=3D"460" cellspacing=3D"0" ce= llpadding=3D"0"><tbody><tr><td style=3D"margin: 0; font-size: 11px; font-fa= mily: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 24pt; tex= t-align: left;" width=3D"32" valign=3D"top"><a href=3D"https://www.youtube.= com/channel/UCrVl1CO_Jlu3KbiRH-tQ_vA" style=3D"border: none; text-decoratio= n: none; margin: 0; float: left; display: inline-block; width: 32px;" targe= t=3D"_blank"><img src=3D"cid:fee0c7043a6ec1d238d7c1a097f03e711e4bdd56@zimbr= a" alt=3D"" height=3D"28" width=3D"32" border=3D"0"></a><br></td><td style= =3D"margin: 0; font-size: 11px; font-family: Arial,sans-serif; color: #2b3c= 7a; line-height: 16px; width: 30.75pt; text-align: left;" width=3D"41" vali= gn=3D"top"><a href=3D"https://www.linkedin.com/company/lyra-network_2" styl= e=3D"border: none; text-decoration: none; margin: 0; float: left; display: = inline-block; width: 41px;" target=3D"_blank"><img src=3D"cid:487e72d709dc9= 7cbbfa0b1ba96aee8060575054e@zimbra" height=3D"28" width=3D"41" border=3D"0"= ></a><br></td><td style=3D"margin: 0; font-size: 11px; font-family: Arial,s= ans-serif; color: #2b3c7a; line-height: 16px; width: 31.5pt; text-align: le= ft;" width=3D"42" valign=3D"top"><a href=3D"https://twitter.com/LyraNetwork= " style=3D"border: none; text-decoration: none; margin: 0; float: left; dis= play: inline-block; width: 42px;" target=3D"_blank"><img src=3D"cid:999ede1= ddc50a603985f40ccca2df8880b9ac139@zimbra" alt=3D"" height=3D"28" width=3D"4= 2" border=3D"0"></a><br></td><td style=3D"margin: 0; font-size: 11px; font-= family: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 258.75p= t; text-align: left;" width=3D"345" valign=3D"top"><a href=3D"https://payze= n.eu" style=3D"border: none; text-decoration: none; margin: 0; float: left;= display: inline-block; width: 61px;" target=3D"_blank"><img src=3D"cid:be5= 888ad89e097f78d6fcfb233cf1d8d4f6045db@zimbra" alt=3D"" height=3D"28" width= =3D"61" border=3D"0"></a><br></td></tr></tbody></table><table style=3D"marg= in: 0; table-layout: fixed; border: none; width: 345pt;" width=3D"460" cell= spacing=3D"0" cellpadding=3D"0"><tbody><tr><td><hr style=3D"background: #29= 3b79 none repeat scroll 0% 0%; width: 100%; height: 4px; color: #293b79; ma= rgin: 0px;"></td></tr></tbody></table><table style=3D"margin: 0; table-layo= ut: fixed; border: none; width: 345pt;" width=3D"460" cellspacing=3D"0" cel= lpadding=3D"0"><tbody><tr><td style=3D"margin: 0; font-size: 11px; font-fam= ily: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; t= ext-align: left;"><div>Lyra Network, 109 rue de l'innovation, 31670 Lab=C3= =A8ge, FRANCE</div></td></tr></tbody></table></div></div><br></div></div></= body></html> ------=_Part_30901169_712869510.1490364694843 Content-Type: image/jpeg; name=element-signature_logo_lyra_115x94.jpg Content-Disposition: attachment; filename=element-signature_logo_lyra_115x94.jpg Content-Transfer-Encoding: base64 Content-ID: <6213d47856c2194cb43f7fbca7fede42d2bbb872@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOkU1QUU4Nzk1OEExMzExRTZBNTFCRjVENEYyNDYxNTQ1IiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkU1QUU4Nzk0OEExMzExRTZBNTFCRjVENEYyNDYxNTQ1IiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIAF4AcwMBEQACEQEDEQH/xACdAAEBAAIDAQEAAAAAAAAAAAAACAUH AgMGBAEBAQADAQEAAAAAAAAAAAAAAAACBAUBAxAAAAUDAgAHDQcCBwAAAAAAAAECAwQRBQYSByFR E7RWFzcxQSKS0nOT03RVlQgYYXEyQiMUFYEzsVJicmODOBEAAgECAwcEAgIDAAAAAAAAAAECEQNR EwQhgbESMlIzMUGhFHEVwQUiQzT/2gAMAwEAAhEDEQA/AKpAE9b/AGQZdF3FtNpsd4l29M2DHSll iS6w0bzsp5slqJCiLvERnTuENTRQg7bckntK15vmojj1WfMP0rc+Jy/JD7Fjt+EMueJ6bbnBN4bR lkWdkt+XPtDaHSfjKnSHyUpTZkg+TcLSdFGRjyv3rUo0iqP8EoQkntZ7fcOy5VdrXGYxuccGW2+S 3nCecYq3oUWnU2RmfhGXAPPSXLcJNzVVT8kNVbnKKUHRmppW1/zBOSXVtZS4lpSjNtP8nLKhfcSR alqdPXp+ERhauKKTe38nX1WfMP0qc+Jy/JHPsWO34RPLniOqz5h+lTnxOX5IfYsdvwhlzxHVZ8w/ Spz4nL8kPsWO34Qy54jqs+YfpU58Tl+SH2LHb8IZc8R1WfMP0qc+Jy/JD7Fjt+EMueJ2bCX3MH9y LxZr7eJdxKBCkoW0/JdfaJ5mUy2a0EszL/MRHTuGGshDLTiqVf8AAst81GUGMssgAAAAE5b89s+L +zwefPDV0fhlv4FW71oo0ZRaAAAAAAAAAAAAACdtj+3DLfNXDn7I1dX4Y7uBWtdbKJGUWQAAAACc t+e2fF/Z4PPnhq6Pwy38Crd60UaMotAAAAAAAAAAAAABO2x/bhlvmrhz9kaur8Md3ArWutlEjKLI AAAABOW/PbPi/s8Hnzw1dH4Zb+BVu9aKNGUWjAKzrGk5cnEjkq/nVo5RMbk3NOnkzd/uU0fgKvdH rky5eb2I86rQz48iQAAAAAAAAABO2x/bhlvmrhz9kaur8Md3ArWutlEjKLIAAAABOW/PbPi/s8Hn zw1dH4Zb+BVu9aKNGUWjSD//AKkj+xnzJQ0V/wA2/wDkr/7D3e7GX5DiOMfzlniMTEMPIRORIJfg tOeCladCk/nNJH94raa1GcuVnpck4qqOrJdz4dr2yazKOhDjkxhlUGMszop98i/TOlD/AE/CNX+0 x23p27nIJXKRqeeyjdnLMd27sGSzLdEO4Xd4uWifqkhDDiFut0qrUSzQlNa9wz7g9bemjK44puiI yuNRTOzGs53hud+gvzsYjwMVnqNfLuqUTrEck69bitZmStPc1NJIz4hy5ZtKLpKskIzk36bDHRt2 9yMsuMw9v8ejybNBc5M5s5Rp5Uy4aEZuMJSai4dPCZFStBN6a3BLne1nMyT6Uffgu8GQ5DnysXuN mbtZx461TG1ms3kyGiLWRHXToMz8Hg7nfMQvaWMYcydTsLjcqG2BSPYnbY/twy3zVw5+yNXV+GO7 gVrXWyiRlFkAAAAAnLfntnxf2eDz54auj8Mt/Aq3etFGjKLROmdZbAxL5g/5yey6/GjREJW2wSTc M3YpoKms0F3VcY1bNpzscqKs5UnU9pad4cG3Fefw1UWXFO7x3mULkpaJJnoM6JNC10WREak/aXGK 8tLO1/ns2HorilsNTYzar/kOQWTa+5tmmBjk+W9cKGqimkrJS68RcCkoV/yC7clGMXcXrJI8Yptq OBsj5oEpTiNmSRESSuKSJJFwUJlzgoKv9f1P8Hrf9Db1wh/vbVJh6tH7lhbOvi5RBpr/AEqKMXR1 PZrYaC2x3Jgbawp+IZjBkwpkWS480603rSslkRU7qTOuiqFlUlEfepw6WosO61ODK9ufLsZ27f36 RkG/8q9OwXbe3PgKciMPp0uHHS22hpxRf60o1f4VC9DlsUrWjEHWdSghllknbY/twy3zVw5+yNXV +GO7gVrXWyiRlFkAAAAAnLfntnxf2eDz54auj8Mt/Aq3etFGjKLRxU00o6qQlR8ZkRhUGMyO7W7H 7FOvUpCSZgMrfMqERqNJeCgj41qokvtMTtxcpJL3OSdFU1n8vFimPwbrnF18O55DIXybhlw8ihZm s08RLdqVOJJC5rZqqgvSJ42V7v3MpM3dTBnyWbtBQmHFnXFpLzdXOWjW9tWo2irwPpd0pWhVPBPU R0qILTVWx+y+STuYmQj7sxHH1Kctb7NuahnMflKW2akk3J/bvGlojqtpv8ZuJP8ACR8Ag9M8dtTu YdErdfEJTCZKrY/L5JSySbrbCdKmicdWRLeWlJK/bs8skq+ElSacJ8HVppr3OZiP2RuxFK4W5xi3 LK2T5D8NmY8baHHnWySSeTSa6to1K8JTumn3gtM6PbtQzDYYqnqTtsf24Zb5q4c/ZGrq/DHdwK1r rZRIyiyAAAAATlvz2z4v7PB588NXR+GW/gVbvWijRlFoADGZHjVmyO2Ltd4YOTAcUlbjJLcbJRoO qam2pCuA+GlROFxwdV6nJRT2M+q226DbLfHt8BkmIcRtLMdlNaJQgqEVTqZ/eYjKTbqwlQ5Hb4Bp Uk4zRpUpa1FoTQ1uEaVqPg7qiUZGffDmYodSbNZ0toaTBjk02hbTaCaQSUtu/wBxCSpQkr/MXfHe d4iiP12z2h5k2XYMdxlSkuKbW0hSTW2kkIUZGVKpSkiI+8RApPEURydtltdQpDsRlxCtepKm0mR8 qdXKkZfn/NxjnMxQ+kcOk7bH9uGW+auHP2Rq6vwx3cCta62USMosgAAAAE5b89s+L+zwefPDV0fh lv4FW71oo0ZRaAAAAAAAAAAAAACdtj+3DLfNXDn7I1dX4Y7uBWtdbKJGUWQAAAACb9/3mWN4cbff WTTLUWEt1xX4UpTNeNSj+wiGtolW1LfwKt7qRuTrY226RwfSkKH1rnaz3zI4jrZ226RwfSkH1rna xmRxHWztt0jg+lIPrXO1jMjiOtnbbpHB9KQfWudrGZHEdbO23SOD6Ug+tc7WMyOJ+o3W24WtKE5F CUpR0SknCqZmH1rnazjuxW2pnbTfbPeGnHbXMamNtK0OLaVqJKjKtDELlqUNklQ7C5GfS6mOu+f4 XZpy4F0vMWHMbJKlsOrJKyJRVTUvtIdjZnJVSOuaXqfF1sbbdI4PpSEvrXO1nMyOJp7YiQxJ3oyi RHcS9Hejz3GXUcKVoVOZNKi+wyOovaxUsx3cDwtdbKNGUWgAAAADX+4GzGPZveWbtcpsuO+xGTFS iObRINCFrcIz1oWdaun3xas6qVtUSR5ztKTqeZ+lrCvely8Zj1Q9f2M8EQyEPpawr3pcvGY9UH7G eCGQh9LWFe9Ll4zHqg/YzwQyEPpawr3pcvGY9UH7GeCGQh9LWFe9Ll4zHqg/YzwQyEc2flfwxl5t 1NzuJqbUSiI1MUqX/UOr+xmn6I5LTRaaxNg4XhNuxOHIiwX3n0SXCdWb5pMyMk6eDSlPEPDU6mV5 pteg0+nVpNI8zm+xeNZfkDt7nzprEl5Dbam2FNEgibTpKmttR97jErWslCNEkTlaUnUwP0tYV70u XjMeqHp+xngiOQj023+zGPYReXrtbZsuQ+/GVFUiQbRoJC1ocMy0IQdatF3x5XtVK4qNInC0oups AVT0AAAAAAAAAAAAAAAAAAAAAAAAAAAAD//Z ------=_Part_30901169_712869510.1490364694843 Content-Type: image/jpeg; name=element-signature_logo_YouTube_32x28.jpg Content-Disposition: attachment; filename=element-signature_logo_YouTube_32x28.jpg Content-Transfer-Encoding: base64 Content-ID: <fee0c7043a6ec1d238d7c1a097f03e711e4bdd56@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOjQ1REY5Njk1OEExNzExRTY5OUVDOTI1QTU3QzAwNzI0IiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOjQ1REY5Njk0OEExNzExRTY5OUVDOTI1QTU3QzAwNzI0IiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAIAMBEQACEQEDEQH/xAB5AAADAQEAAAAAAAAAAAAAAAAABwgF BgEAAgMBAAAAAAAAAAAAAAAAAAQCAwUBEAABBAECBAUFAAAAAAAAAAABAgMEBQARBiESEwcxUdIU CEEik1UYEQACAQMCBQUAAAAAAAAAAAAAAQIRAwQhMVFhEiITQaHBYhX/2gAMAwEAAhEDEQA/AKpw AnD5Hbg3JA35XxKqxmxUPVrJEaI862FuqkPp4IbI5lHQDNXBhFwbaW4tebqcMIvfYjURtz6eesv1 YzWz9fYh38zR7eX2+mu5lHV3VhaNOe8aTJgTHnweVXEBba1cQRkb8IeNtJbHYN9WpW+YY2T53inQ 4HfzZk6a4lmHGaiOSHl8EoT7mSOZR+gBIzUxU3Yklz+Be4+9DRl30N3dMOxjbyro9EzHW3MqupHc L7qlaoX1SsFvlHl44moPpa6XXiW113FPuu3qrT5I7dfrJLUxllMRl15hQWjqBbiuXmTqCQlQx23F rHdSqTrNFFZlDAou7vZa43xuSNaw7CPFZZhIiKbeSsqKkOuuE/aCNNHcexspW40a9Sm5bcmcH/J1 5+0rvxOenGf0o8GQ8DN7ZXxzv9vbpqrhy0huMQJCHlstocBKU+ITqANcru50ZRao9SUbLTqPvMwv DAAwAMAP/9k= ------=_Part_30901169_712869510.1490364694843 Content-Type: image/jpeg; name=element-signature_logo_LinkedIn_41x28.jpg Content-Disposition: attachment; filename=element-signature_logo_LinkedIn_41x28.jpg Content-Transfer-Encoding: base64 Content-ID: <487e72d709dc97cbbfa0b1ba96aee8060575054e@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOjY2MEYzRTFGOEExNzExRTY5QzI5OUNGQkY1MzM2MUQ1IiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOjY2MEYzRTFFOEExNzExRTY5QzI5OUNGQkY1MzM2MUQ1IiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAKQMBEQACEQEDEQH/xAB2AAEBAQEAAAAAAAAAAAAAAAAABggH AQEAAwEAAAAAAAAAAAAAAAAAAwQFAhAAAQMEAgICAgMBAAAAAAAAAQIDBAARBQYhEjEHMghBE1Fh IhcRAAICAQIDCQAAAAAAAAAAAAABAgMREgQxkTIhQVGhscETMxX/2gAMAwEAAhEDEQA/ANU0Bl33 zsuzQfZcmHj8tMiMKaihDLMl1psKcQkXslSUjk8mtjZ1xdeWkVbW9RDZ/ZN8wOXkYnI7LKMuL1Lq o+RddaIWkLHVwLAPCuf4NWYVwksqPkcNtd5V+ldr2ef7MwkaZmJsqK6p/uy9JdcbUBGcULpUog8i 9Q7uuKreEjquT1GsKxC2KAUBk37B2/6y72t1tB7X8dbIvf8Aq3mtvZfVzKlvUWWw7Dr+Dfy8rCt4 d153Z8ew0FNx3kohuxmUyFtAfFPyBUOBz+arwhKWE89L9SRtLmTuns4xj7LLaxYaGNE6SYojlJZ6 rhLUf19f89eyj4qa1t7ft449ziPWairGLQoBQHFvZ/onObht0jNxclFjMPNtNpZdS4Vj9aAk36gj mtDb7yMIaWiGdTbySSfqnsKbdctAFh1Fm3Bwfx8fFT/ox8GcfAyk9dfX7OapuGNzj+SiPRoJcKmG kuBRDjS2x1uAPK71DfvYzg444nUKmnk7lWcTigFAKAUAoBQCgP/Z ------=_Part_30901169_712869510.1490364694843 Content-Type: image/jpeg; name=element-signature_logo_Twitter_42x28.jpg Content-Disposition: attachment; filename=element-signature_logo_Twitter_42x28.jpg Content-Transfer-Encoding: base64 Content-ID: <999ede1ddc50a603985f40ccca2df8880b9ac139@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOjdDMkI3MjMyOEExNzExRTY5MDUyRTk1NEIyREUwNjVCIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOjdDMkI3MjMxOEExNzExRTY5MDUyRTk1NEIyREUwNjVCIiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAKgMBEQACEQEDEQH/xAB3AAEBAQEBAAAAAAAAAAAAAAAABwUI BgEBAAMBAQAAAAAAAAAAAAAAAAMEBQIBEAABAwIEBwEBAQAAAAAAAAABAgMEAAUREhMGITFBFBUH CIEiFhEAAgIBAgQHAAAAAAAAAAAAAAERAgMxBCHBEgVBUWGBQhMV/9oADAMBAAIRAxEAPwDC9g7u 3dH33uJiNeri2wxcJQQ01JfCUNodVwCUqwSlI/AK3sGKropS0Kd7OWZMXcPsyZDdnQ7he5UFhQQ/ LZelOMoURiEqWlRAOFdumNOGqyeTYtPzFfL1df8ASm5XCTP0ey0e5eceyZu4zZc5VhjlGOFZ/cKJ dMKNeRNhbclzrOJxQCgOSW7o5a/oKXMRFXNT5iYw/EaAUtbL61tOBKTwXglWOXrW30zgj0RUmLlb 9p3rZ/r/ANd3GxWJtm3XC8B1EO2RsEqDkng88pAP8JSnEk8ugqlt6Xy5Fa3FImyNVUI8z8nJCU7o SOSRAA/O5qbuXx9+Rxg8ToGsssCgFAc/7q+b9xXrc11u7V3iNN3CW/JbQUuhaUuuFYBIHMA9K08e +rWqUPgivbC25MofK25Qoq81DKjwKlJeUT+kE13+jXyZ59DKX6a9WXPYfmO+msTPJdtp6AWMuhq4 5swHPVFVN1uFkiFoS46dJSqqEgoBQCgFAKAUAoBQH//Z ------=_Part_30901169_712869510.1490364694843 Content-Type: image/jpeg; name=element-signature_payzen_61x28.jpg Content-Disposition: attachment; filename=element-signature_payzen_61x28.jpg Content-Transfer-Encoding: base64 Content-ID: <be5888ad89e097f78d6fcfb233cf1d8d4f6045db@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOkU1NjczQjM2OEEzNDExRTZCOEJBQ0Y4Mzg3RTEzODkyIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkU1NjczQjM1OEEzNDExRTZCOEJBQ0Y4Mzg3RTEzODkyIiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAPQMBEQACEQEDEQH/xABvAAABBAMAAAAAAAAAAAAAAAAAAQUG BwIDBAEBAAAAAAAAAAAAAAAAAAAAABAAAQQABAQEAgsBAAAAAAAAAQIDBAUAERIGITETFEEiFQfS I1FhcYGhMlIkRMQWhhEBAAAAAAAAAAAAAAAAAAAAAP/aAAwDAQACEQMRAD8AvqZ7q7OhzZMSS9IQ Yjy2JT/avqZbW2rSvU6lBSACOeeAljLzTzSHmVhxpxIW24k5pUlQzBBHgRgM8BBJ9fKuvcGwr3La wgxIlfGeaagyVsJ1uOOBRUBmOSRgI0bnZgfQwdx7qDrroYZSVzBrcJ0hKM2xq+7AWBU7PTXTEShc 2svRx6MuWp5o5gjigj68BombFRKmPyTfXTPXWpzoszloaRqOelCQPKkeAwEP6lp6f6V6vYaP9Z6b 3fcr7ntuhno6vPnxwGyohb2ntbpr6Y17NdKt7Bp5+YHlPJLitKyltI0KGk+XPANVgzV1Eyyqbe3s IMmnhsMbVaYcebDraY+XVbQ15XXFOghQVnkMBkbjcVPTUs6M5IkPbnpWa1hKlrWG7QZBp0hROnUh xRUfHTgJDWuwtsbptVTpC1xaqhgJfkuFTji9DjoKiTmpSlq/HAcO2d11d/cuXUySJG4C0+NvbfCH CmK2hClHUop0GQ6E+dWfAeUYBi2lY2E+zgW7twhVlHDk+7AkzFO9u2lRdjORFIEZrTmAkA+GYwDl TwLJhjZFouxsF3NzN6r7Lj7imExHUOSHWi0TpyCdORIzzwHT/J/7n+vgLVAA5YBChBUlRSCpOelR HEZ88sA2WG3YVhb1lnJW4VVJcXFjAgM9VxOjqKTlmVJTnp48M8Ax2+3N3J3TJu6KVAbRKisxnWpr brh+SpasxoKf14BBD91hxE2kB+nt5Px4AEL3VGoiZSAr4qyjyOP2+fAL2nuvw/e0vDl8iT8eAbv8 Lur0vPvYXrPrfrfU6bvb59Lp6NOev83HngLBwBgDAGAMAYAwBgP/2Q== ------=_Part_30901169_712869510.1490364694843-- ------=_Part_30901168_366908900.1490364694843--

10 46

Timeout for Hosts
by Sven Achtelik 29 May '17

29 May '17

--_000_BFAB40933B3367488CE6299BAF8592D1014E52CC4584SOCRATESasl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have 2 hosts which are at remote locations where the ISP is forcing a con= nection reset after some days. During that reset the connection will be dow= n for at most 2 minutes and the engine starts to complain about the hosts n= ot being reachable. What is the right value to tweak to compensate this ? Is it on of these: TimeoutToResetVdsInSeconds, VdsRefreshRate, vdsTimeout ?= And is it possible to only apply this for a certain cluster or DC or is it= global ? Thank you, Sven --_000_BFAB40933B3367488CE6299BAF8592D1014E52CC4584SOCRATESasl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 15 (filtered medium)"><style></style></head><body lang=3DDE link=3D"#0563C1" v= link=3D"#954F72"><div class=3DWordSection1><p class=3DMsoNormal>Hi All, <o:= p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>= <span lang=3DEN-US>I have 2 hosts which are at remote locations where the I= SP is forcing a connection reset after some days. During that reset the con= nection will be down for at most 2 minutes and the engine starts to complai= n about the hosts not being reachable. What is the right value to tweak to = compensate this ? <o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DE= N-US>Is it on of these: TimeoutToResetVdsInSeconds, VdsRefreshRate, vdsTime= out ? And is it possible to only apply this for a certain cluster or DC or = is it global ? <o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-U= S style=3D'mso-fareast-language:DE'><o:p> </o:p></span></p><p class=3D= MsoNormal><span lang=3DEN-US style=3D'mso-fareast-language:DE'>Thank you, <= o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US style=3D'mso-f= areast-language:DE'><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US style=3D'mso-fareast-language:DE'>Sven </span><o:p></o:p></p><= /div></body></html>= --_000_BFAB40933B3367488CE6299BAF8592D1014E52CC4584SOCRATESasl_--

3 8

Building ovirt-host-deploy gives `configure: error: otopi-devtools required but missing`
by Leni Kadali Mutungi 19 May '17

19 May '17

Hello. I got the error mentioned in the subject when when trying to build ovirt-host-deploy. Full output here: https://paste.fedoraproject.org/paste/Dh7FF1XjhDa2TGNSBs~o815M1UNdIGYhyRLiv… The troubleshooting I've done so far is as follows: 1. Rebuilt otopi, running the commands `autoreconf -ivf` and then `./configure --enable-java-sdk --with-maven`. This made `make` download a host of stuff for otopi project from https://repo.maven.apache.org It did this again when I ran `make install`. When I went back to the ovirt-host-deploy directory, I ran `./configure`, both with the --enable-java-sdk and --with-maven options. Got the same error again. 2. I tried running entering the directory src/java and running `mvn install`. I received a build success message and then proceeded to run ./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --disable-python-syntax-check --enable-java-sdk --with-local-version=otopi-1.7.0.master COMMONS_LOGGING_JAR=/usr/share/java/commons-logging.jar JUNIT_JAR=/usr/share/java/junit.jar I omitted the --disable-dependency-tracking and --docdir=/usr/share/doc/otopi-1.7.0 options because of the following error: configure: WARNING: unrecognized options: --disable-dependency-tracking and the fact that I didn't have the directory /usr/share/doc/otopi-1.7.0 respectively. I got the following output: https://paste.fedoraproject.org/paste/90D0k1AyVPGDbNhk1WxlBl5M1UNdIGYhyRLiv… Running `sudo make install` gives me the same errors. It seems otopi is failing to compile properly and as a result, running ./configure within the ovirt-host-deploy directory ends with an error saying otopi-devtools are missing. Documentation of my environment as it stands is here: https://github.com/leni1/oVirt-docs-Debian/blob/master/oVirt-Development-En… Any ideas on what I should try next are welcome. -- - Warm regards Leni Kadali Mutungi

6 14

Upgrade 4.0.6 to 4.1.1 -- How to Update oVirt Node (4.x) Hosts?
by Beckman, Daniel 09 May '17

09 May '17

--_000_99294B0B51BA4CA6B4F3169AC046B619ingramcontentcom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 U28gSSBzdWNjZXNzZnVsbHkgdXBncmFkZWQgbXkgZW5naW5lIGZyb20gNC4wNiB0byA0LjEuMSB3 aXRoIG5vIG1ham9yIGlzc3Vlcy4NCg0KQSBuaWNlIHRoaW5nIEkgbm90aWNlZCB3YXMgdGhhdCBt eSBjdXN0b20gQ0EgY2VydGlmaWNhdGUgZm9yIGh0dHBzIG9uIHRoZSBhZG1pbiBhbmQgdXNlciBw b3J0YWxzIHdhc27igJl0IGNsb2JiZXJlZCBieSBzZXR1cC4NCg0KSSBkaWQgaGF2ZSB0byByZXN0 b3JlIG15IGN1c3RvbSBzZXR0aW5ncyBmb3IgSVNPIHVwbG9hZGVyLCBsb2cgY29sbGVjdG9yLCBh bmQgd2Vic29ja2V0IHByb3h5Og0KY3AgL2V0Yy9vdmlydC1lbmdpbmUvaXNvdXBsb2FkZXIuY29u Zi5kLzEwLWVuZ2luZS1zZXR1cC5jb25mLjxsYXRlc3RfdGltZXN0YW1wPiAvZXRjL292aXJ0LWVu Z2luZS9pc291cGxvYWRlci5jb25mLmQvMTAtZW5naW5lLXNldHVwLmNvbmYNCmNwIC9ldGMvb3Zp cnQtZW5naW5lL292aXJ0LXdlYnNvY2tldC1wcm94eS5jb25mLmQvMTAtc2V0dXAuY29uZi48bGF0 ZXN0X3RpbWVzdGFtcD4gL2V0Yy9vdmlydC1lbmdpbmUvb3ZpcnQtd2Vic29ja2V0LXByb3h5LmNv bmYuZC8xMC1zZXR1cC5jb25mDQpjcCAvZXRjL292aXJ0LWVuZ2luZS9sb2djb2xsZWN0b3IuY29u Zi5kLzEwLWVuZ2luZS1zZXR1cC5jb25mLjxsYXRlc3RfdGltZXN0YW1wPiAvZXRjL292aXJ0LWVu Z2luZS9sb2djb2xsZWN0b3IuY29uZi5kLzEwLWVuZ2luZS1zZXR1cC5jb25mDQoNCk5vdyBJ4oCZ bSBtb3Zpbmcgb24gdG8gdXBkYXRpbmcgdGhlIG9WaXJ0IG5vZGUgaG9zdHMsIHdoaWNoIGFyZSBj dXJyZW50bHkgYXQgb1ZpcnQgTm9kZSA0LjAuNi4xLiAoSeKAmW0gYXNzdW1pbmcgSSBzaG91bGQg ZG8gdGhhdCBiZWZvcmUgYXR0ZW1wdGluZyB0byB1cGdyYWRlIHRoZSBjbHVzdGVyIGFuZCBkYXRh IGNlbnRlciBjb21wYXRpYmlsaXR5IGxldmVsIHRvIDQuMS4pDQoNCldoZW4gSSByaWdodC1jbGlj ayBvbiBhIGhvc3QgYW5kIGdvIHRvIEluc3RhbGxhdGlvbiAvIENoZWNrIGZvciBVcGdyYWRlLCB0 aGUgcmVzdWx0cyBhcmUg4oCYbm8gdXBkYXRlcyBmb3VuZC7igJkgV2hlbiBJIGxvZyBpbnRvIHRo YXQgaG9zdCBkaXJlY3RseSwgSSBub3RpY2UgaXTigJlzIHN0aWxsIGdvdCB0aGUgb1ZpcnQgNC4w IHJlcG8sIG5vdCA0LjEuIElzIHRoZXJlIGFuIGV4dHJhIHN0ZXAgSeKAmW0gbWlzc2luZz8gVGhl IGRvY3VtZW50YXRpb24gSeKAmXZlIGZvdW5kIChodHRwOi8vd3d3Lm92aXJ0Lm9yZy9kb2N1bWVu dGF0aW9uL3VwZ3JhZGUtZ3VpZGUvY2hhcC1VcGRhdGVzX2JldHdlZW5fTWlub3JfUmVsZWFzZXMv KSBkb2VzbuKAmXQgbWVudGlvbiB0aGlzLg0KDQoNCioqDQpJZiBJIGNhbiBvZmZlciBzb21lIHVu c29saWNpdGVkIGZlZWRiYWNrOiBJIGZlZWwgbGlrZSB0aGlzIGxpc3QgaXMgcG9wdWxhdGVkIHdp dGggYSBsb3Qgb2YgcXVlc3Rpb25zIHRoYXQgY291bGQgYmUgYXZlcnRlZCB3aXRoIGEgbGl0dGxl IGNhcmUgYW5kIGZlZWRpbmcgb2YgdGhlIGRvY3VtZW50YXRpb24uIEl04oCZcyB1bmZvcnR1bmF0 ZSBiZWNhdXNlIHRoYXQgbWFrZXMgZm9yIGEgcm9ja3kgaW50cm9kdWN0aW9uIHRvIG9WaXJ0LCBh bmQgaXQgbWFrZXMgaXQgbG9vayBsaWtlIGEgbmVnbGVjdGVkIHByb2plY3QsIHdoaWNoIEkga25v dyBpcyBub3QgdGhlIGNhc2UuDQoNCk9uIGEgcmVsYXRlZCBub3RlLCBJIGtub3cgdGhpcyBoYXMg YmVlbiBkaXNjdXNzZWQgYmVmb3JlIGJ1dOKApg0KVGhlIGNlbnRyYWxpemVkIGNvbnRyb2wgaW4g R2l0aHViIGZvciB0aGUgZG9jdW1lbnRhdGlvbiBkb2VzIG5vdCByZWFsbHkgZW5jb3VyYWdlIHVz ZXIgY29udHJpYnV0aW9ucy4gV2hhdOKAmXMgd3Jvbmcgd2l0aCBhIHdpa2k/IElmIHdl4oCZcmUg cmVhbGx5IGNvbmNlcm5lZCBhYm91dCBiYWQgb3IgbWFsaWNpb3VzIGVkaXRzIGJlaW5nIHBvc3Rl ZCwga2VlcCB0aGUgb2ZmaWNpYWwgaW4gZ2l0IGFuZCBhZGQgYSBzZXBhcmF0ZSB3aWtpIHRoYXQg aXMgY2xlYXJseSBtYXJrZWQgYXMgdXNlci1jb250cmlidXRlZC4NCioqDQoNCg0KVGhhbmtzLA0K RGFuaWVsDQo= --_000_99294B0B51BA4CA6B4F3169AC046B619ingramcontentcom_ Content-Type: text/html; charset=UTF-8 Content-ID: <A36A61E118072E419909BC293B56461B(a)namprd12.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNv IEkgc3VjY2Vzc2Z1bGx5IHVwZ3JhZGVkIG15IGVuZ2luZSBmcm9tIDQuMDYgdG8gNC4xLjEgd2l0 aCBubyBtYWpvciBpc3N1ZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkEgbmljZSB0aGluZyBJIG5vdGljZWQgd2FzIHRoYXQgbXkgY3VzdG9tIENBIGNlcnRp ZmljYXRlIGZvciBodHRwcyBvbiB0aGUgYWRtaW4gYW5kIHVzZXIgcG9ydGFscyB3YXNu4oCZdCBj bG9iYmVyZWQgYnkgc2V0dXAuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkkgZGlkIGhhdmUgdG8gcmVzdG9yZSBteSBjdXN0b20gc2V0dGluZ3MgZm9yIElTTyB1 cGxvYWRlciwgbG9nIGNvbGxlY3RvciwgYW5kIHdlYnNvY2tldCBwcm94eTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Y3AmbmJzcDsvZXRjL292aXJ0LWVuZ2luZS9pc291cGxvYWRlci5jb25mLmQvMTAtZW5n aW5lLXNldHVwLmNvbmYuJmx0O2xhdGVzdF90aW1lc3RhbXAmZ3Q7IC9ldGMvb3ZpcnQtZW5naW5l L2lzb3VwbG9hZGVyLmNvbmYuZC8xMC1lbmdpbmUtc2V0dXAuY29uZjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5jcCZuYnNwOy9ldGMvb3ZpcnQtZW5naW5lL292aXJ0LXdlYnNvY2tldC1wcm94eS5jb25mLmQv MTAtc2V0dXAuY29uZi4mbHQ7bGF0ZXN0X3RpbWVzdGFtcCZndDsgL2V0Yy9vdmlydC1lbmdpbmUv b3ZpcnQtd2Vic29ja2V0LXByb3h5LmNvbmYuZC8xMC1zZXR1cC5jb25mPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPmNwJm5ic3A7L2V0Yy9vdmlydC1lbmdpbmUvbG9nY29sbGVjdG9yLmNvbmYuZC8xMC1lbmdp bmUtc2V0dXAuY29uZi4mbHQ7bGF0ZXN0X3RpbWVzdGFtcCZndDsgL2V0Yy9vdmlydC1lbmdpbmUv bG9nY29sbGVjdG9yLmNvbmYuZC8xMC1lbmdpbmUtc2V0dXAuY29uZjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Tm93IEnigJltIG1vdmluZyBvbiB0byB1cGRhdGlu ZyB0aGUgb1ZpcnQgbm9kZSBob3N0cywgd2hpY2ggYXJlIGN1cnJlbnRseSBhdCBvVmlydCBOb2Rl IDQuMC42LjEuIChJ4oCZbSBhc3N1bWluZyBJIHNob3VsZCBkbyB0aGF0IGJlZm9yZSBhdHRlbXB0 aW5nIHRvIHVwZ3JhZGUgdGhlIGNsdXN0ZXIgYW5kIGRhdGEgY2VudGVyIGNvbXBhdGliaWxpdHkg bGV2ZWwgdG8NCiA0LjEuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+V2hlbiBJIHJpZ2h0LWNsaWNrIG9uIGEgaG9zdCBhbmQgZ28gdG8gSW5zdGFsbGF0aW9uIC8g Q2hlY2sgZm9yIFVwZ3JhZGUsIHRoZSByZXN1bHRzIGFyZSDigJhubyB1cGRhdGVzIGZvdW5kLuKA mSBXaGVuIEkgbG9nIGludG8gdGhhdCBob3N0IGRpcmVjdGx5LCBJIG5vdGljZSBpdOKAmXMgc3Rp bGwgZ290IHRoZSBvVmlydCA0LjAgcmVwbywgbm90IDQuMS4gSXMgdGhlcmUNCiBhbiBleHRyYSBz dGVwIEnigJltIG1pc3Npbmc/IFRoZSBkb2N1bWVudGF0aW9uIEnigJl2ZSBmb3VuZCAoPGEgaHJl Zj0iaHR0cDovL3d3dy5vdmlydC5vcmcvZG9jdW1lbnRhdGlvbi91cGdyYWRlLWd1aWRlL2NoYXAt VXBkYXRlc19iZXR3ZWVuX01pbm9yX1JlbGVhc2VzLykiPmh0dHA6Ly93d3cub3ZpcnQub3JnL2Rv Y3VtZW50YXRpb24vdXBncmFkZS1ndWlkZS9jaGFwLVVwZGF0ZXNfYmV0d2Vlbl9NaW5vcl9SZWxl YXNlcy8pPC9hPiBkb2VzbuKAmXQgbWVudGlvbg0KIHRoaXMuIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPioqPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPklmIEkgY2FuIG9mZmVyIHNvbWUgdW5zb2xpY2l0ZWQgZmVlZGJhY2s6IEkg ZmVlbCBsaWtlIHRoaXMgbGlzdCBpcyBwb3B1bGF0ZWQgd2l0aCBhIGxvdCBvZiBxdWVzdGlvbnMg dGhhdCBjb3VsZCBiZSBhdmVydGVkIHdpdGggYSBsaXR0bGUgY2FyZSBhbmQgZmVlZGluZyBvZiB0 aGUgZG9jdW1lbnRhdGlvbi4gSXTigJlzIHVuZm9ydHVuYXRlIGJlY2F1c2UgdGhhdA0KIG1ha2Vz IGZvciBhIHJvY2t5IGludHJvZHVjdGlvbiB0byBvVmlydCwgYW5kIGl0IG1ha2VzIGl0IGxvb2sg bGlrZSBhIG5lZ2xlY3RlZCBwcm9qZWN0LCB3aGljaCBJIGtub3cgaXMgbm90IHRoZSBjYXNlLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5PbiBhIHJlbGF0ZWQg bm90ZSwgSSBrbm93IHRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZSBidXTigKY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+VGhlIGNlbnRyYWxpemVkIGNvbnRyb2wgaW4gR2l0aHViIGZvciB0aGUgZG9j dW1lbnRhdGlvbiBkb2VzIG5vdCByZWFsbHkgZW5jb3VyYWdlIHVzZXIgY29udHJpYnV0aW9ucy4g V2hhdOKAmXMgd3Jvbmcgd2l0aCBhIHdpa2k/IElmIHdl4oCZcmUgcmVhbGx5IGNvbmNlcm5lZCBh Ym91dCBiYWQgb3IgbWFsaWNpb3VzIGVkaXRzIGJlaW5nIHBvc3RlZCwga2VlcCB0aGUNCiBvZmZp Y2lhbCBpbiBnaXQgYW5kIGFkZCBhIHNlcGFyYXRlIHdpa2kgdGhhdCBpcyBjbGVhcmx5IG1hcmtl ZCBhcyB1c2VyLWNvbnRyaWJ1dGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4qKjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGFuaWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_99294B0B51BA4CA6B4F3169AC046B619ingramcontentcom_--

3 19

Hosted engine FCP SAN can not activate data domain
by Jens Oechsler 09 May '17

09 May '17

Hello I have a problem with oVirt Hosted Engine Setup version: 4.0.5.5-1.el7.centos. Setup is using FCP SAN for data and engine. Cluster has worked fine for a while. It has two hosts with VMs running. I extended storage with an additional LUN recently. This LUN seems to be gone from data domain and one VM is paused which I assume has data on that device. Got these errors in events: Apr 24, 2017 10:26:05 AM Failed to activate Storage Domain SD (Data Center DC) by admin@internal-authz Apr 10, 2017 3:38:08 PM Status of host cl01 was set to Up. Apr 10, 2017 3:38:03 PM Host cl01 does not enforce SELinux. Current status: DISABLED Apr 10, 2017 3:37:58 PM Host cl01 is initializing. Message: Recovering from crash or Initializing Apr 10, 2017 3:37:58 PM VDSM cl01 command failed: Recovering from crash or Initializing Apr 10, 2017 3:37:46 PM Failed to Reconstruct Master Domain for Data Center DC. Apr 10, 2017 3:37:46 PM Host cl01 is not responding. Host cannot be fenced automatically because power management for the host is disabled. Apr 10, 2017 3:37:46 PM VDSM cl01 command failed: Broken pipe Apr 10, 2017 3:37:46 PM VDSM cl01 command failed: Broken pipe Apr 10, 2017 3:32:45 PM Invalid status on Data Center DC. Setting Data Center status to Non Responsive (On host cl01, Error: General Exception). Apr 10, 2017 3:32:45 PM VDSM cl01 command failed: [Errno 19] Could not find dm device named `[unknown]` Apr 7, 2017 1:28:04 PM VM HostedEngine is down with error. Exit message: resource busy: Failed to acquire lock: error -243. Apr 7, 2017 1:28:02 PM Storage Pool Manager runs on Host cl01 (Address: cl01). Apr 7, 2017 1:27:59 PM Invalid status on Data Center DC. Setting status to Non Responsive. Apr 7, 2017 1:27:53 PM Host cl02 does not enforce SELinux. Current status: DISABLED Apr 7, 2017 1:27:52 PM Host cl01 does not enforce SELinux. Current status: DISABLED Apr 7, 2017 1:27:49 PM Affinity Rules Enforcement Manager started. Apr 7, 2017 1:27:34 PM ETL Service Started Apr 7, 2017 1:26:01 PM ETL Service Stopped Apr 3, 2017 1:22:54 PM Shutdown of VM HostedEngine failed. Apr 3, 2017 1:22:52 PM Storage Pool Manager runs on Host cl01 (Address: cl01). Apr 3, 2017 1:22:49 PM Invalid status on Data Center DC. Setting status to Non Responsive. Master data domain is inactive. vdsm.log: jsonrpc.Executor/5::INFO::2017-04-20 07:01:26,796::lvm::1226::Storage.LVM::(activateLVs) Refreshing lvs: vg=bd616961-6da7-4eb0-939e-330b0a3fea6e lvs=['ids'] jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:26,796::lvm::288::Storage.Misc.excCmd::(cmd) /usr/bin/taskset --cpu-list 0-39 /usr/bin/sudo -n /usr/sbin/lvm lvchange --config ' devices { preferred_names = ["^/dev/mapper/"] ignore_suspended_d evices=1 write_cache_state=0 disable_after_error_count=3 filter = [ '\''a|/dev/mapper/360050768018182b6c00000000000099e|[unknown]|'\'', '\''r|.*|'\'' ] } global { locking_type=1 prioritise_write_locks=1 wait_for_locks=1 use_lvmetad= 0 } backup { retain_min = 50 retain_days = 0 } ' --refresh bd616961-6da7-4eb0-939e-330b0a3fea6e/ids (cwd None) jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:26,880::lvm::288::Storage.Misc.excCmd::(cmd) SUCCESS: <err> = " WARNING: Not using lvmetad because config setting use_lvmetad=0.\n WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).\n Couldn't find device with uuid jDB9VW-bNqY-UIKc-XxXp-xnyK-ZTlt-7Cpa1U.\n"; <rc> = 0 jsonrpc.Executor/5::INFO::2017-04-20 07:01:26,881::lvm::1226::Storage.LVM::(activateLVs) Refreshing lvs: vg=bd616961-6da7-4eb0-939e-330b0a3fea6e lvs=['leases'] jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:26,881::lvm::288::Storage.Misc.excCmd::(cmd) /usr/bin/taskset --cpu-list 0-39 /usr/bin/sudo -n /usr/sbin/lvm lvchange --config ' devices { preferred_names = ["^/dev/mapper/"] ignore_suspended_d evices=1 write_cache_state=0 disable_after_error_count=3 filter = [ '\''a|/dev/mapper/360050768018182b6c00000000000099e|[unknown]|'\'', '\''r|.*|'\'' ] } global { locking_type=1 prioritise_write_locks=1 wait_for_locks=1 use_lvmetad= 0 } backup { retain_min = 50 retain_days = 0 } ' --refresh bd616961-6da7-4eb0-939e-330b0a3fea6e/leases (cwd None) jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:26,973::lvm::288::Storage.Misc.excCmd::(cmd) SUCCESS: <err> = " WARNING: Not using lvmetad because config setting use_lvmetad=0.\n WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).\n Couldn't find device with uuid jDB9VW-bNqY-UIKc-XxXp-xnyK-ZTlt-7Cpa1U.\n"; <rc> = 0 jsonrpc.Executor/5::INFO::2017-04-20 07:01:26,973::lvm::1226::Storage.LVM::(activateLVs) Refreshing lvs: vg=bd616961-6da7-4eb0-939e-330b0a3fea6e lvs=['metadata', 'leases', 'ids', 'inbox', 'outbox', 'master'] jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:26,974::lvm::288::Storage.Misc.excCmd::(cmd) /usr/bin/taskset --cpu-list 0-39 /usr/bin/sudo -n /usr/sbin/lvm lvchange --config ' devices { preferred_names = ["^/dev/mapper/"] ignore_suspended_d evices=1 write_cache_state=0 disable_after_error_count=3 filter = [ '\''a|/dev/mapper/360050768018182b6c00000000000099e|[unknown]|'\'', '\''r|.*|'\'' ] } global { locking_type=1 prioritise_write_locks=1 wait_for_locks=1 use_lvmetad= 0 } backup { retain_min = 50 retain_days = 0 } ' --refresh bd616961-6da7-4eb0-939e-330b0a3fea6e/metadata bd616961-6da7-4eb0-939e-330b0a3fea6e/leases bd616961-6da7-4eb0-939e-330b0a3fea6e/ids bd616961-6da7-4eb0-939e-330b0a3fea6e/inbox b d616961-6da7-4eb0-939e-330b0a3fea6e/outbox bd616961-6da7-4eb0-939e-330b0a3fea6e/master (cwd None) Reactor thread::INFO::2017-04-20 07:01:27,069::protocoldetector::72::ProtocolDetector.AcceptorImpl::(handle_accept) Accepting connection from ::1:44692 jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:27,070::lvm::288::Storage.Misc.excCmd::(cmd) SUCCESS: <err> = " WARNING: Not using lvmetad because config setting use_lvmetad=0.\n WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).\n Couldn't find device with uuid jDB9VW-bNqY-UIKc-XxXp-xnyK-ZTlt-7Cpa1U.\n"; <rc> = 0 jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:27,070::sp::662::Storage.StoragePool::(_stopWatchingDomainsState) Stop watching domains state jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:27,070::resourceManager::628::Storage.ResourceManager::(releaseResource) Trying to release resource 'Storage.58493e81-01dc-01d8-0390-000000000032' jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:27,071::resourceManager::647::Storage.ResourceManager::(releaseResource) Released resource 'Storage.58493e81-01dc-01d8-0390-000000000032' (0 active users) jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:27,071::resourceManager::653::Storage.ResourceManager::(releaseResource) Resource 'Storage.58493e81-01dc-01d8-0390-000000000032' is free, finding out if anyone is waiting for it. jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:27,071::resourceManager::661::Storage.ResourceManager::(releaseResource) No one is waiting for resource 'Storage.58493e81-01dc-01d8-0390-000000000032', Clearing records. jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:27,071::resourceManager::628::Storage.ResourceManager::(releaseResource) Trying to release resource 'Storage.HsmDomainMonitorLock' jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:27,071::resourceManager::647::Storage.ResourceManager::(releaseResource) Released resource 'Storage.HsmDomainMonitorLock' (0 active users) jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:27,071::resourceManager::653::Storage.ResourceManager::(releaseResource) Resource 'Storage.HsmDomainMonitorLock' is free, finding out if anyone is waiting for it. jsonrpc.Executor/5::DEBUG::2017-04-20 07:01:27,071::resourceManager::661::Storage.ResourceManager::(releaseResource) No one is waiting for resource 'Storage.HsmDomainMonitorLock', Clearing records. jsonrpc.Executor/5::ERROR::2017-04-20 07:01:27,072::task::868::Storage.TaskManager.Task::(_setError) Task=`15122a21-4fb7-45bf-9a9a-4b97f27bc1e1`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 875, in _run return fn(*args, **kargs) File "/usr/lib/python2.7/site-packages/vdsm/logUtils.py", line 50, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 988, in connectStoragePool spUUID, hostID, msdUUID, masterVersion, domainsMap) File "/usr/share/vdsm/storage/hsm.py", line 1053, in _connectStoragePool res = pool.connect(hostID, msdUUID, masterVersion) File "/usr/share/vdsm/storage/sp.py", line 646, in connect self.__rebuild(msdUUID=msdUUID, masterVersion=masterVersion) File "/usr/share/vdsm/storage/sp.py", line 1219, in __rebuild self.setMasterDomain(msdUUID, masterVersion) File "/usr/share/vdsm/storage/sp.py", line 1427, in setMasterDomain domain = sdCache.produce(msdUUID) File "/usr/share/vdsm/storage/sdc.py", line 101, in produce domain.getRealDomain() File "/usr/share/vdsm/storage/sdc.py", line 53, in getRealDomain return self._cache._realProduce(self._sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 125, in _realProduce domain = self._findDomain(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 144, in _findDomain dom = findMethod(sdUUID) File "/usr/share/vdsm/storage/blockSD.py", line 1441, in findDomain return BlockStorageDomain(BlockStorageDomain.findDomainPath(sdUUID)) File "/usr/share/vdsm/storage/blockSD.py", line 814, in __init__ lvm.checkVGBlockSizes(sdUUID, (self.logBlkSize, self.phyBlkSize)) File "/usr/share/vdsm/storage/lvm.py", line 1056, in checkVGBlockSizes _checkpvsblksize(pvs, vgBlkSize) File "/usr/share/vdsm/storage/lvm.py", line 1033, in _checkpvsblksize pvBlkSize = _getpvblksize(pv) File "/usr/share/vdsm/storage/lvm.py", line 1027, in _getpvblksize dev = devicemapper.getDmId(os.path.basename(pv)) File "/usr/share/vdsm/storage/devicemapper.py", line 40, in getDmId deviceMultipathName) OSError: [Errno 19] Could not find dm device named `[unknown]` Any input how to diagnose or troubleshoot would be appreciated. -- Best Regards Jens Oechsler

2 5

[oVirt4.1] Does oVirt 4.1 support iSCSI offload?
by wodel youchi 07 May '17

07 May '17

Hi, We have two hypervisors, each one has a 10Gbe nic card with two ports, the cards support iSCSI offload. Does oVirt 4.1 support this? if yes how can someone use it on hosted-engine deployment? the VM engine will be in the SAN targeted by these cards. Regards. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 4

Change DNS Server
by Kai Wagner 06 May '17

06 May '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ck3WecahvXJaUfA9994GcjRewKPgnskLx Content-Type: multipart/mixed; boundary="R85rSQvBINNVM8UjrG2weAQEIeXGVwVMH"; protected-headers="v1" From: Kai Wagner <kwagner(a)suse.com> To: users(a)ovirt.org Message-ID: <282bf3c4-662c-c871-a495-cad2e540a311(a)suse.com> Subject: Change DNS Server --R85rSQvBINNVM8UjrG2weAQEIeXGVwVMH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, where can I change the dns server for my hosts? I know the DNS entry is part of the ifcfg-* file, but I tried to change it there and after a reboot the old entry was restored from anywhere. Kai --=20 SUSE Linux GmbH, GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton= , HRB 21284 (AG N=C3=BCrnberg) --R85rSQvBINNVM8UjrG2weAQEIeXGVwVMH-- --Ck3WecahvXJaUfA9994GcjRewKPgnskLx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJY9dKrAAoJEB6MkVYW48RuWuMIAIPFlOXp+ah56n3MlF7t6zJq nlYYbS8JrIX9vo8T9+J4b0qX0RwR0g0TPxP2IzlmFZXTs3nc4r9dhOprFdS0XWKR 52z9S4Mx8BpWJ12HLAqlo5XjeXH/USS7Rc3oD+2t9ZJzA8/ljJ9pLATa/iGzDOcF 1aSHmB/cc+549xNVaOMpS4g8JJJPszmGUMYd3b2Mhquu2iAhhrLu2ZTBjvYhq6IC 6CM7PrDDVjJhi5T3MocHRamLPj6xkfAPEAKvZ3zV3frlpTptTJ4PmEzLcqZ7Tcm+ LTDq4r7gihudFvQ+oOrQKJFtOroZZ8GJ0pgLP86SrY5zlSXmFGkG3Ate64khEAc= =Lka2 -----END PGP SIGNATURE----- --Ck3WecahvXJaUfA9994GcjRewKPgnskLx--

2 3

log out event but not log in?
by Gianluca Cecchi 05 May '17

05 May '17

Hello, In oVirt 4.1 web admin gui I see events about users logging out (they have been created on internal domain with ovirt-aaa-jdbc-tool command), but I don't see the corresponding log in event. The same is true for the default admin@internal user. Is there any reason or is it a bug? Thanks, Gianluca

4 6

Hosted engine already imported
by Jamie Lawrence 04 May '17

04 May '17

Hi all, In my hopefully-near-complete quest to automate Ovirt configuration in our environment, I’m very close. One outstanding issue that remains is that, even though the hosted engine storage domain actually was imported and shows in the GUI, some part of Ovirt appears to think that hasn’t happened yet. In the GUI, a periodic error is logged: “The Hosted Engine Storage Domain doesn’t exist. It will be imported automatically…” In engine.log, all I’m seeing that appears relevant is: 2017-04-25 10:28:57,988-07 INFO [org.ovirt.engine.core.bll.storage.domain.ImportHostedEngineStorageDomainCommand] (org.ovirt.thread.pool-6-thread-9) [1e44dde0] Lock Acquired to object 'EngineLock:{exclusiveLocks='[]', sharedLocks='null'}' 2017-04-25 10:28:57,992-07 WARN [org.ovirt.engine.core.bll.storage.domain.ImportHostedEngineStorageDomainCommand] (org.ovirt.thread.pool-6-thread-9) [1e44dde0] Validation of action 'ImportHostedEngineStorageDomain' failed for user SYSTEM. Reasons: VAR__ACTION__ADD,VAR__TYPE__STORAGE__DOMAIN,ACTION_TYPE_FAILED_STORAGE_DOMAIN_ALREADY_EXIST 2017-04-25 10:28:57,992-07 INFO [org.ovirt.engine.core.bll.storage.domain.ImportHostedEngineStorageDomainCommand] (org.ovirt.thread.pool-6-thread-9) [1e44dde0] Lock freed to object 'EngineLock:{exclusiveLocks='[]', sharedLocks='null’}’ Otherwise the log is pretty clean. I saw nothing of interest in the Gluster logs or the hosted-engine-ha logs on the host it is running on. It appears harmless, but then we aren’t actually using these systems yet, and in any case we don’t want the error spamming the log forever. This is 4.1.1.8-1.el7.centos, hosted engine on Centos 7.6.1311, Gluster for both the hosted engine and general data domains. Has anyone seen this before? Thanks in advance, -j

3 8

Ovirt tasks "stuck"
by Jim Kusznir 04 May '17

04 May '17

Hi: A few days ago I attempted to create a new VM from one of the ovirt-image-repository images. I haven't really figured out how to use this reliably yet, and in this case, while trying to import an image, one of my nodes spontaneously rebooted (or at least, it looked like that to ovirt...Not sure if it had an OOM issue or something else). I assume it was the node that got the task of importing those images, as ever since then (several days now), on my management screen under "Tasks" it shows the attempted imports, still stuck in "processing". I'm quite certain its not actually processing. I do believe it used some of my storage up in the partially downloaded images, though (they do show up as GlanceDisk-<numbers>, with a status of "Locked" under the main Disks tab. How do I "properly" recover from this (abort the task and delete the partial download)? Thanks! --Jim

3 4

Error importing old NFS storage domain
by Endre Karlson 03 May '17

03 May '17

I have a existing NFS storage domain I would like to import. I add the Name attribute and set the path and hit Enter but it gives me "Error while executing actions Attach Storage Domain: Internal Engine Error". I checked the Engine logs too to see if there's any clue when I do it but I cant seem to find anything. Maybe I can attach it here?

2 3