- Users - oVirt List Archives

Re: [ovirt-users] [Centos7.1x64] [Ovirt 3.5.2] SOLVED: Test fence : Power management test failed for Host hosted_engine1 Done
by wodel youchi 17 Jun '15

17 Jun '15

Hi, and thanks for your replies. The problem was the *quotation marks* in fence options, the lanplus="1" and power_wait="60" were misinterpreted, the correct form is lanplus=1, power_wait=60 After changing that the power management was configured and the test passed with : success, on. thanks. 2015-06-11 12:11 GMT+01:00 Martin Perina <mperina(a)redhat.com>: > Hi, > > I have HP DL160 G6 with ILO 2.0 and Firmware 4.23, but I'm really > don't have an idea what is your issue right now with power management. > Because oVirt just executes fence_ipmi on selected proxy host with > parameters you could see in your vdsm log. And those parameters are > identical to your command line options that you used when testing it > with fence_ipmi directly (which worked fine). Very strange :-( > > Also I can't see any difference from oVirt power management code point > of view in using Centos 6 or 7. Just be warned that in oVirt 3.6 not > all features will be supported on Centos 6, so using Centos 7 is IMO > a better option for now. > > But anyway could you please file a bug for oVirt 3.5.2 with the description > of your issue and your logs attached? We will try to reproduce this issue, > but so for I wasn't able to reproduce it. > > About your issue with hp watch dog, I cannot give any specifi advice, just > that you can try to solve the issue by updating BIOS/firmware to latest > version and/or try to contact HP support. > > Thanks a lot > > Martin Perina > > > ----- Original Message ----- > > From: "wodel youchi" <wodel.youchi(a)gmail.com> > > To: "Martin Perina" <mperina(a)redhat.com> > > Cc: "users" <Users(a)ovirt.org>, "Eli Mesika" <emesika(a)redhat.com> > > Sent: Thursday, June 11, 2015 12:56:46 PM > > Subject: Re: [ovirt-users] [Centos7.1x64] [Ovirt 3.5.2] Test fence : > Power management test failed for Host > > hosted_engine1 Done > > > > Hi Martin, > > > > Could you please tell me the version of the ILO firmware you are using? > > > > I did upgrade mine from 1.40 to 2.10 but nothing changed, I did also > > upgrade the smart array p420i card from 5.10 to 6.34 without luck so far. > > > > I checked again all parameters, I can't find the error. > > > > I did all the updates for Centos and oVirt > > > > I have another problem when rebooting any hypervisor, the hypervisor > hangs, > > the problem is with hpwtd (hp watch dog) > > "hpwdt unexpected close not stopping watchdog" > > > > I added this to kernel parameters "intremap=no_x2apic_optout" but it > didn't > > change any thing. > > > > I am thinking to test with the latest kernel available to see if it's a > > kernel problem. > > > > and I am going to reinstall the platform with Centos 6 to see if there > will > > be any differences. > > > > > > > > > > 2015-06-10 12:00 GMT+01:00 wodel youchi <wodel.youchi(a)gmail.com>: > > > > > Hi, > > > > > > engine log is already in debug mode > > > > > > here it is: > > > 2015-06-10 11:48:23,653 INFO > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > > (ajp--127.0.0.1-8702-12) Correlation ID: null, Call Stack: null, Custom > > > Event ID: -1, Message: Host hosted_engine_2 from cluster Default was > chosen > > > as a proxy to execute Status command on Host hosted_engine_1. > > > 2015-06-10 11:48:23,653 INFO [org.ovirt.engine.core.bll.FenceExecutor] > > > (ajp--127.0.0.1-8702-12) Using Host hosted_engine_2 from cluster > Default as > > > proxy to execute Status command on Host > > > 2015-06-10 11:48:23,673 INFO [org.ovirt.engine.core.bll.FenceExecutor] > > > (ajp--127.0.0.1-8702-12) Executing <Status> Power Management command, > Proxy > > > Host:hosted_engine_2, Agent:ipmilan, Target Host:, Management > > > IP:192.168.2.2, User:Administrator, Options: > power_wait="60",lanplus="1", > > > Fencing policy:null > > > 2015-06-10 11:48:23,703 INFO > > > *[org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] > > > (ajp--127.0.0.1-8702-12) START, FenceVdsVDSCommand(HostName = > > > hosted_engine_2, HostId = 0192d1ac-b905-4660-b149-4bef578985dd, > targetVdsId > > > = cf2d1260-7bb3-451a-9cd7-80e6a0ede52a, action = Status, ip = > 192.168.2.2, > > > port = , type = ipmilan, user = Administrator, password = ******, > options = > > > ' power_wait="60",lanplus="1"', policy = 'null'), log id: > > > 2bda01bd2015-06-10 11:48:23,892 WARN > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > > (ajp--127.0.0.1-8702-12) Correlation ID: null, Call Stack: null, Custom > > > Event ID: -1, Message: Power Management test failed for Host > > > hosted_engine_1.Done* > > > 2015-06-10 11:48:23,892 INFO > > > [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] > > > (ajp--127.0.0.1-8702-12) FINISH, FenceVdsVDSCommand, return: > > > *Test Succeeded, unknown, log id: 2bda01bd2015-06-10 11:48:23,897 WARN > > > [org.ovirt.engine.core.bll.FenceExecutor] (ajp--127.0.0.1-8702-12) > Fencing > > > operation failed with proxy host 0192d1ac-b905-4660-*b149-4bef578985dd, > > > trying another proxy... > > > 2015-06-10 11:48:24,039 ERROR [org.ovirt.engine.core.bll.FenceExecutor] > > > (ajp--127.0.0.1-8702-12) Failed to run Power Management command on > Host , > > > no running proxy Host was found. > > > 2015-06-10 11:48:24,039 WARN [org.ovirt.engine.core.bll.FenceExecutor] > > > (ajp--127.0.0.1-8702-12) Failed to find other proxy to re-run failed > fence > > > operation, retrying with the same proxy... > > > 2015-06-10 11:48:24,143 INFO > > > *[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > > (ajp--127.0.0.1-8702-12) Correlation ID: null, Call Stack: null, Custom > > > Event ID: -1, Message: Host hosted_engine_2 from cluster Default was > chosen > > > as a proxy to execute Status command on Host hosted_engine_1.* > > > 2015-06-10 11:48:24,143 INFO [org.ovirt.engine.core.bll.FenceExecutor] > > > (ajp--127.0.0.1-8702-12) Using Host hosted_engine_2 from cluster > Default as > > > proxy to execute Status command on Host > > > > > > *2015-06-10 11:48:24,148 INFO > [org.ovirt.engine.core.bll.FenceExecutor] > > > (ajp--127.0.0.1-8702-12) Executing <Status> Power Management command, > Proxy > > > Host:hosted_engine_2, Agent:ipmilan, Target Host:, Management > > > IP:192.168.2.2, User:Administrator, Options: > power_wait="60",lanplus="1", > > > Fencing policy:null2015-06-10 11:48:24,165 INFO > > > *[org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] > > > (ajp--127.0.0.1-8702-12) START, FenceVdsVDSCommand(HostName = > > > hosted_engine_2, HostId = 0192d1ac-b905-4660-b149-4bef578985dd, > targetVdsId > > > = cf2d1260-7bb3-451a-9cd7-80e6a0ede52a, action = Status, ip = > 192.168.2.2, > > > port = , type = ipmilan, user = Administrator, password = ******, > options = > > > ' power_wait="60",lanplus="1"', policy = 'null'), log id: 7e7f2726 > > > 2015-06-10 11:48:24,360 WARN > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > > (ajp--127.0.0.1-8702-12) Correlation ID: null, Call Stack: null, Custom > > > Event ID: -1, Message: Power Management test failed for Host > > > hosted_engine_1.Done > > > 2015-06-10 11:48:24,360 INFO > > > *[org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] > > > (ajp--127.0.0.1-8702-12) FINISH, FenceVdsVDSCommand, return: Test > > > Succeeded, unknown, log id: 7e7f2726* > > > > > > > > > VDSM log from hosted_engine_2 > > > > > > JsonRpcServer::DEBUG::2015-06-10 > > > 11:48:23,640::__init__::506::jsonrpc.JsonRpcServer::(serve_requests) > > > Waiting for request > > > Thread-2201::DEBUG::2015-06-10 > 11:48:23,642::API::1209::vds::(fenceNode) > > > > *fenceNode(addr=192.168.2.2,port=,agent=ipmilan,user=Administrator,passwd=XXXX,action=status,secure=False,options= > > > power_wait="60"lanplus="1",policy=None)* > > > Thread-2201::DEBUG::2015-06-10 > 11:48:23,642::utils::739::root::(execCmd) > > > /usr/sbin/fence_ipmilan (cwd None) > > > Thread-2201::DEBUG::2015-06-10 > 11:48:23,709::utils::759::root::(execCmd) > > > *FAILED: > > > <err> = 'Failed: Unable to obtain correct plug status or plug is not > > > available\n\n\n*'; <rc> = 1 > > > Thread-2201::DEBUG::2015-06-10 11:48:23,710::API::1164::vds::(fence) > rc 1 > > > inp agent=fence_ipmilan > > > ipaddr=192.168.2.2 > > > login=Administrator > > > action=status > > > passwd=XXXX > > > power_wait="60" > > > lanplus="1" out [] err ['Failed: Unable to obtain correct plug status > or > > > plug is not available', '', ''] > > > Thread-2201::DEBUG::2015-06-10 > 11:48:23,710::API::1235::vds::(fenceNode) > > > rc 1 in agent=fence_ipmilan > > > ipaddr=192.168.2.2 > > > login=Administrator > > > action=status > > > passwd=XXXX > > > power_wait="60" > > > lanplus="1" out [] err ['Failed: Unable to obtain correct plug status > or > > > plug is not available', '', ''] > > > Thread-2201::DEBUG::2015-06-10 > > > 11:48:23,710::stompReactor::163::yajsonrpc.StompServer::(send) Sending > > > response > > > JsonRpc (StompReactor)::DEBUG::2015-06-10 > > > 11:48:23,712::stompReactor::98::Broker.StompAdapter::(handle_frame) > > > Handling message <StompFrame command='SEND'> > > > JsonRpcServer::DEBUG::2015-06-10 > > > 11:48:23,713::__init__::506::jsonrpc.JsonRpcServer::(serve_requests) > > > Waiting for request > > > Thread-2202::DEBUG::2015-06-10 > 11:48:23,715::API::1209::vds::(fenceNode) > > > > fenceNode(addr=192.168.2.2,port=,agent=ipmilan,user=Administrator,passwd=XXXX,action=status,secure=False,options= > > > power_wait="60" > > > lanplus="1",policy=None) > > > Thread-2202::DEBUG::2015-06-10 > 11:48:23,715::utils::739::root::(execCmd) > > > /usr/sbin/fence_ipmilan (cwd None) > > > Thread-2202::DEBUG::2015-06-10 > 11:48:23,781::utils::759::root::(execCmd) > > > FAILED: <err> = 'Failed: Unable to obtain correct plug status or plug > is > > > not available\n\n\n'; <rc> = 1 > > > Thread-2202::DEBUG::2015-06-10 11:48:23,781::API::1164::vds::(fence) > rc 1 > > > inp agent=fence_ipmilan > > > ipaddr=192.168.2.2 > > > login=Administrator > > > action=status > > > passwd=XXXX > > > power_wait="60" > > > lanplus="1" out [] err ['Failed: Unable to obtain correct plug status > or > > > plug is not available', '', ''] > > > > > > > > > > > > I triple checked, I used the correct IPs and login password, the test > in > > > console works. > > > > > > 2015-06-10 10:31 GMT+01:00 Martin Perina <mperina(a)redhat.com>: > > > > > >> Hi, > > >> > > >> I just install engine 3.5.2 on Centos 7.1, added 2 Centos 7.1 hosts > (both > > >> with ipmilan fence devices) and everything worked fine. I also tried > to > > >> add > > >> options > > >> > > >> lanplus="1", power_wait="60" > > >> > > >> and even with them getting power status of hosts worked fine. > > >> > > >> So could you please check again settings of your hosts in webadmin? > > >> > > >> hosted_engine1 > > >> PM address: IP address of ILO4 interface of the host hosted_engine1 > > >> > > >> > > >> hosted_engine2 > > >> PM address: IP address of ILO4 interface of the host hosted_engine2 > > >> > > >> If the IP addresses are entered correctly, please allow DEBUG log for > > >> engine, > > >> execute test of PM settings for one host and attach logs from engine > and > > >> VDSM logs from both hosts. > > >> > > >> Thanks > > >> > > >> Martin Perina > > >> > > >> > > >> ----- Original Message ----- > > >> > From: "wodel youchi" <wodel.youchi(a)gmail.com> > > >> > To: "users" <Users(a)ovirt.org> > > >> > Sent: Tuesday, June 9, 2015 2:41:02 PM > > >> > Subject: [ovirt-users] [Centos7.1x64] [Ovirt 3.5.2] Test fence : > Power > > >> management test failed for Host hosted_engine1 > > >> > Done > > >> > > > >> > Hi, > > >> > > > >> > I have a weird problem with fencing > > >> > > > >> > I have a cluster of two HP DL380p G8 (ILO4) > > >> > > > >> > Centos7.1x64 and oVirt 3.5.2 ALL UPDATED > > >> > > > >> > I configured fencing first with ilo4 then ipmilan > > >> > > > >> > When testing fence from the engine I get : Succeeded, Unknown > > >> > > > >> > And in alerts tab I get : Power management test failed for Host > > >> > hosted_engine1 Done (the same for host2) > > >> > > > >> > I tested with fence_ilo4 and fence_ipmilan and they report the > result > > >> > correctly > > >> > > > >> > # fence_ipmilan -P -a 192.168.2.2 -o status -l Administrator -p > ertyuiop > > >> > -vExecuting: /usr/bin/ipmitool -I lanplus -H 192.168.2.2 -U > > >> Administrator -P > > >> > ertyuiop -p 623 -L ADMINISTRATOR chassis power status > > >> > > > >> > 0 Chassis Power is on > > >> > > > >> > > > >> > Status: ON > > >> > > > >> > > > >> > # fence_ilo4 -l Administrator -p ertyuiop -a 192.168.2.2 -o status > -v > > >> > Executing: /usr/bin/ipmitool -I lanplus -H 192.168.2.2 -U > Administrator > > >> -P > > >> > ertyuiop -p 623 -L ADMINISTRATOR chassis power status > > >> > > > >> > 0 Chassis Power is on > > >> > > > >> > > > >> > Status: ON > > >> > > > >> > ---------------------------------- > > >> > These are the options passed to fence_ipmilan (I tested with the > > >> options and > > >> > without them) > > >> > > > >> > lanplus="1", power_wait="60" > > >> > > > >> > > > >> > This is the engine log: > > >> > > > >> > 2015-06-09 13:35:29,287 INFO > [org.ovirt.engine.core.bll.FenceExecutor] > > >> > (ajp--127.0.0.1-8702-7) Using Host hosted_engine_2 from cluster > Default > > >> as > > >> > proxy to execute Status command on Host > > >> > 2015-06-09 13:35:29,289 INFO > [org.ovirt.engine.core.bll.FenceExecutor] > > >> > (ajp--127.0.0.1-8702-7) Executing <Status> Power Management command, > > >> Proxy > > >> > Host:hosted_engine_2, Agent:ipmilan, Target Host:, Management > > >> > IP:192.168.2.2, User:Administrator, Options: > > >> power_wait="60",lanplus="1", > > >> > Fencing policy:null > > >> > 2015-06-09 13:35:29,306 INFO > > >> > [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] > > >> > (ajp--127.0.0.1-8702-7) START, FenceVdsVDSCommand( > > >> > HostName = hosted_engine_2, > > >> > HostId = 0192d1ac-b905-4660-b149-4bef578985dd, > > >> > targetVdsId = cf2d1260-7bb3-451a-9cd7-80e6a0ede52a, > > >> > action = Status, > > >> > ip = 192.168.2.2, > > >> > port = , > > >> > type = ipmilan, > > >> > user = Administrator, > > >> > password = ******, > > >> > options = ' power_wait="60",lanplus="1"', > > >> > policy = 'null'), log id: 24ce6206 > > >> > 2015-06-09 13:35:29,516 WARN > > >> > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > >> > (ajp--127.0.0.1-8702-7) Correlation ID: null, Call Stack: null, > Custom > > >> Event > > >> > ID: -1, Message: Power Management test failed for Host > > >> hosted_engine_1.Done > > >> > 2015-06-09 13:35:29,516 INFO > > >> > [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] > > >> > (ajp--127.0.0.1-8702-7) FINISH, FenceVdsVDSCommand, return: Test > > >> Succeeded, > > >> > unknown , log id: 24ce6206 > > >> > > > >> > > > >> > and here the vdsm log from the proxy > > >> > > > >> > JsonRpcServer::DEBUG::2015-06-09 > > >> > 13:37:52,461::__init__::506::jsonrpc.JsonRpcServer::(serve_requests) > > >> Waiting > > >> > for request > > >> > Thread-131907::DEBUG::2015-06-09 > > >> 13:37:52,463::API::1209::vds::(fenceNode) > > >> > > > >> > fenceNode(addr=192.168.2.2,port=,agent=ipmilan,user=Administrator,passwd=XXXX,action=status,secure=False,options= > > >> > power_wait="60" > > >> > lanplus="1",policy=None) > > >> > Thread-131907::DEBUG::2015-06-09 > > >> 13:37:52,463::utils::739::root::(execCmd) > > >> > /usr/sbin/fence_ipmilan (cwd None) > > >> > Thread-131907::DEBUG::2015-06-09 > > >> 13:37:52,533::utils::759::root::(execCmd) > > >> > FAILED: <err> = 'Failed: Unable to obtain correct plug status or > plug > > >> is not > > >> > available\n\n\n'; <rc> = 1 > > >> > Thread-131907::DEBUG::2015-06-09 > 13:37:52,533::API::1164::vds::(fence) > > >> rc 1 > > >> > inp agent=fence_ipmilan > > >> > ipaddr=192.168.2.2 > > >> > login=Administrator > > >> > action=status > > >> > passwd=XXXX > > >> > power_wait="60" > > >> > lanplus="1" out [] err ['Failed: Unable to obtain correct plug > status > > >> or plug > > >> > is not available', '', ''] > > >> > Thread-131907::DEBUG::2015-06-09 > > >> 13:37:52,533::API::1235::vds::(fenceNode) rc > > >> > 1 in agent=fence_ipmilan > > >> > ipaddr=192.168.2.2 > > >> > login=Administrator > > >> > action=status > > >> > passwd=XXXX > > >> > power_wait="60" > > >> > lanplus="1" out [] err [' Failed: Unable to obtain correct plug > status > > >> or > > >> > plug is not available ', '', ''] > > >> > Thread-131907::DEBUG::2015-06-09 > > >> > 13:37:52,534::stompReactor::163::yajsonrpc.StompServer::(send) > Sending > > >> > response > > >> > Detector thread::DEBUG::2015-06-09 > > >> > > > >> > 13:37:53,670::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection) > > >> > Adding connection from 127.0.0.1:55761 > > >> > > > >> > > > >> > VDSM rpms > > >> > # rpm -qa | grep vdsm > > >> > vdsm-cli-4.16.14-0.el7.noarch > > >> > vdsm-python-zombiereaper-4.16.14-0.el7.noarch > > >> > vdsm-xmlrpc-4.16.14-0.el7.noarch > > >> > vdsm-yajsonrpc-4.16.14-0.el7.noarch > > >> > vdsm-4.16.14-0.el7.x86_64 > > >> > vdsm-python-4.16.14-0.el7.noarch > > >> > vdsm-jsonrpc-4.16.14-0.el7.noarch > > >> > > > >> > any idea? > > >> > > > >> > Thanks in advance. > > >> > > > >> > _______________________________________________ > > >> > Users mailing list > > >> > Users(a)ovirt.org > > >> > http://lists.ovirt.org/mailman/listinfo/users > > >> > > > >> > > > > > > > > >

2 1

storage domain don't go active anymore after 3.5.3 update
by Nathanaël Blanchet 17 Jun '15

17 Jun '15

Hello, since the update to 3.5.3, my master data domain fails to activate. I don't know what to do, and it is critical for production. Vms are still up but I can't interacte with them anymore If I shutdown any of them, I won't be able to recover them. My datacenter is a FC one, and all of my hosts have been upgraded to vdsm 4.16.20, I restarted vdsmd and engine, but nothing has changed. Thank you for your help. -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

2 5

Need Advice on Hosted Engine installation
by wodel youchi 17 Jun '15

17 Jun '15

Hi, We are installing a new ovirt platform for a client. this is our first deployment. we chose Hosted Engine install. here is the hardware used and the network configuration used be patient :) We have 02 hypervisors for now. each sever has 8 nic ports, we will use bonding. A NAS with nfs4 for the Engine_VM the ISO and Export domains. And iSCSI SAN for the rest of the VMs (Data domain) At first we chose as a network configuration: 10.0.0.X/16 as DMZ (ovirtmgmt will use this network) 172.16.1/24 as Storage network. we've configured our nfs to export only on this network. ----------------- We didn't configure the bonding manually at first, we thought that we could do it once the engine is up.... we couldn't :-( for ovirtmgmt, if we create the bond after the engine's installation, we could not modify the configuration, error message "network in use" for the storage network, we could't attach this logical network to the nic used for the storage, because when we do that we loose the connexion to nfs for the VM engine... so we had to export the VM engine nfs's share on DMZ and we had to configure bonding before starting the hosted engine installation. We also configured bonding on storage network, but after the engine installation, we couldn't attach this bonding to the logical network Storage, error message "you have to specify network address if static protocol is used", the IP address is specified, it's the IP address of the bonding... :-( --------------- Questions: - Do we missed anything on network configuration capabilities of ovirt? or the hosted engine is really a special case? - What is the best way to configure ovirt's Hosted Engine storage? - For the rest of the network, do we have to configure bonding and bridging from the GUI only? (not manually) thanks in advance.

3 2

Bug in hostdeploy / baseurl - RepoError: Cannot find a valid baseurl for repo: base/7/x86_64
by Daniel Helgenberger 17 Jun '15

17 Jun '15

Hello, I just went ahead and filed [BZ1232714] because with ovirt 3.5.3 host deploy seens to fail on CentOS7 if there is no baseurl setting in yum repos: RepoError: Cannot find a valid baseurl for repo: base/7/x86_64 [BZ1232714] https://bugzilla.redhat.com/show_bug.cgi?id=1232714 -8<--------- > 2015-06-17 12:27:37 DEBUG otopi.transaction transaction._prepare:77 preparing 'Yum Transaction' > Loaded plugins: fastestmirror > 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:138 Stage internal_packages METHOD otopi.plugins.otopi.network.hostname.Plugin._internal_packages > 2015-06-17 12:27:37 DEBUG otopi.plugins.otopi.packagers.yumpackager yumpackager.verbose:88 Yum queue package iproute for install > Loading mirror speeds from cached hostfile > 2015-06-17 12:27:37 ERROR otopi.plugins.otopi.packagers.yumpackager yumpackager.error:97 Yum Cannot queue package iproute: Cannot find a valid baseurl for repo: base/7/x86_64 > 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:152 method exception > Traceback (most recent call last): > File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/context.py", line 142, in _executeMethod > method['method']() > File "/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/network/hostname.py", line 66, in _internal_packages > self.packager.install(packages=('iproute',)) > File "/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/packagers/yumpackager.py", line 303, in install > ignoreErrors=ignoreErrors > File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 865, in install > **kwargs > File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 509, in _queue > provides = self._queryProvides(packages=(package,)) > File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 447, in _queryProvides > for po in self._yb.searchPackageProvides(args=packages): > File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 3406, in searchPackageProvides > where = self.returnPackagesByDep(arg) > File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 4232, in returnPackagesByDep > return self.pkgSack.searchProvides(depstring) > File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1079, in <lambda> > pkgSack = property(fget=lambda self: self._getSacks(), > File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 784, in _getSacks > self.repos.populateSack(which=repos) > File "/usr/lib/python2.7/site-packages/yum/repos.py", line 344, in populateSack > self.doSetup() > File "/usr/lib/python2.7/site-packages/yum/repos.py", line 158, in doSetup > self.ayum.plugins.run('postreposetup') > File "/usr/lib/python2.7/site-packages/yum/plugins.py", line 188, in run > func(conduitcls(self, self.base, conf, **kwargs)) > File "/usr/lib/yum-plugins/fastestmirror.py", line 197, in postreposetup_hook > if downgrade_ftp and _len_non_ftp(repo.urls) == 1: > File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 871, in <lambda> > urls = property(fget=lambda self: self._geturls(), > File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 868, in _geturls > self._baseurlSetup() > File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 834, in _baseurlSetup > self.check() > File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 554, in check > 'Cannot find a valid baseurl for repo: %s' % self.ui_id > RepoError: Cannot find a valid baseurl for repo: base/7/x86_64 > 2015-06-17 12:27:37 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Environment packages setup': Cannot find a valid baseurl for repo: base/7/x86_64 > 2015-06-17 12:27:37 DEBUG otopi.transaction transaction.abort:131 aborting 'Yum Transaction' > 2015-06-17 12:27:37 INFO otopi.plugins.otopi.packagers.yumpackager yumpackager.info:92 Yum Performing yum transaction rollback > Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was > 14: curl#7 - "Failed connect to mirrorlist.centos.org:80; No route to host" > Loaded plugins: fastestmirror > 2015-06-17 12:27:37 DEBUG otopi.context context.dumpEnvironment:490 ENVIRONMENT DUMP - BEGIN > 2015-06-17 12:27:37 DEBUG otopi.context context.dumpEnvironment:500 ENV BASE/error=bool:'True' > 2015-06-17 12:27:37 DEBUG otopi.context context.dumpEnvironment:500 ENV BASE/exceptionInfo=list:'[(<class 'yum.Errors.RepoError'>, RepoError(), <traceback object at 0x2e26200>)]' > 2015-06-17 12:27:37 DEBUG otopi.context context.dumpEnvironment:504 ENVIRONMENT DUMP - END > 2015-06-17 12:27:37 INFO otopi.context context.runSequence:417 Stage: Pre-termination -8<----- -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv Geschäftsführer: Martin Retschitzegger / Michaela Göllner Handeslregister: Amtsgericht Charlottenburg / HRB 112767

2 4

problems with power management using idrac7 on r620
by Jason Keltz 17 Jun '15

17 Jun '15

Hi. I've been having problem with power management using iDRAC 7 EXPRESS on a Dell R620. This uses a shared LOM as opposed to Enterprise that has a dedicated one. Every now and then, idrac simply stops responding to ping, so it can't respond to status commands from the proxy. If I send a reboot with "ipmitool mc reset cold" command, the idrac reboots and comes back, but after the problem has occurred, even after a reboot, it responds to ping, but drops 80+% of packets. The only way I can "solve" the problem is to physically restart the server. This isn't just happening on one R620 - it's happening on all of my ovirt hosts. I highly suspect it has to do with a memory leak, and being monitored by engine causes the problem. I had applied a recent firmware upgrade that was supposed to "solve" this kind of problem, but it doesn't. In other to provide Dell with more details, can someone tell me how often each host is being queried for status? I can't seem to find that info. The idrac on my file server doesn't seem to exhibit the same problem, and I suspect that is because it isn't being queried. Thanks, Jason.

4 5

windows guest tools install
by Patrick Russell 17 Jun '15

17 Jun '15

Hi all, We’ve got a large migration in progress for a windows (2k3, 2k8, and 2k12) environment from vmware to ovirt. Does anyone have any suggestions for an unattended ovirt-tools install? Our windows team has pretty much shot down installing python on their VM’s. Are there any flags we can pass to the installer to just accept the defaults? Any other suggestions? Thanks, Patrick

2 1

Postponing 3.6.0 second alpha to next week
by Sandro Bonazzola 17 Jun '15

17 Jun '15

Hi, due to instability of the current code, we need to postpone second alpha to next week. Maintainers: - please ensure that all packages you maintain builds in jenkins - please ensure that all the dependencies required by your packages are available either in ovirt repository or in an external repository included in ovirt-release repo files. - please ensure that engine is at least able to add a couple of hosts, create a vm on one host and migrate it to the other one. Infra: - please help keeping jenkins monitored and stabilizing it. Community: - please help testing nightly build while stabilizing it for the second alpha release. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Just for info: ovirt-guest-agent on Debian 8 Jessie is buggy.
by Arman Khalatyan 16 Jun '15

16 Jun '15

The current debian has an bug the python script does not have exec flag so daemon shows as running but it does nothing. to fix it simply: chmod +x /usr/share/ovirt-guest-agent/ovirt-guest-agent.py systemctl restart ovirt-guest-agent *********************************************************** Dr. Arman Khalatyan eScience -SuperComputing Leibniz-Institut für Astrophysik Potsdam (AIP) An der Sternwarte 16, 14482 Potsdam, Germany ***********************************************************

2 1

Re: [ovirt-users] DWH remove
by Yedidyah Bar David 16 Jun '15

16 Jun '15

----- Original Message ----- > From: "Michael Wagenknecht" <wagenknecht(a)fuh-e.de> > To: "Yedidyah Bar David" <didi(a)redhat.com> > Sent: Tuesday, June 16, 2015 8:58:47 AM > Subject: Re: [ovirt-users] DWH remove > > Hi Didi, > thank you very much for the quick response. > A small report from my side: After doing your instructions I get some > error messages from engine-backup. > I have to remove the folders /var/lib/ovirt-engine-reports, > /var/lib/ovirt-engine-dwh, /etc/ovirt-engine-reports and > /etc/ovirt-engine-dwh manually. Then engine-backup works again. > Otherwise nothing has struck me. Thanks for the report! I'll update the wiki page about migration. Best, > > Best Regards, > Michael > > > Am 14.06.2015 um 07:40 schrieb Yedidyah Bar David: > > ----- Original Message ----- > >> From: "Michael Wagenknecht" <wagenknecht(a)fuh-e.de> > >> To: "Users" <users(a)ovirt.org> > >> Sent: Friday, June 12, 2015 2:15:23 PM > >> Subject: [ovirt-users] DWH remove > >> > >> Hi all, > >> how can I safely remove the DWH extension in ovirt 3.5.1? > > > > This depends on how "safely" you want this... > > > > Just stopping the services and removing the packages should be enough. > > > > I didn't verify what happens if you e.g. later try to run 'engine-cleanup' > > (How will it react when trying to remove them?) or re-install (will they > > behave as if already setup?) etc. > > > > You can/might then also remove the databases from postgres, e.g. > > > > # su - postgres > > psql > > drop database ovirt_engine_history; > > drop database ovirt_engine_reports; > > > >> Is there a howto? > > > > Not for this per-se, but [1] shows how to migrate them to another machine. > > > > We also have open bugs [2][3] to do this more cleanly, but they'll require > > some more work, and it currently does not seem they'll make it to 3.6. > > > > [1] http://www.ovirt.org/Features/Migration_of_local_DWH_Reports_to_remote > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1060529 > > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1169695 > > > > Best, > > > -- Didi

1 0

Import Storage Domain 3.5 Error
by Tang Jackson 16 Jun '15

16 Jun '15

--_000_HK2PR03MB08200834250ECB842629B7DC9CBD0HK2PR03MB0820apcp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have a SAN appliance with a large amount of data including VMs/Templates/= Disks mounted via NFS. When I tried to attach the storage domain to a fres= h ovirt cluster the following occurs 2015-06-10 18:35:58,739 INFO [org.ovirt.engine.core.bll.ImportVmFromConfig= urationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] Lock Acquired to object = EngineLock [exclusiveLocks=3D key: AI_Database value: VM_NAME , sharedLocks=3D key: 765ab10e-2283-465a-919a-fce70d877220 value: REMOTE_VM ] 2015-06-10 18:35:58,741 WARN [org.ovirt.engine.core.bll.ImportVmFromConfig= urationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] CanDoAction of action Im= portVmFromConfiguration failed for user admin@internal. Reasons: VAR__ACTIO= N__IMPORT,VAR__TYPE__VM,ACTION_TYPE_FAILED_STORAGE_DOMAIN_NOT_EXIST 2015-06-10 18:35:58,743 INFO [org.ovirt.engine.core.bll.ImportVmFromConfig= urationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] Lock freed to object Eng= ineLock [exclusiveLocks=3D key: AI_Database value: VM_NAME , sharedLocks=3D key: 765ab10e-2283-465a-919a-fce70d877220 value: REMOTE_VM ] The error appears on the GUI as Storage Domain does not exist. All templates are OK. Some VMs could be imported but most of them produce the error message above= . The procedure followed was http://www.ovirt.org/Features/ImportStorageDomai= n. --_000_HK2PR03MB08200834250ECB842629B7DC9CBD0HK2PR03MB0820apcp_ 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=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"JA" link=3D"blue" vlink=3D"purple" style=3D"text-justify-trim= :punctuation"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">Hell= o,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">I ha= ve a SAN appliance with a large amount of data including VMs/Templates/Disk= s mounted via NFS.  When I tried to attach the storage domain to a fre= sh ovirt cluster the following occurs<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">2015= -06-10 18:35:58,739 INFO  [org.ovirt.engine.core.bll.ImportVmFromConfi= gurationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] Lock Acquired to object= EngineLock [exclusiveLocks=3D key: AI_Database value: VM_NAME<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">, sh= aredLocks=3D key: 765ab10e-2283-465a-919a-fce70d877220 value: REMOTE_VM<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">]<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">2015= -06-10 18:35:58,741 WARN  [org.ovirt.engine.core.bll.ImportVmFromConfi= gurationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] CanDoAction of action I= mportVmFromConfiguration failed for user admin@internal. Reasons: VAR__ACTION__IMPORT,VAR__TYPE__VM,ACTION_TYPE_FAILED_STORAGE_DOMA= IN_NOT_EXIST<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">2015= -06-10 18:35:58,743 INFO  [org.ovirt.engine.core.bll.ImportVmFromConfi= gurationCommand] (ajp--127.0.0.1-8702-4) [1d68187c] Lock freed to object En= gineLock [exclusiveLocks=3D key: AI_Database value: VM_NAME<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">, sh= aredLocks=3D key: 765ab10e-2283-465a-919a-fce70d877220 value: REMOTE_VM<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">]<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">The = error appears on the GUI as Storage Domain does not exist.<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">All = templates are OK.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">Some= VMs could be imported but most of them produce the error message above.<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt">The = procedure followed was <a href=3D"http://www.ovirt.org/Features/ImportStorageDomain">http://www.ov= irt.org/Features/ImportStorageDomain</a>.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.0pt"><o:p= > </o:p></span></p> </div> </body> </html> --_000_HK2PR03MB08200834250ECB842629B7DC9CBD0HK2PR03MB0820apcp_--

2 2

[ANN] oVirt 3.5.3 Second Release Candidate is now available for testing
by Sandro Bonazzola 16 Jun '15

16 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The oVirt team is pleased to announce that the 3.5.3 Second Release Candidate is now available for testing as of May 28th 2015. The release candidate is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS 7.1 (or similar). This release of oVirt includes numerous bug fixes and one CVE fix for the VENOM Vulnerability. See the release notes [1] for a list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO is already available as well[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.5.3_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors - -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVZrrzAAoJEHw3u57E4QAOnX4QAMFi+d4Vq5jnZ0e+LaD1vB9R GmT+k21q6vybjIvovPh7q6StCtPS0sg15BoH5JTmTfl5IWL01qMsFvw/G32PIjZI u3mm2Z3evbxPg9qsqJPyJm/jAlRHv/L6ntLJaJBDPDSO6Y0iqiHTVUQG16easW3L ZnUC2IM5TpHuU3PcgVp8zY9gqFqQWnnsA8deJXBvif9J8RdSf7DnkFha9/Ei3v0E 1btkzt0XVS3Cate8pEaTT8zSoE/tOBBS/D65HsnnZdD13RAxYkolzuPvT+7BlmUO QMhyIE7msWex048HrcDVTEDLrkYF2SpAmYix3sA2O9+AIujenpICHJ8JyxAc+BmJ scsvv99iDLU3wkpMwKiIABj7nE8gIiUbyZBNaxsxQJ0jurLZGHGIhQGLAJ2q/rd7 MTkcDXOBOZHEadqs87mSEzHt1pQCmZ40KSJCvyWbqa7vFv6kyOgOs3PldoizsOyV Z1DlDmfMM8hs/6LOP/Mr/4p/l3JgS3gbOy34L2q9J/B+BX/XU7H2bOk6GTEMVPOn av7m2kDs8DlQJzSqZAURZNt6XTnGGw05THOBWD8NmHuvlVZsSF1mxKb0BC+LpRcs QmLGAtT12Y2Wnq1xwzcRav9+wiIeEYTVJCbyohMLyqTHqPgRstpeF3JulpqILo5I rHhGapreYDlzy06Ki7X7 =pUqF -----END PGP SIGNATURE-----

2 1

Re: [ovirt-users] Adding users through LDAP fails on "external_id"
by Zach La Celle 15 Jun '15

15 Jun '15

I have tried the following combinations of certificates added to the keystore: * PositiveSSL CA bundle (SHA-1 and SHA256) -- This is the source of our SSL certificates * All CA certificates from the LDAP machine * All CA certificates from the LDAP machine plus the machine's own certificate * The machine's own certificate only None fix the issue. As I understand it, adding just the CA bundle from PositiveSSL should work. Or, adding the CA bundles offered by Ubuntu should also work. Previously (when using port 636 and TLS/SSL), to fix SSLPeerUnverifiedException, I added all of the CA certificates from the LDAP machine, plus its own certificate (this last part fixed it). In the mean time, to try and fix the original issue of "external_id", is there any way to disable certificate verification for STARTTLS? On 06/15/2015 03:57 PM, Alon Bar-Lev wrote: > You should add *ONLY* the ca certificate top level to the keystore. > > ----- Original Message ----- >> From: "Zach La Celle" <lacelle(a)roboticresearch.com> >> To: "Alon Bar-Lev" <alonbl(a)redhat.com> >> Sent: Monday, June 15, 2015 10:54:02 PM >> Subject: Re: [ovirt-users] Adding users through LDAP fails on "external_id" >> >> OK, started using the STARTTLS protocol. Tested working using >> ldapsearch, but now ovirt-engine's engine.log complains: >> >> java.io.IOException: Unable to verify an attempt to to establish a >> secure connection to 'directory.roboticresearch.com:389' becau\ >> se an unexpected error was encountered during validation processing: >> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated >> >> Not sure what is wrong. We fixed this before by adding the >> ca-certificates from the LDAP server as well as the LDAP server >> certificate into the .jks keystore. >> >> On 06/15/2015 03:21 PM, Alon Bar-Lev wrote: >>> ----- Original Message ----- >>>> From: "Zach La Celle" <lacelle(a)roboticresearch.com> >>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com> >>>> Sent: Monday, June 15, 2015 10:14:34 PM >>>> Subject: Re: [ovirt-users] Adding users through LDAP fails on >>>> "external_id" >>>> >>>> My mistake. We're using OpenLDAP 2.4.28-1.1ubuntu4.4 on Ubuntu 12.04. >>>> >>>> The full configuration files are as follows (I removed commented-out >>>> lines for brevity). Communications with the LDAP server seem to work >>>> correctly now. >>>> >>>> __profile1.properties__ >>>> >>>> # >>>> >>>> # Select >>>> one >>>> >>>> # >>>> >>>> include = <openldap.properties> >>> reading bellow, you may want to try rfc2307-openldap as your schema seems >>> to be rfc2307 compatible. >>> >>> <snip> >>> >>>> pool.default.serverset.type = single >>>> pool.default.serverset.single.server = ${global:vars.server} >>>> pool.default.serverset.single.port = 636 >>> why do you modify port? please use startTLS on default port. >>> >>>> #pool.default.auth.simple.bindDN = ${global:vars.user} >>>> #pool.default.auth.simple.password = ${global:vars.password} >>> why did you comment this, do you allow anonymous access? >>> >>>> # Create keystore, import certificate chain and uncomment >>>> # if using ssl/tls. >>>> #pool.default.ssl.startTLS = true >>> please uncomment this^ >>> >>>> pool.default.ssl.truststore.file = >>>> ${local:_basedir}/${global:vars.server}.jks >>>> pool.default.ssl.truststore.password = sdfnliwneponalsdinosaivnewal >>>> >>>> # TLS settings and authentication >>>> pool.default.ssl.enable = true >>> please do not use ssl unless startTLS is not supported, and it is in >>> openldap. >>> >>>> pool.default.ssl.startTLS = false >>> please set this to true. >>> >>>> pool.default.ssl.host-name-verify.enable = true >>>> pool.default.ssl.host-name-verify.wildcards = false >>>> pool.default.ssl.insecure = false >>>> pool.default.ssl.protocol = TLSv1 >>>> #pool.default.ssl.startTLSProtocol = TLSv1 >>> these are the default, you do not need to add these. >>> >>>> pool.default.auth.type = none >>> why have you set this explicitly? >>> >>>> # Mapping >>>> attrmap.map-principal-record.attr.PrincipalRecord_DISPLAY_NAME.map = cn >>>> attrmap.map-principal-record.attr.PrincipalRecord_EMAIL.map = Email >>>> attrmap.map-group-record.attr.GroupRecord_DISPLAY_NAME.map = cn >>> please remove mapping, it should work without. >>> >>>> # Variables >>>> sequence.openldap-init-vars.030.var-set.value = entryUUID, uid, cn, >>>> givenName, sn, Email >>>> sequence.openldap-init-vars.040.var-set.value = >>>> (objectClass=posixAccount)(uid=*) >>>> sequence.openldap-init-vars.050.var-set.value = entryUUID, cn >>>> sequence.openldap-init-vars.060.var-set.value = (objectClass=posixGroup) >>>> sequence.openldap-init-vars.070.var-set.value = memberUid >>> why have you added these? maybe you have rfc2307 compatible schema? >>> >>>> On 06/15/2015 03:07 PM, Alon Bar-Lev wrote: >>>>> This probably state that you do not use the correct driver. >>>>> >>>>> You did not mention what LDAP server do you use, and you pasted only >>>>> partial profile. >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Zach La Celle" <lacelle(a)roboticresearch.com> >>>>>> To: users(a)ovirt.org >>>>>> Sent: Monday, June 15, 2015 10:04:47 PM >>>>>> Subject: [ovirt-users] Adding users through LDAP fails on "external_id" >>>>>> >>>>>> Hello, >>>>>> >>>>>> We have a small oVirt cluster set up, and are trying to get it >>>>>> integrated with our LDAP server. >>>>>> >>>>>> I've changed some configuration values in order to try and make it >>>>>> function, and it seems to communicate correctly with the LDAP server. >>>>>> However, when trying to add the user, I get the following error upon SQL >>>>>> entry add: >>>>>> >>>>>> 2015-06-15 14:44:49,439 ERROR >>>>>> [org.ovirt.engine.core.bll.aaa.AddUserCommand] (ajp--127.0.0.1-8702-6) >>>>>> [3b15cbfe] Command org.ovirt.engine.core.bll.aaa.AddUserCommand throw >>>>>> exception: org.springframework.da\ >>>>>> o.DataIntegrityViolationException: CallableStatementCallback; SQL [{call >>>>>> insertuser(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: null >>>>>> value in column "external_id" violates not-null constraint >>>>>> Where: SQL statement "INSERT INTO users(department, domain, email, >>>>>> groups, name, note, role, active, surname, user_id, username, group_ids, >>>>>> external_id,namespace) VALUES( $1 , $2 , $3 , $4 , $5 , $\ >>>>>> 6 , $7 , $8 , $9 , $10 , $11 , $12 , $13 , $14 )" >>>>>> PL/pgSQL function "insertuser" line 2 at SQL statement; nested exception >>>>>> is org.postgresql.util.PSQLException: ERROR: null value in column >>>>>> "external_id" violates not-null constraint >>>>>> Where: SQL statement "INSERT INTO users(department, domain, email, >>>>>> groups, name, note, role, active, surname, user_id, username, group_ids, >>>>>> external_id,namespace) VALUES( $1 , $2 , $3 , $4 , $5 , $\ >>>>>> 6 , $7 , $8 , $9 , $10 , $11 , $12 , $13 , $14 )" >>>>>> >>>>>> I can't figure out what maps from the LDAP user to "external_id" for the >>>>>> SQL table entry. >>>>>> >>>>>> Here are the changes I made to profile1.properties: >>>>>> >>>>>> #Mapping changes >>>>>> attrmap.map-principal-record.attr.PrincipalRecord_DISPLAY_NAME.map = cn >>>>>> attrmap.map-principal-record.attr.PrincipalRecord_EMAIL.map = Email >>>>>> attrmap.map-group-record.attr.GroupRecord_DISPLAY_NAME.map = cn >>>>>> >>>>>> #LDAP value changes >>>>>> sequence.openldap-init-vars.030.var-set.value = entryUUID, uid, cn, >>>>>> givenName, sn, Email >>>>>> sequence.openldap-init-vars.040.var-set.value = >>>>>> (objectClass=posixAccount)(uid=*) >>>>>> sequence.openldap-init-vars.050.var-set.value = entryUUID, cn >>>>>> sequence.openldap-init-vars.060.var-set.value = (objectClass=posixGroup) >>>>>> sequence.openldap-init-vars.070.var-set.value = memberUid >>>>>> >>>>>> Any help is appreciated! >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>> >>

2 3

Adding users through LDAP fails on "external_id"
by Zach La Celle 15 Jun '15

15 Jun '15

Hello, We have a small oVirt cluster set up, and are trying to get it integrated with our LDAP server. I've changed some configuration values in order to try and make it function, and it seems to communicate correctly with the LDAP server. However, when trying to add the user, I get the following error upon SQL entry add: 2015-06-15 14:44:49,439 ERROR [org.ovirt.engine.core.bll.aaa.AddUserCommand] (ajp--127.0.0.1-8702-6) [3b15cbfe] Command org.ovirt.engine.core.bll.aaa.AddUserCommand throw exception: org.springframework.da\ o.DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertuser(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: null value in column "external_id" violates not-null constraint Where: SQL statement "INSERT INTO users(department, domain, email, groups, name, note, role, active, surname, user_id, username, group_ids, external_id,namespace) VALUES( $1 , $2 , $3 , $4 , $5 , $\ 6 , $7 , $8 , $9 , $10 , $11 , $12 , $13 , $14 )" PL/pgSQL function "insertuser" line 2 at SQL statement; nested exception is org.postgresql.util.PSQLException: ERROR: null value in column "external_id" violates not-null constraint Where: SQL statement "INSERT INTO users(department, domain, email, groups, name, note, role, active, surname, user_id, username, group_ids, external_id,namespace) VALUES( $1 , $2 , $3 , $4 , $5 , $\ 6 , $7 , $8 , $9 , $10 , $11 , $12 , $13 , $14 )" I can't figure out what maps from the LDAP user to "external_id" for the SQL table entry. Here are the changes I made to profile1.properties: #Mapping changes attrmap.map-principal-record.attr.PrincipalRecord_DISPLAY_NAME.map = cn attrmap.map-principal-record.attr.PrincipalRecord_EMAIL.map = Email attrmap.map-group-record.attr.GroupRecord_DISPLAY_NAME.map = cn #LDAP value changes sequence.openldap-init-vars.030.var-set.value = entryUUID, uid, cn, givenName, sn, Email sequence.openldap-init-vars.040.var-set.value = (objectClass=posixAccount)(uid=*) sequence.openldap-init-vars.050.var-set.value = entryUUID, cn sequence.openldap-init-vars.060.var-set.value = (objectClass=posixGroup) sequence.openldap-init-vars.070.var-set.value = memberUid Any help is appreciated!

2 1

changelogs for upgrades in ovirt yum repo
by Tiemen Ruiten 15 Jun '15

15 Jun '15

Hello, Is there a changelog available for upgrades in the ovirt repositories? There are some upgrades available for qemu and vdsm and I have no idea whether they're urgent, security related or both. -- Tiemen Ruiten Systems Engineer R&D Media

3 3

oVirt 3.5.3 VDSM on CentOS Virt SIG
by Sandro Bonazzola 15 Jun '15

15 Jun '15

Hi, today oVirt 3.5.3 has been released[1]. VDSM 4.16.20 and its dependencies has been tagged as release as well within the Virt SIG build repositories for CentOS Linux 7. In order to enable the needed repositories you need to create /etc/yum.repos.d/centos-virt-sig.repo with the following content: [virt7-kvm-common-release] name=virt7-kvm-common-release baseurl=http://cbs.centos.org/repos/virt7-kvm-common-release/x86_64/os enabled=1 gpgcheck=0 [virt7-ovirt-common-release] name=virt7-ovirt-common-release baseurl=http://cbs.centos.org/repos/virt7-ovirt-common-release/x86_64/os enabled=1 gpgcheck=0 [virt7-ovirt-35-release] name=virt7-ovirt-35-release baseurl=http://cbs.centos.org/repos/virt7-ovirt-35-release/x86_64/os enabled=1 gpgcheck=0 An initial submission for the repository rpm has been pushed[2] and is waiting for public GPG keys to be added. [1] http://lists.ovirt.org/pipermail/announce/2015-June/000175.html [2] https://gerrit.ovirt.org/41403 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

[ANN] oVirt 3.5.3 Final Release is now available
by Sandro Bonazzola 15 Jun '15

15 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The oVirt team is pleased to announce that the oVirt 3.5.3 Final Release is now available as of June 15th 2015. oVirt is an open source alternative to VMware vSphere, and provides an excellent KVM management interface for multi-node virtualization. oVirt is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS Linux 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar). This release of oVirt includes numerous bug fixes and two CVE fixes. See the release notes [1] for a list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO is already available[2] and oVirt Node ISO will be soon available as well[3]. Please note that mirrors[4] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.5.3_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5/iso/ovirt-live/el6-3.5.3/ovirt-liv… [3] http://resources.ovirt.org/pub/ovirt-3.5/iso/ovirt-node/ [4] http://www.ovirt.org/Repository_mirrors#Current_mirrors - -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVfoI3AAoJEHw3u57E4QAOZtcP/167LZUjWapo8ujNgW9JilAW Cmz9mWoQWzUopaFFhLkpPJV9+ngCIqiny4bgdeStNQCJ3VsbWS6gz1mFgm9M7ZGl 1y6Q5dbUrt+xRtdec+w8BbTb/UEdFPUeQ2Gxa+Z/YCJ4+ovsAX2Sgv2ZVNe6S6zR WBVy79X1oKwJDsTbXjSotl2FxWbHW/+S3+3qI5YLVkwHDhwn6uoHdaNC0xo47fUj Kw9G0VjLhQH3UHtna0QX/rw39elLf9/eVsiIiimSo8YbnQ7aqvkZw3tcOVYs/hGe s+fW+xDnU5IcD90K6JToZYfHc8xsN7KAyfAbJecgS3HVDef1jyjcfxG08cTlG73C Q+XqAZQXlAPHbjMQe8EYHYRAZcpk0EGVOaR+BXmL4x4p9sGCppTavq6W/9FlxkmK tLVz5hFC+H6pjU00T/gCQC1+N8aZSfy8kO5nbbLWdFW9/ixvkIB4SCEVDkbB0keb KphiOJZuxX5U1ZdwK0HvYcA6Z6bevCp9+wZEyi6UdNu/SjJx785USiFjBi/rmXVY h/W0u0bqkjqu6Fc/IlDA8irNhxjwDiNp7qLWba72mlqKif0UKeqBgXmFk9A34BWi bJmToIpnWyrZ5vjYyvHY+fwcnvu7EFFQb/OOnuFspoXc8aOkm6GcGZP+pgm9biN2 aPdWpfSKRDeX6nOg5LZN =5bEX -----END PGP SIGNATURE-----

1 0

DWH remove
by Michael Wagenknecht 14 Jun '15

14 Jun '15

Hi all, how can I safely remove the DWH extension in ovirt 3.5.1? Is there a howto? Best Regards, Michael

2 1

Help with a vdsm hook script script?
by Paul Jansen 12 Jun '15

12 Jun '15

------=_Part_1839633_221010509.1434090878897 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have not coded much python, but I'm having a go at trying to get a vdsm h= ook script working. What it is supposed to do is look for a controller of model 'virtio-scsi' i= n the domxml and change the model to 'ich9-ahci'.I've named the script '50_= change_scsi_controller' and have placed it in '/usr/libexec/vdsm/hooks/befo= re_vm_start' on the one (and only) host in the cluster where I'm doing this= testing.=C2=A0 I've set the perms to 755.I've also added the custom proper= ty to my engine like so: engine-config -s UserDefinedVMProperties=3D'change= _scsi_controller=3D.*' --cver=3D3.5I've restarted the ovirt-engine like so = 'service ovirt-engine restart' , and can now see the custom property in the= GUI config for a powered off VM that is set to boot up into my cluster.=C2= =A0 I've put a string into the 'change_scsi_controller' property and booted= up the VM.The scsi controller model is not changed from 'virtio-scsi' to '= ich9-ahci' =C2=A0On the host when I look at '/var/log/vdsm/vdsm.log' I can see tha tth= e hook is getting called, but I'm not sure what I need to look at here spec= ifically?=C2=A0 Can anyone assist and possibly tell me what is wrong here? = Is it an issue with my python hook script? I'm wanting to test an EL5 based install with a scsi disk, and EL5 does not= support virtio-scsi. I should also mention that I know there are issues with migrating VMs that = use the ich9-ahci sata controller and I don't plan to use this long term.= =C2=A0 If I do need this functionality I'll likely set up some Fedora hosts= in another cluster and use one of the other scsi controller types instead = - ie: 'lsi53c810"', 'lsi53c895a', 'megasas', 'pvscsi'. Here's the hook script code: #!/usr/bin/python =C2=A0 import os import hooking =C2=A0 def main(): =C2=A0 =C2=A0=C2=A0=C2=A0 if hooking.tobool(os.environ.get('change_scsi_controller= ')): =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 newscsiadapter =3D hooking.read_= json() =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 domxml =3D hooking.read_domxml() =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for controller in domxml.getElem= entsByTagName('controller'): =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 filterVa= lue =3D controller.getAttribute('model') =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if filte= rValue =3D=3D 'virtio-scsi': =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 filterValue.setAttribute('model','ich9-ahci') =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hooking.write_domxml(domxml) if __name__ =3D=3D '__main__': =C2=A0=C2=A0=C2=A0 main() ------=_Part_1839633_221010509.1434090878897 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial,= Lucida Grande, Sans-Serif;font-size:16px"><div dir=3D"ltr" id=3D"yui_3_16_= 0_1_1434089995415_2277"><span id=3D"yui_3_16_0_1_1434089995415_2464">I have= not coded much python, but I'm having a go at trying to get a vdsm hook sc= ript working.</span></div><div id=3D"yui_3_16_0_1_1434089995415_2366" dir= =3D"ltr"><br><span></span></div><div id=3D"yui_3_16_0_1_1434089995415_2289"= dir=3D"ltr"><span id=3D"yui_3_16_0_1_1434089995415_2310">What it is suppos= ed to do is look for a controller of model 'virtio-scsi' in the domxml and = change the model to 'ich9-ahci'.</span></div><div id=3D"yui_3_16_0_1_143408= 9995415_2311" dir=3D"ltr"><span id=3D"yui_3_16_0_1_1434089995415_2310"></sp= an></div><div id=3D"yui_3_16_0_1_1434089995415_2338" dir=3D"ltr">I've named= the script '50_change_scsi_controller' and have placed it in '/usr/libexec= /vdsm/hooks/before_vm_start' on the one (and only) host in the cluster wher= e I'm doing this testing.  I've set the perms to 755.</div><div id=3D"= yui_3_16_0_1_1434089995415_2389" dir=3D"ltr">I've also added the custom pro= perty to my engine like so: engine-config -s UserDefinedVMProperties=3D'cha= nge_scsi_controller=3D.*' --cver=3D3.5</div><div id=3D"yui_3_16_0_1_1434089= 995415_2423" dir=3D"ltr">I've restarted the ovirt-engine like so 'service o= virt-engine restart' , and can now see the custom property in the GUI confi= g for a powered off VM that is set to boot up into my cluster.  I've p= ut a string into the 'change_scsi_controller' property and booted up the VM= .</div><div id=3D"yui_3_16_0_1_1434089995415_2453" dir=3D"ltr">The scsi con= troller model is not changed from 'virtio-scsi' to 'ich9-ahci'<br></div><di= v style=3D"" class=3D"" id=3D"yui_3_16_0_1_1434089995415_2338" dir=3D"ltr">=  </div><div id=3D"yui_3_16_0_1_1434089995415_2535" style=3D"" class=3D= "" dir=3D"ltr">On the host when I look at '/var/log/vdsm/vdsm.log' I can se= e tha tthe hook is getting called, but I'm not sure what I need to look at = here specifically?  Can anyone assist and possibly tell me what is wro= ng here? Is it an issue with my python hook script?</div><div id=3D"yui_3_1= 6_0_1_1434089995415_2562" style=3D"" class=3D"" dir=3D"ltr"><br></div><div = id=3D"yui_3_16_0_1_1434089995415_2593" style=3D"" class=3D"" dir=3D"ltr">I'= m wanting to test an EL5 based install with a scsi disk, and EL5 does not s= upport virtio-scsi.<br></div><div id=3D"yui_3_16_0_1_1434089995415_2701" st= yle=3D"" class=3D"" dir=3D"ltr">I should also mention that I know there are= issues with migrating VMs that use the ich9-ahci sata controller and I don= 't plan to use this long term.  If I do need this functionality I'll l= ikely set up some Fedora hosts in another cluster and use one of the other = scsi controller types instead - ie: 'lsi53c810"', 'lsi53c895a', 'megasas', = 'pvscsi'.</div><div id=3D"yui_3_16_0_1_1434089995415_2702" style=3D"" class= =3D"" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1434089995415_2703" sty= le=3D"" class=3D"" dir=3D"ltr">Here's the hook script code:</div><div id=3D= "yui_3_16_0_1_1434089995415_2635" style=3D"" class=3D"" dir=3D"ltr"><br></d= iv><div id=3D"yui_3_16_0_1_1434089995415_2636" style=3D"" class=3D"" dir=3D= "ltr"><br></div><div id=3D"yui_3_16_0_1_1434089995415_2637" style=3D"" clas= s=3D"" dir=3D"ltr">#!/usr/bin/python<br style=3D"" class=3D""> <br sty= le=3D"" class=3D"">import os<br style=3D"" class=3D"">import hooking<br sty= le=3D"" class=3D""> <br style=3D"" class=3D"">def main():<br style=3D"= " class=3D""> <br style=3D"" class=3D"">    if hooking.= tobool(os.environ.get('change_scsi_controller')):<br style=3D"" class=3D"">=         newscsiadapter =3D hooking.read_= json()<br style=3D"" class=3D"">        = domxml =3D hooking.read_domxml()<br style=3D"" class=3D""><br style=3D"" cl= ass=3D"">        for controller in domxm= l.getElementsByTagName('controller'):<br style=3D"" class=3D"">  =           filterValue =3D cont= roller.getAttribute('model')<br style=3D"" class=3D"">   &nb= sp;        if filterValue =3D=3D 'virtio= -scsi':<br style=3D"" class=3D"">       =          filterValue.setAttribute('= model','ich9-ahci')<br style=3D"" class=3D""><br style=3D"" class=3D"">&nbs= p;       hooking.write_domxml(domxml)<br styl= e=3D"" class=3D""><br style=3D"" class=3D""><br style=3D"" class=3D"">if __= name__ =3D=3D '__main__':<br style=3D"" class=3D"">    main(= )<br style=3D"" class=3D""><br></div></div></body></html> ------=_Part_1839633_221010509.1434090878897--

3 2

Re: [ovirt-users] Bug in Snapshot Removing
by Soeren Malchow 11 Jun '15

11 Jun '15

--_000_D1916735D978soerenmalchowmconnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Small addition again: This error shows up in the log while removing snapshots WITHOUT rendering t= he Vms unresponsive =97 Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net libvirtd[1657]: Timed= out during operation: cannot acquire state change lock Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net vdsm[6839]: vdsm vm.V= m ERROR vmId=3D`56848f4a-cd73-4eda-bf79-7eb80ae569a9`::Error getting block = job info Traceback= (most recent call last): File "/= usr/share/vdsm/virt/vm.py", line 5759, in queryBlockJobs=85 =97 From: Soeren Malchow <soeren.malchow(a)mcon.net<mailto:soeren.malchow@mcon.ne= t>> Date: Monday 1 June 2015 00:56 To: "libvirt-users(a)redhat.com<mailto:libvirt-users@redhat.com>" <libvirt-us= ers(a)redhat.com<mailto:libvirt-users@redhat.com>>, users <users(a)ovirt.org<ma= ilto:users@ovirt.org>> Subject: [ovirt-users] Bug in Snapshot Removing Dear all I am not sure if the mail just did not get any attention between all the ma= ils and this time it is also going to the libvirt mailing list. I am experiencing a problem with VM becoming unresponsive when removing Sna= pshots (Live Merge) and i think there is a serious problem. Here are the previous mails, http://lists.ovirt.org/pipermail/users/2015-May/033083.html The problem is on a system with everything on the latest version, CentOS 7.= 1 and ovirt 3.5.2.1 all upgrades applied. This Problem did NOT exist before upgrading to CentOS 7.1 with an environme= nt running ovirt 3.5.0 and 3.5.1 and Fedora 20 with the libvirt-preview rep= o activated. I think this is a bug in libvirt, not ovirt itself, but i am not sure. The = actual file throwing the exception is in VDSM (/usr/share/vdsm/virt/vm.py, = line 697). We are very willing to help, test and supply log files in anyway we can. Regards Soeren --_000_D1916735D978soerenmalchowmconnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9FBCF9D40986EE4C94B0FC8E1FE85212(a)liquidcampaign.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div>Small addition again:</div> <div><br> </div> <div>This error shows up in the log while removing snapshots WITHOUT render= ing the Vms unresponsive</div> <div><br> </div> <div>=97</div> <div> <div>Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net libvirtd[1657]: = Timed out during operation: cannot acquire state change lock</div> <div>Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net vdsm[6839]: vdsm= vm.Vm ERROR vmId=3D`56848f4a-cd73-4eda-bf79-7eb80ae569a9`::Error getting b= lock job info</div> <div>                    =                     &nbsp= ;                     &nb= sp;   Traceback (most recent call last):</div> <div>                    =                     &nbsp= ;                     &nb= sp;     File "/usr/share/vdsm/virt/vm.py", line 5759, i= n queryBlockJobs=85</div> </div> <div><br> </div> <div>=97</div> <div><br> </div> <div><br> </div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:b= lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span style=3D"font-weight:bold">From: </span>Soeren Malchow <<a href=3D= "mailto:soeren.malchow@mcon.net">soeren.malchow(a)mcon.net</a>><br> <span style=3D"font-weight:bold">Date: </span>Monday 1 June 2015 00:56<br> <span style=3D"font-weight:bold">To: </span>"<a href=3D"mailto:libvirt= -users(a)redhat.com">libvirt-users(a)redhat.com</a>" <<a href=3D"mailto= :libvirt-users@redhat.com">libvirt-users(a)redhat.com</a>>, users <<a h= ref=3D"mailto:users@ovirt.org">users(a)ovirt.org</a>><br> <span style=3D"font-weight:bold">Subject: </span>[ovirt-users] Bug in Snaps= hot Removing<br> </div> <div><br> </div> <div> <div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line= -break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-famil= y: Calibri, sans-serif;"> <div>Dear all</div> <div><br> </div> <div>I am not sure if the mail just did not get any attention between all t= he mails and this time it is also going to the libvirt mailing list.</div> <div><br> </div> <div>I am experiencing a problem with VM becoming unresponsive when removin= g Snapshots (Live Merge) and i think there is a serious problem.</div> <div><br> </div> <div>Here are the previous mails,</div> <div><br> </div> <div><a href=3D"http://lists.ovirt.org/pipermail/users/2015-May/033083.html= ">http://lists.ovirt.org/pipermail/users/2015-May/033083.html</a></div> <div><br> </div> <div>The problem is on a system with everything on the latest version, Cent= OS 7.1 and ovirt 3.5.2.1 all upgrades applied.</div> <div><br> </div> <div>This Problem did NOT exist before upgrading to CentOS 7.1 with an envi= ronment running ovirt 3.5.0 and 3.5.1 and Fedora 20 with the libvirt-previe= w repo activated.</div> <div><br> </div> <div>I think this is a bug in libvirt, not ovirt itself, but i am not sure.= The actual file throwing the exception is in VDSM (/usr/share/vdsm/virt/vm= .py, line 697).</div> <div><br> </div> <div>We are very willing to help, test and supply log files in anyway we ca= n. </div> <div><br> </div> <div>Regards</div> <div>Soeren </div> <div><br> </div> </div> </div> </span> </body> </html> --_000_D1916735D978soerenmalchowmconnet_--

3 11

How do I get discard working?
by Chris Jones - BookIt.com Systems Administrator 11 Jun '15

11 Jun '15

oVirt Node - 3.5 - 0.999.201504280931.el7.centos Using our shared storage via baremetal (stock CentOS 7) -> iscsi, I can successfully issue fstrim commands. With oVirt at the VM level, even with direct LUNS, trim commands are not supported despite having the LVM config in the VMs set up to allow it. Thanks -- This email was Virus checked by the PHX UTM 9. For issues please contact the Windows Systems Admin.

4 4

Re: [ovirt-users] [Users] Compiling ovirt-guest-agent on FreeBSD
by Karli Sjöberg 11 Jun '15

11 Jun '15

--_000_88d6743d06ba4ab8bfea500a71da1165emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTEganVuIDIwMTUgNDo0MiBlbSBza3JldiBWaW56ZW56IEZlZW5zdHJhIDx2ZmVlbnN0 ckByZWRoYXQuY29tPjoNCj4NCj4gT24gMDUvMjcvMjAxNSAxMDozOSBBTSwgQWxleGFuZHIgS3Jp dnVseWEgd3JvdGU6DQo+ID4gMDIuMDIuMjAxNSAxMjo1NywgS2FybGkgU2rDtmJlcmcg0L/QuNGI 0LXRgjoNCj4gPj4gT24gU2F0LCAyMDE1LTAxLTMxIGF0IDIzOjU0ICswMjAwLCBBbGV4YW5kciBL cml2dWx5YSB3cm90ZToNCj4gPj4+IDE5LjA4LjIwMTMgMTM6MjEsIEthcmxpIFNqw7ZiZXJnINC/ 0LjRiNC10YI6DQo+ID4+Pg0KPiA+Pj4+IG3DpW4gMjAxMy0wOC0xOSBrbG9ja2FuIDEyOjExICsw MjAwIHNrcmV2IFZpbnplbnogRmVlbnN0cmE6DQo+ID4+Pj4+IE9uIDA4LzE5LzIwMTMgMTA6MDEg QU0sIEthcmxpIFNqw7ZiZXJnIHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gbcOlbiAyMDEzLTA4 LTE5IGtsb2NrYW4gMDk6NTMgKzAyMDAgc2tyZXYgTWljaGFsIFNrcml2YW5lazoNCj4gPj4+Pj4+ PiBPbiBBdWcgMTksIDIwMTMsIGF0IDA5OjQxICwgS2FybGkgU2rDtmJlcmcgPEthcmxpLlNqb2Jl cmdAc2x1LnNlPiB3cm90ZToNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBIaSENCj4gPj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4gQXMgcGFydCBvZiBhIHRlbXBsYXRlIEnCtG0gcHJlcGFyaW5nLCBJwrRtIHdv bmRlcmluZyBob3cgdG8gY29tcGlsZSB0aGUgYWdlbnQgd2l0aCBqdXN0IHRoZSBiYXNpY3MgaW5j bHVkZWQuIEnCtHZlIHRyaWVkIHJ1bm5pbmcgbGlrZToNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4g T1BUSU9OUz0nDQo+ID4+Pj4+Pj4+IC0td2l0aG91dC1nZG0tcGx1Z2luIC0td2l0aG91dC1nZG0y LXBsdWdpbiAgLS13aXRob3V0LWtkbS1wbHVnaW4gLS13aXRob3V0LXBhbS1vdmlydC1jcmVkDQo+ ID4+Pj4+Pj4+IC0td2l0aC1nZG0tcGx1Z2luPW5vIC0td2l0aC1nZG0yLXBsdWdpbj1ubyAtLXdp dGgta2RtLXBsdWdpbj1ubyAtLXdpdGgtcGFtLW92aXJ0LWNyZWQ9bm8NCj4gPj4+Pj4+Pj4gLS1k aXNhYmxlLWdkbS1wbHVnaW4gLS1kaXNhYmxlLWdkbTItcGx1Z2luIC0tZGlzYWJsZS1rZG0tcGx1 Z2luIC0tZGlzYWJsZS1wYW0tb3ZpcnQtY3JlZA0KPiA+Pj4+Pj4+PiAtLWVuYWJsZS1nZG0tcGx1 Z2luPW5vIC0tZW5hYmxlLWdkbTItcGx1Z2luPW5vIC0tZW5hYmxlLWtkbS1wbHVnaW49bm8gLS1l bmFibGVwYW0tb3ZpcnQtY3JlZC09bm8nDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICMgLi9jb25m aWd1cmUgJHtPUFRJT05TfQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBSZWdhcmRsZXNzIG9mIGhv dyBJIHRyeSwgaXQganVzdCByZXNwb25kczoNCj4gPj4+Pj4+Pj4gY29uZmlndXJlOiBXQVJOSU5H OiB1bnJlY29nbml6ZWQgb3B0aW9uczogJHtPUFRJT05TfQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ PiBJIHRvb2sgdGhlIHBhY2thZ2UgZnJvbSB0aGUgIm9mZmljaWFsIiBvVmlydC5vcmcgcmVwbywg c3JjIGZpbGU6DQo+ID4+Pj4+Pj4+IG92aXJ0LWd1ZXN0LWFnZW50LTEuMC42LnRhci5iejINCj4g Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gV2hhdCBhbSBJIGRvaW5nIHdyb25nPw0KPiA+Pj4+Pj4+IEhp DQo+ID4+Pj4+Pj4gdGhlIHBhcmFtZXRlcnMgYXJlIGdkbSwga2RtIGFuZCBzc28sIHNldCB0aGVt IHRvIG5vDQo+ID4+Pj4+PiBJIGRvbsK0dCBnZXQgaXQsIGl0IGRvZXNuwrR0IHNlZW0gdG8gY2Fy ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAjIC4vY29uZmlndXJlIC0td2l0aG91dC1nZG0NCj4gPj4+ Pj4+ICMgLi9jb25maWd1cmUgLS13aXRoLWdkbT1ubw0KPiA+Pj4+Pj4gIyAuL2NvbmZpZ3VyZSAt LWVuYWJsZS1nZG09bm8NCj4gPj4+Pj4+ICMgLi9jb25maWd1cmUgLS1kaXNhYmxlLWdkbQ0KPiA+ Pj4+Pj4gIyAuL2NvbmZpZ3VyZSAtLXdpdGhvdXQtZ2RtIC0td2l0aC1nZG09bm8gLS1lbmFibGUt Z2RtPW5vDQo+ID4+Pj4+PiAtLWRpc2FibGUtZ2RtDQo+ID4+Pj4+PiBjb25maWd1cmU6IFdBUk5J Tkc6IHVucmVjb2duaXplZCBvcHRpb25zOiAtLXdpdGhvdXQtZ2RtLA0KPiA+Pj4+Pj4gLS13aXRo LWdkbSwgLS1lbmFibGUtZ2RtLCAtLWRpc2FibGUtZ2RtDQo+ID4+Pj4+IHRoaXMgZmVhdHVyZSBv ZiBkaXNhYmxpbmcgaXQgd2FzIGludHJvZHVjZWQgdG8gb3ZpcnQtZ3Vlc3QtYWdlbnQNCj4gPj4+ Pj4gaW4gMS4wLjgNCj4gPj4+Pj4NCj4gPj4+Pj4gVHJ5IHRoaXMgb25lOg0KPiA+Pj4+PiBodHRw Oi8vZXZpbGlzc2ltby5mZWRvcmFwZW9wbGUub3JnL3JlbGVhc2VzL292aXJ0LWd1ZXN0LWFnZW50 LzEuMC44L292aXJ0LWd1ZXN0LWFnZW50LTEuMC44LjEudGFyLmJ6Mg0KPiA+Pj4+Pg0KPiA+Pj4+ PiAuL2NvbmZpZ3VyZSAtLXdpdGhvdXQtc3NvIC0tcHJlZml4PS91c3INCj4gPj4+PiBZb3Uga25v dyB3aGF0LCBzb3JyeSBhYm91dCB0aGUgbm9pc2UsIGJlY2F1c2UgaXQgc2VlbXMgYXMgaWYNCj4g Pj4+PiB2aXJ0aW8tc2VyaWFsIGlzbsK0dCBldmVuIGF2YWlsYWJsZSBvbiBGcmVlQlNELCBzbyBp dMK0cyBtb290DQo+ID4+Pj4gYW55d2F5Li4uIFNob3VsZCBwcm9iYWJseSBoYXZlIGxvb2tlZCB0 aGF0IHVwIGJlZm9yZSBldmVuIGdldHRpbmcNCj4gPj4+PiBzdGFydGVkOykNCj4gPj4+Pg0KPiA+ Pj4+IEJ1dCBiZXNpZGVzIHRoZSBmYWN0IHRoYXQgaXQgd29uwrR0IHdvcmsgdW50aWwgdGhhdMK0 cyBzb3J0ZWQsIEkgY2FuDQo+ID4+Pj4gYXQgbGVhc3Qgc2F5IHRoYXQgaXQgY29uZmlndXJlZCwg Y29tcGlsZWQgYW5kIGluc3RhbGxlZCBPSyB1c2luZw0KPiA+Pj4+IFJlbsOpwrRzIHN1Z2dlc3Rp b24sIGNsb25pbmcgZnJvbSBnaXQgYW5kIGJ1aWxkaW5nIGZyb20gdGhlcmUuDQo+ID4+PiBIZWxs byENCj4gPj4+IE5vdyB3aGVuIHZpcnRpb19jb25zb2xlKDQpIGRyaXZlciBhdmFpbGFibGUgaW4g Q1VSUkVOVCBkb2VzIGFueW9uZQ0KPiA+Pj4gd29ya3Mgb24gcG9ydGluZyBvdmlydC1ndWVzdC1h Z2VudCB0byBGcmVlQlNEPw0KPiA+Pj4gcGxhaW4gdGV4dCBkb2N1bWVudCBhdHRhY2htZW50IChB VFQwMDAwMSkNCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+PiBVc2VycyBtYWlsaW5nIGxpc3QNCj4gPj4+IFVzZXJzQG92aXJ0Lm9yZw0K PiA+Pj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+ID4+ IEkgaGF2ZW7CtHQgdGVzdGVkIGFueXRoaW5nIHNpbmNlIGxhc3QgdGltZSBidXQgZ29vZCB0byBr bm93IHNvbWVvbmUgZG9pbmcNCj4gPj4gc29tZXRoaW5nOikgSSBjYW4gaW1hZ2luZSB0aGUgZ3Vl c3QgYWdlbnQgd291bGQgbmVlZCBzb21lIHR3ZWVraW5nIHRvDQo+ID4+IGdldCBpdCBydW5uaW5n IGFzIHdlbGw6DQo+ID4+DQo+ID4+IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9waXBlcm1haWwv ZnJlZWJzZC1lbXVsYXRpb24vMjAxMy1BcHJpbC8wMTA1NjkuaHRtbA0KPiA+PiAiVGhlIFZpcnRJ TyBzcGVjIGlzIHdyaXR0ZW4gd2l0aCBtb3N0bHkgTGludXggaW4gbWluZCBhbmQgdXN1YWxseSB0 YWtlcw0KPiA+PiB2YXJ5aW5nIGFtb3VudHMgb2YgZXh0cmEgZWZmb3J0IHRvIGFkYXB0IHRvIEZy ZWVCU0QuIg0KPiA+Pg0KPiA+Pg0KPiA+IEkgaGF2ZSBzdWNjZXNzZnVsbHkgYnVpbGQgYW5kIHJ1 biBndWVzdCBhZ2VudCBvbiBGcmVlQlNELUN1cnJlbnQuIEl0DQo+ID4gcHJvdmlkZXMgYSBmZXcg aW5mb3JtYXRpb24gKGZvciBleGFtcGxlIGZxZG4gYW5kIGxvZ2dlZCB1c2VycykgaW50bw0KPiA+ IGFkbWluIHBvcnRhbCwgYnV0IGFsbCBvdGhlciByZXF1aXJlcyByZXdyaXRpbmcgR3Vlc3RBZ2Vu dExpbnV4Mi5weSBvcg0KPiA+IGltcGxlbWVudGluZyBpdCBhcyBzZXBhcmF0ZSBtb2R1bGUuIEkg aGF2ZSBubyBleHBlcmllbmNlIGluIHB5dGhvbiBhbmQNCj4gPiBwcm9ncmFtbWluZyBpdHNlbGYs IGJ1dCBpbXBsZW1lbnRpbmcgc29tZSBzaW1wbGUgZmVhdHVyZXMgbWF5IGJlIHF1aWV0DQo+ID4g ZWFzeS4gQ2FuIGFueW9uZSBoZWxwIHdpdGggaXQ/DQo+IFNvcnJ5IGZvciB0aGUgbGF0ZSByZXBs eSwgbm93IEkgZGlkbid0IG5vdGljZSB0aGF0IHRoZSBkcml2ZXJzIGFyZSBub3cNCj4gYXZhaWxh YmxlLCBJIHdpbGwgYmUgbG9va2luZyBpbnRvIHN1cHBvcnRpbmcgRnJlZUJTRCBmb3IgdGhlIGd1 ZXN0IGFnZW50DQo+IHRoZW4uDQoNCkhlcmUncyBhbiBleGNlbGxlbnQgcGxhY2UgdG8gc3RhcnQ6 KQ0KaHR0cHM6Ly93d3cuZnJlZWJzZC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9ib29rcy9wb3J0 ZXJzLWhhbmRib29rLw0KDQovSw0KDQo+DQo+IFRoYW5rcyBmb3IgdGhlIGhlYWRzIHVwIDotKQ0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g VXNlcnMgbWFpbGluZyBsaXN0DQo+ID4gVXNlcnNAb3ZpcnQub3JnDQo+ID4gaHR0cDovL2xpc3Rz Lm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+DQo+DQo+IC0tDQo+IFJlZ2FyZHMs DQo+DQo+IFZpbnplbnogRmVlbnN0cmEgfCBTZW5pb3IgU29mdHdhcmUgRW5naW5lZXINCj4gUmVk SGF0IEVuZ2luZWVyaW5nIFZpcnR1YWxpemF0aW9uIFIgJiBEDQo+IFBob25lOiArNDIwIDUzMiAy OTQgNjI1DQo+IElSQzogdmZlZW5zdHIgb3IgZXZpbGlzc2ltbw0KPg0KPiBCZXR0ZXIgdGVjaG5v bG9neS4gRmFzdGVyIGlubm92YXRpb24uIFBvd2VyZWQgYnkgY29tbXVuaXR5IGNvbGxhYm9yYXRp b24uDQo+IFNlZSBob3cgaXQgd29ya3MgYXQgcmVkaGF0LmNvbQ0KPg0K --_000_88d6743d06ba4ab8bfea500a71da1165emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <B2651542710001428FAF322F6A8F4A69(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxMSBqdW4gMjAxNSA0OjQyIGVtIHNrcmV2IFZpbnplbnogRmVlbnN0cmEgJmx0 O3ZmZWVuc3RyQHJlZGhhdC5jb20mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDA1LzI3LzIw MTUgMTA6MzkgQU0sIEFsZXhhbmRyIEtyaXZ1bHlhIHdyb3RlOjxicj4NCiZndDsgJmd0OyAwMi4w Mi4yMDE1IDEyOjU3LCBLYXJsaSBTasO2YmVyZyDQv9C40YjQtdGCOjxicj4NCiZndDsgJmd0OyZn dDsgT24gU2F0LCAyMDE1LTAxLTMxIGF0IDIzOjU0ICYjNDM7MDIwMCwgQWxleGFuZHIgS3JpdnVs eWEgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgMTkuMDguMjAxMyAxMzoyMSwgS2FybGkg U2rDtmJlcmcg0L/QuNGI0LXRgjo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBtw6VuIDIwMTMtMDgtMTkga2xvY2thbiAxMjoxMSAmIzQzOzAyMDAgc2ty ZXYgVmluemVueiBGZWVuc3RyYTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDA4 LzE5LzIwMTMgMTA6MDEgQU0sIEthcmxpIFNqw7ZiZXJnIHdyb3RlOjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtw6VuIDIw MTMtMDgtMTkga2xvY2thbiAwOTo1MyAmIzQzOzAyMDAgc2tyZXYgTWljaGFsIFNrcml2YW5lazo8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gQXVnIDE5LCAyMDEzLCBh dCAwOTo0MSAsIEthcmxpIFNqw7ZiZXJnICZsdDtLYXJsaS5Tam9iZXJnQHNsdS5zZSZndDsgd3Jv dGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBBcyBwYXJ0IG9mIGEgdGVtcGxhdGUgScK0bSBwcmVwYXJpbmcsIEnCtG0gd29uZGVyaW5n IGhvdyB0byBjb21waWxlIHRoZSBhZ2VudCB3aXRoIGp1c3QgdGhlIGJhc2ljcyBpbmNsdWRlZC4g ScK0dmUgdHJpZWQgcnVubmluZyBsaWtlOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9Q VElPTlM9Jzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS13aXRo b3V0LWdkbS1wbHVnaW4gLS13aXRob3V0LWdkbTItcGx1Z2luJm5ic3A7IC0td2l0aG91dC1rZG0t cGx1Z2luIC0td2l0aG91dC1wYW0tb3ZpcnQtY3JlZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgLS13aXRoLWdkbS1wbHVnaW49bm8gLS13aXRoLWdkbTItcGx1Z2lu PW5vIC0td2l0aC1rZG0tcGx1Z2luPW5vIC0td2l0aC1wYW0tb3ZpcnQtY3JlZD1ubzxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS1kaXNhYmxlLWdkbS1wbHVnaW4g LS1kaXNhYmxlLWdkbTItcGx1Z2luIC0tZGlzYWJsZS1rZG0tcGx1Z2luIC0tZGlzYWJsZS1wYW0t b3ZpcnQtY3JlZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS1l bmFibGUtZ2RtLXBsdWdpbj1ubyAtLWVuYWJsZS1nZG0yLXBsdWdpbj1ubyAtLWVuYWJsZS1rZG0t cGx1Z2luPW5vIC0tZW5hYmxlcGFtLW92aXJ0LWNyZWQtPW5vJzxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICMgLi9jb25maWd1cmUgJHtPUFRJT05TfTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFJlZ2FyZGxlc3Mgb2YgaG93IEkgdHJ5LCBpdCBqdXN0IHJlc3BvbmRzOjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uZmlndXJlOiBXQVJOSU5HOiB1 bnJlY29nbml6ZWQgb3B0aW9uczogJHtPUFRJT05TfTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IEkgdG9vayB0aGUgcGFja2FnZSBmcm9tIHRoZSAmcXVvdDtvZmZpY2lhbCZxdW90OyBvVmly dC5vcmcgcmVwbywgc3JjIGZpbGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBvdmlydC1ndWVzdC1hZ2VudC0xLjAuNi50YXIuYnoyPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgV2hhdCBhbSBJIGRvaW5nIHdyb25nPzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBIaTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB0aGUgcGFyYW1ldGVycyBhcmUgZ2RtLCBrZG0gYW5kIHNzbywgc2V0IHRoZW0gdG8gbm88YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRvbsK0dCBnZXQgaXQsIGl0IGRvZXNu wrR0IHNlZW0gdG8gY2FyZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICMgLi9jb25maWd1cmUgLS13aXRob3V0LWdk bTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICMgLi9jb25maWd1cmUgLS13aXRo LWdkbT1ubzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICMgLi9jb25maWd1cmUg LS1lbmFibGUtZ2RtPW5vPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgIyAuL2Nv bmZpZ3VyZSAtLWRpc2FibGUtZ2RtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg IyAuL2NvbmZpZ3VyZSAtLXdpdGhvdXQtZ2RtIC0td2l0aC1nZG09bm8gLS1lbmFibGUtZ2RtPW5v PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS1kaXNhYmxlLWdkbTxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbmZpZ3VyZTogV0FSTklORzogdW5yZWNvZ25p emVkIG9wdGlvbnM6IC0td2l0aG91dC1nZG0sPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgLS13aXRoLWdkbSwgLS1lbmFibGUtZ2RtLCAtLWRpc2FibGUtZ2RtPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGlzIGZlYXR1cmUgb2YgZGlzYWJsaW5nIGl0IHdhcyBpbnRy b2R1Y2VkIHRvIG92aXJ0LWd1ZXN0LWFnZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBpbiAxLjAuODxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFRyeSB0aGlzIG9uZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGh0dHA6Ly9ldmlsaXNzaW1vLmZlZG9yYXBlb3BsZS5vcmcvcmVsZWFzZXMvb3ZpcnQtZ3Vl c3QtYWdlbnQvMS4wLjgvb3ZpcnQtZ3Vlc3QtYWdlbnQtMS4wLjguMS50YXIuYnoyPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLi9j b25maWd1cmUgLS13aXRob3V0LXNzbyAtLXByZWZpeD0vdXNyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFlvdSBrbm93IHdoYXQsIHNvcnJ5IGFib3V0IHRoZSBub2lzZSwgYmVjYXVzZSBpdCBz ZWVtcyBhcyBpZjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB2aXJ0aW8tc2VyaWFsIGlzbsK0 dCBldmVuIGF2YWlsYWJsZSBvbiBGcmVlQlNELCBzbyBpdMK0cyBtb290PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGFueXdheS4uLiBTaG91bGQgcHJvYmFibHkgaGF2ZSBsb29rZWQgdGhhdCB1 cCBiZWZvcmUgZXZlbiBnZXR0aW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHN0YXJ0ZWQ7 KTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBC dXQgYmVzaWRlcyB0aGUgZmFjdCB0aGF0IGl0IHdvbsK0dCB3b3JrIHVudGlsIHRoYXTCtHMgc29y dGVkLCBJIGNhbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhdCBsZWFzdCBzYXkgdGhhdCBp dCBjb25maWd1cmVkLCBjb21waWxlZCBhbmQgaW5zdGFsbGVkIE9LIHVzaW5nPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IFJlbsOpwrRzIHN1Z2dlc3Rpb24sIGNsb25pbmcgZnJvbSBnaXQgYW5k IGJ1aWxkaW5nIGZyb20gdGhlcmUuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSGVsbG8hPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsgTm93IHdoZW4gdmlydGlvX2NvbnNvbGUoNCkgZHJpdmVyIGF2YWls YWJsZSBpbiBDVVJSRU5UIGRvZXMgYW55b25lPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgd29ya3Mg b24gcG9ydGluZyBvdmlydC1ndWVzdC1hZ2VudCB0byBGcmVlQlNEPzxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7IHBsYWluIHRleHQgZG9jdW1lbnQgYXR0YWNobWVudCAoQVRUMDAwMDEpPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBVc2VycyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBVc2Vyc0BvdmlydC5vcmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBodHRw Oi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+DQomZ3Q7ICZndDsm Z3Q7IEkgaGF2ZW7CtHQgdGVzdGVkIGFueXRoaW5nIHNpbmNlIGxhc3QgdGltZSBidXQgZ29vZCB0 byBrbm93IHNvbWVvbmUgZG9pbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7IHNvbWV0aGluZzopIEkgY2Fu IGltYWdpbmUgdGhlIGd1ZXN0IGFnZW50IHdvdWxkIG5lZWQgc29tZSB0d2Vla2luZyB0bzxicj4N CiZndDsgJmd0OyZndDsgZ2V0IGl0IHJ1bm5pbmcgYXMgd2VsbDo8YnI+DQomZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvcGlwZXJtYWlsL2Zy ZWVic2QtZW11bGF0aW9uLzIwMTMtQXByaWwvMDEwNTY5Lmh0bWw8YnI+DQomZ3Q7ICZndDsmZ3Q7 ICZxdW90O1RoZSBWaXJ0SU8gc3BlYyBpcyB3cml0dGVuIHdpdGggbW9zdGx5IExpbnV4IGluIG1p bmQgYW5kIHVzdWFsbHkgdGFrZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IHZhcnlpbmcgYW1vdW50cyBv ZiBleHRyYSBlZmZvcnQgdG8gYWRhcHQgdG8gRnJlZUJTRC4mcXVvdDs8YnI+DQomZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyBJIGhhdmUgc3VjY2Vzc2Z1bGx5 IGJ1aWxkIGFuZCBydW4gZ3Vlc3QgYWdlbnQgb24gRnJlZUJTRC1DdXJyZW50LiBJdDxicj4NCiZn dDsgJmd0OyBwcm92aWRlcyBhIGZldyBpbmZvcm1hdGlvbiAoZm9yIGV4YW1wbGUgZnFkbiBhbmQg bG9nZ2VkIHVzZXJzKSBpbnRvPGJyPg0KJmd0OyAmZ3Q7IGFkbWluIHBvcnRhbCwgYnV0IGFsbCBv dGhlciByZXF1aXJlcyByZXdyaXRpbmcgR3Vlc3RBZ2VudExpbnV4Mi5weSBvcjxicj4NCiZndDsg Jmd0OyBpbXBsZW1lbnRpbmcgaXQgYXMgc2VwYXJhdGUgbW9kdWxlLiBJIGhhdmUgbm8gZXhwZXJp ZW5jZSBpbiBweXRob24gYW5kPGJyPg0KJmd0OyAmZ3Q7IHByb2dyYW1taW5nIGl0c2VsZiwgYnV0 IGltcGxlbWVudGluZyBzb21lIHNpbXBsZSBmZWF0dXJlcyBtYXkgYmUgcXVpZXQ8YnI+DQomZ3Q7 ICZndDsgZWFzeS4gQ2FuIGFueW9uZSBoZWxwIHdpdGggaXQ/PGJyPg0KJmd0OyBTb3JyeSBmb3Ig dGhlIGxhdGUgcmVwbHksIG5vdyBJIGRpZG4ndCBub3RpY2UgdGhhdCB0aGUgZHJpdmVycyBhcmUg bm93IDxicj4NCiZndDsgYXZhaWxhYmxlLCBJIHdpbGwgYmUgbG9va2luZyBpbnRvIHN1cHBvcnRp bmcgRnJlZUJTRCBmb3IgdGhlIGd1ZXN0IGFnZW50IDxicj4NCiZndDsgdGhlbi48L3A+DQo8cCBk aXI9Imx0ciI+SGVyZSdzIGFuIGV4Y2VsbGVudCBwbGFjZSB0byBzdGFydDopPGJyPg0KaHR0cHM6 Ly93d3cuZnJlZWJzZC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9ib29rcy9wb3J0ZXJzLWhhbmRi b29rLzwvcD4NCjxwIGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0 OyBUaGFua3MgZm9yIHRoZSBoZWFkcyB1cCA6LSk8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgVXNlcnMg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IFVzZXJzQG92aXJ0Lm9yZzxicj4NCiZndDsgJmd0 OyBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDs8YnI+ DQomZ3Q7IFZpbnplbnogRmVlbnN0cmEgfCBTZW5pb3IgU29mdHdhcmUgRW5naW5lZXI8YnI+DQom Z3Q7IFJlZEhhdCBFbmdpbmVlcmluZyBWaXJ0dWFsaXphdGlvbiBSICZhbXA7IEQ8YnI+DQomZ3Q7 IFBob25lOiAmIzQzOzQyMCA1MzIgMjk0IDYyNTxicj4NCiZndDsgSVJDOiB2ZmVlbnN0ciBvciBl dmlsaXNzaW1vPGJyPg0KJmd0Ozxicj4NCiZndDsgQmV0dGVyIHRlY2hub2xvZ3kuIEZhc3RlciBp bm5vdmF0aW9uLiBQb3dlcmVkIGJ5IGNvbW11bml0eSBjb2xsYWJvcmF0aW9uLjxicj4NCiZndDsg U2VlIGhvdyBpdCB3b3JrcyBhdCByZWRoYXQuY29tPGJyPg0KJmd0Ozxicj4NCjwvcD4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_88d6743d06ba4ab8bfea500a71da1165emailandroidcom_--

1 0

[Users] Compiling ovirt-guest-agent on FreeBSD
by Karli Sjöberg 11 Jun '15

11 Jun '15

--_000_5F9E965F5A80BC468BE5F40576769F092E70EBE0exchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkFzIHBhcnQgb2YgYSB0ZW1wbGF0ZSBJwrRtIHByZXBhcmluZywgScK0bSB3b25kZXJp bmcgaG93IHRvIGNvbXBpbGUgdGhlIGFnZW50IHdpdGgganVzdCB0aGUgYmFzaWNzIGluY2x1ZGVk LiBJwrR2ZSB0cmllZCBydW5uaW5nIGxpa2U6DQoNCk9QVElPTlM9Jw0KLS13aXRob3V0LWdkbS1w bHVnaW4gLS13aXRob3V0LWdkbTItcGx1Z2luICAtLXdpdGhvdXQta2RtLXBsdWdpbiAtLXdpdGhv dXQtcGFtLW92aXJ0LWNyZWQNCi0td2l0aC1nZG0tcGx1Z2luPW5vIC0td2l0aC1nZG0yLXBsdWdp bj1ubyAtLXdpdGgta2RtLXBsdWdpbj1ubyAtLXdpdGgtcGFtLW92aXJ0LWNyZWQ9bm8NCi0tZGlz YWJsZS1nZG0tcGx1Z2luIC0tZGlzYWJsZS1nZG0yLXBsdWdpbiAtLWRpc2FibGUta2RtLXBsdWdp biAtLWRpc2FibGUtcGFtLW92aXJ0LWNyZWQNCi0tZW5hYmxlLWdkbS1wbHVnaW49bm8gLS1lbmFi bGUtZ2RtMi1wbHVnaW49bm8gLS1lbmFibGUta2RtLXBsdWdpbj1ubyAtLWVuYWJsZXBhbS1vdmly dC1jcmVkLT1ubycNCg0KIyAuL2NvbmZpZ3VyZSAke09QVElPTlN9DQoNClJlZ2FyZGxlc3Mgb2Yg aG93IEkgdHJ5LCBpdCBqdXN0IHJlc3BvbmRzOg0KY29uZmlndXJlOiBXQVJOSU5HOiB1bnJlY29n bml6ZWQgb3B0aW9uczogJHtPUFRJT05TfQ0KDQpJIHRvb2sgdGhlIHBhY2thZ2UgZnJvbSB0aGUg Im9mZmljaWFsIiBvVmlydC5vcmcgcmVwbywgc3JjIGZpbGU6DQpvdmlydC1ndWVzdC1hZ2VudC0x LjAuNi50YXIuYnoyDQoNCldoYXQgYW0gSSBkb2luZyB3cm9uZz8NCg0KLS0NCg0KTWVkIFbDpG5s aWdhIEjDpGxzbmluZ2FyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpLYXJsaSBTasO2YmVyZw0K U3dlZGlzaCBVbml2ZXJzaXR5IG9mIEFncmljdWx0dXJhbCBTY2llbmNlcw0KQm94IDcwNzkgKFZp c2l0aW5nIEFkZHJlc3MgS3JvbsOlc3bDpGdlbiA4KQ0KUy03NTAgMDcgVXBwc2FsYSwgU3dlZGVu DQpQaG9uZTogICs0Ni0oMCkxOC02NyAxNSA2Ng0Ka2FybGkuc2pvYmVyZ0BzbHUuc2U8bWFpbHRv OmthcmxpLnNqb2JlcmdAYWRtLnNsdS5zZT4NCg== --_000_5F9E965F5A80BC468BE5F40576769F092E70EBE0exchange21_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii IGNvbnRlbnQ9Ikd0a0hUTUwvNC42LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQpIaSE8YnI+DQo8YnI+ DQpBcyBwYXJ0IG9mIGEgdGVtcGxhdGUgScK0bSBwcmVwYXJpbmcsIEnCtG0gd29uZGVyaW5nIGhv dyB0byBjb21waWxlIHRoZSBhZ2VudCB3aXRoIGp1c3QgdGhlIGJhc2ljcyBpbmNsdWRlZC4gScK0 dmUgdHJpZWQgcnVubmluZyBsaWtlOjxicj4NCjxicj4NCk9QVElPTlM9Jzxicj4NCi0td2l0aG91 dC1nZG0tcGx1Z2luIC0td2l0aG91dC1nZG0yLXBsdWdpbiZuYnNwOyAtLXdpdGhvdXQta2RtLXBs dWdpbiAtLXdpdGhvdXQtcGFtLW92aXJ0LWNyZWQ8YnI+DQotLXdpdGgtZ2RtLXBsdWdpbj1ubyAt LXdpdGgtZ2RtMi1wbHVnaW49bm8gLS13aXRoLWtkbS1wbHVnaW49bm8gLS13aXRoLXBhbS1vdmly dC1jcmVkPW5vPGJyPg0KLS1kaXNhYmxlLWdkbS1wbHVnaW4gLS1kaXNhYmxlLWdkbTItcGx1Z2lu IC0tZGlzYWJsZS1rZG0tcGx1Z2luIC0tZGlzYWJsZS1wYW0tb3ZpcnQtY3JlZDxicj4NCi0tZW5h YmxlLWdkbS1wbHVnaW49bm8gLS1lbmFibGUtZ2RtMi1wbHVnaW49bm8gLS1lbmFibGUta2RtLXBs dWdpbj1ubyAtLWVuYWJsZXBhbS1vdmlydC1jcmVkLT1ubyc8YnI+DQo8YnI+DQojIC4vY29uZmln dXJlICR7T1BUSU9OU308YnI+DQo8YnI+DQpSZWdhcmRsZXNzIG9mIGhvdyBJIHRyeSwgaXQganVz dCByZXNwb25kczo8YnI+DQpjb25maWd1cmU6IFdBUk5JTkc6IHVucmVjb2duaXplZCBvcHRpb25z OiAke09QVElPTlN9PGJyPg0KPGJyPg0KSSB0b29rIHRoZSBwYWNrYWdlIGZyb20gdGhlICZxdW90 O29mZmljaWFsJnF1b3Q7IG9WaXJ0Lm9yZyByZXBvLCBzcmMgZmlsZTo8YnI+DQpvdmlydC1ndWVz dC1hZ2VudC0xLjAuNi50YXIuYnoyPGJyPg0KPGJyPg0KV2hhdCBhbSBJIGRvaW5nIHdyb25nPzxi cj4NCjxicj4NCjx0YWJsZSBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIx MDAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZD4tLSA8YnI+DQo8YnI+DQpNZWQgVsOkbmxpZ2EgSMOk bHNuaW5nYXI8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KS2FybGkgU2rDtmJlcmc8 YnI+DQpTd2VkaXNoIFVuaXZlcnNpdHkgb2YgQWdyaWN1bHR1cmFsIFNjaWVuY2VzPGJyPg0KQm94 IDcwNzkgKFZpc2l0aW5nIEFkZHJlc3MgS3JvbsOlc3bDpGdlbiA4KTxicj4NClMtNzUwIDA3IFVw cHNhbGEsIFN3ZWRlbjxicj4NClBob25lOiAmbmJzcDsmIzQzOzQ2LSgwKTE4LTY3IDE1IDY2PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOmthcmxpLnNqb2JlcmdAYWRtLnNsdS5zZSI+a2FybGkuc2pvYmVy Z0BzbHUuc2U8L2E+IDwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_5F9E965F5A80BC468BE5F40576769F092E70EBE0exchange21_--

6 10

[Centos7.1x64] [Ovirt 3.5.2] Test fence : Power management test failed for Host hosted_engine1 Done
by wodel youchi 11 Jun '15

11 Jun '15

Hi, I have a weird problem with fencing I have a cluster of two HP DL380p G8 (ILO4) *Centos7.1x64 and oVirt 3.5.2 ALL UPDATED* I configured fencing first with *ilo4* then *ipmilan* When testing fence from the engine I get : Succeeded, Unknown And in alerts tab I get : Power management test failed for Host hosted_engine1 Done (the same for host2) I tested with fence_ilo4 and fence_ipmilan and they report the result correctly # fence_ipmilan -P -a 192.168.2.2 -o status -l Administrator -p ertyuiop -vExecuting: /usr/bin/ipmitool -I lanplus -H 192.168.2.2 -U Administrator -P ertyuiop -p 623 -L ADMINISTRATOR chassis power status 0 Chassis Power is on Status: ON # fence_ilo4 -l Administrator -p ertyuiop -a 192.168.2.2 -o status -v Executing: /usr/bin/ipmitool -I lanplus -H 192.168.2.2 -U Administrator -P ertyuiop -p 623 -L ADMINISTRATOR chassis power status 0 Chassis Power is on Status: ON ---------------------------------- These are the options passed to fence_ipmilan (I tested with the options and without them) lanplus="1", power_wait="60" This is the engine log: 2015-06-09 13:35:29,287 INFO [org.ovirt.engine.core.bll.FenceExecutor] (ajp--127.0.0.1-8702-7) Using Host hosted_engine_2 from cluster Default as proxy to execute Status command on Host 2015-06-09 13:35:29,289 INFO [org.ovirt.engine.core.bll.FenceExecutor] (ajp--127.0.0.1-8702-7) Executing <Status> Power Management command, Proxy Host:hosted_engine_2, Agent:ipmilan, Target Host:, Management IP:192.168.2.2, User:Administrator, Options: power_wait="60",lanplus="1", Fencing policy:null 2015-06-09 13:35:29,306 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (ajp--127.0.0.1-8702-7) START, FenceVdsVDSCommand( HostName = hosted_engine_2, HostId = 0192d1ac-b905-4660-b149-4bef578985dd, targetVdsId = cf2d1260-7bb3-451a-9cd7-80e6a0ede52a, action = Status, ip = 192.168.2.2, port = , type = ipmilan, user = Administrator, password = ******, options = ' power_wait="60",lanplus="1"', policy = 'null'), log id: 24ce6206 2015-06-09 13:35:29,516 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-7) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Power Management test failed for Host hosted_engine_1.Done 2015-06-09 13:35:29,516 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (ajp--127.0.0.1-8702-7) FINISH, FenceVdsVDSCommand, return: *Test Succeeded, unknown*, log id: 24ce6206 and here the vdsm log from the proxy JsonRpcServer::DEBUG::2015-06-09 13:37:52,461::__init__::506::jsonrpc.JsonRpcServer::(serve_requests) Waiting for request Thread-131907::DEBUG::2015-06-09 13:37:52,463::API::1209::vds::(fenceNode) fenceNode(addr=192.168.2.2,port=,agent=ipmilan,user=Administrator,passwd=XXXX,action=status,secure=False,options= power_wait="60" lanplus="1",policy=None) Thread-131907::DEBUG::2015-06-09 13:37:52,463::utils::739::root::(execCmd) /usr/sbin/fence_ipmilan (cwd None) Thread-131907::DEBUG::2015-06-09 13:37:52,533::utils::759::root::(execCmd) FAILED: <err> = 'Failed: Unable to obtain correct plug status or plug is not available\n\n\n'; <rc> = 1 Thread-131907::DEBUG::2015-06-09 13:37:52,533::API::1164::vds::(fence) rc 1 inp agent=fence_ipmilan ipaddr=192.168.2.2 login=Administrator action=status passwd=XXXX power_wait="60" lanplus="1" out [] err ['Failed: Unable to obtain correct plug status or plug is not available', '', ''] Thread-131907::DEBUG::2015-06-09 13:37:52,533::API::1235::vds::(fenceNode) rc 1 in agent=fence_ipmilan ipaddr=192.168.2.2 login=Administrator action=status passwd=XXXX power_wait="60" lanplus="1" out [] err ['*Failed: Unable to obtain correct plug status or plug is not available*', '', ''] Thread-131907::DEBUG::2015-06-09 13:37:52,534::stompReactor::163::yajsonrpc.StompServer::(send) Sending response Detector thread::DEBUG::2015-06-09 13:37:53,670::protocoldetector::187::vds.MultiProtocolAcceptor::(_add_connection) Adding connection from 127.0.0.1:55761 VDSM rpms # rpm -qa | grep vdsm vdsm-cli-4.16.14-0.el7.noarch vdsm-python-zombiereaper-4.16.14-0.el7.noarch vdsm-xmlrpc-4.16.14-0.el7.noarch vdsm-yajsonrpc-4.16.14-0.el7.noarch vdsm-4.16.14-0.el7.x86_64 vdsm-python-4.16.14-0.el7.noarch vdsm-jsonrpc-4.16.14-0.el7.noarch any idea? Thanks in advance.

3 9

Unable to use the SPICE HTML5 tool
by Nicolás 11 Jun '15

11 Jun '15

This is a multi-part message in MIME format. --------------040801010109090109090703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I'm using oVirt 3.5.2 on a CentOS box. As far as the engine goes everything is working fine, except that I can't start the SPICE HTML5 tool for any of the installed machines I have. I've installed the oVirt guest agent on the VM side, websocket-proxy is running and port 6100 is listening on the engine box: # systemctl status ovirt-websocket-proxy ovirt-websocket-proxy.service - oVirt Engine websockets proxy Loaded: loaded (/usr/lib/systemd/system/ovirt-websocket-proxy.service; enabled) Active: active (running) # netstat -atpn | grep 6100 tcp 0 0 0.0.0.0:6100 0.0.0.0:* LISTEN 7227/python Also, I imported the CA cert (https://fqdn/ca.crt) on the browser. However, once I run the SPICE HTML5 client from the userportal, all I get is an empty grey square with the two "Send ctrl+alt+delete" and "Toggle messages output" buttons at the bottom. Nothing in the logs about this issue. I tried to run it both with Chromium and Firefox on a linux box. Is there anything that I am missing? I've run out of ideas... Thanks. Nicolás --------------040801010109090109090703 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi,<br> <br> I'm using oVirt 3.5.2 on a CentOS box. As far as the engine goes everything is working fine, except that I can't start the SPICE HTML5 tool for any of the installed machines I have.<br> <br> I've installed the oVirt guest agent on the VM side, websocket-proxy is running and port 6100 is listening on the engine box:<br> <blockquote># systemctl status ovirt-websocket-proxy<br> ovirt-websocket-proxy.service - oVirt Engine websockets proxy<br> Loaded: loaded (/usr/lib/systemd/system/ovirt-websocket-proxy.service; enabled)<br> Active: active (running)<br> <br> # netstat -atpn | grep 6100<br> tcp 0 0 0.0.0.0:6100 0.0.0.0:* LISTEN 7227/python<br> </blockquote> Also, I imported the CA cert (<a class="moz-txt-link-freetext" href="https://fqdn/ca.crt">https://fqdn/ca.crt</a>) on the browser. However, once I run the SPICE HTML5 client from the userportal, all I get is an empty grey square with the two "Send ctrl+alt+delete" and "Toggle messages output" buttons at the bottom. Nothing in the logs about this issue. I tried to run it both with Chromium and Firefox on a linux box.<br> <br> Is there anything that I am missing? I've run out of ideas...<br> <br> Thanks.<br> <br> Nicolás<br> <br> <br> </body> </html> --------------040801010109090109090703--

5 7

Re: [ovirt-users] Comma Seperated Value doesn't accept by custom properties
by Punit Dambiwal 11 Jun '15

11 Jun '15

Hi Dan, Seems the problem is here :- ----------------------------- Thread-779::INFO::2015-06-09 09:04:05,204::hooks::100::root::(_runHooksDir) Thread-779::DEBUG::2015-06-09 09:04:05,205::utils::739::root::(execCmd) /usr/libexec/vdsm/hooks/before_vm_start/50_noipspoof (cwd None) Thread-779::DEBUG::2015-06-09 09:04:05,301::utils::759::root::(execCmd) FAILED: <err> = 'Traceback (most recent call last):\n File "/usr/libexec/vdsm/hooks/before_vm_start/50_noipspoof", line 85, in <module>\n main()\n File "/usr/libexec/vdsm/hooks/before_vm_start/50_noipspoof", line 52, in main\n interface, = domxml.getElementsByTagName(\'interface\')\nValueError: too many values to unpack\n'; <rc> = 1 Thread-779::INFO::2015-06-09 09:04:05,301::hooks::100::root::(_runHooksDir) Traceback (most recent call last): File "/usr/libexec/vdsm/hooks/before_vm_start/50_noipspoof", line 85, in <module> main() File "/usr/libexec/vdsm/hooks/before_vm_start/50_noipspoof", line 52, in main interface, = domxml.getElementsByTagName('interface') ValueError: too many values to unpack Thread-779::DEBUG::2015-06-09 09:04:05,301::vm::2294::vm.Vm::(_startUnderlyingVm) vmId=`600f6fa9-0c08-42ec-bbbd-939a07beb61c`::_ongoingCreations released Thread-779::ERROR::2015-06-09 09:04:05,302::vm::2331::vm.Vm::(_startUnderlyingVm) vmId=`600f6fa9-0c08-42ec-bbbd-939a07beb61c`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 2271, in _startUnderlyingVm self._run() File "/usr/share/vdsm/virt/vm.py", line 3299, in _run domxml = hooks.before_vm_start(self._buildCmdLine(), self.conf) File "/usr/share/vdsm/hooks.py", line 142, in before_vm_start return _runHooksDir(domxml, 'before_vm_start', vmconf=vmconf) File "/usr/share/vdsm/hooks.py", line 110, in _runHooksDir raise HookError() HookError Thread-779::DEBUG::2015-06-09 09:04:05,303::vm::2786::vm.Vm::(setDownStatus) vmId=`600f6fa9-0c08-42ec-bbbd-939a07beb61c`::Changed state to Down: VM terminated with error (code=1) --------------------- On Tue, Jun 9, 2015 at 9:13 AM, Punit Dambiwal <hypunit(a)gmail.com> wrote: > Hi Dan, > > Please find the Vdsm logs here :- > > 1. With 2 NIC (VM failed to bootup) :- http://paste.ubuntu.com/11660142/ > 2. Removed the secondary NIC and run the VM again....VM can bootup :- > http://paste.ubuntu.com/11660197/ > > Thanks, > Punit > > > > > On Mon, Jun 8, 2015 at 8:35 PM, Dan Kenigsberg <danken(a)redhat.com> wrote: > >> On Mon, Jun 08, 2015 at 05:43:40PM +0800, Punit Dambiwal wrote: >> > Hi Dan, >> > >> > Can save now the comma separate ip address...but still the problem >> > persists.... >> > >> > 1. If one Network interface...i can add multiple ip addresses with comma >> > separated... >> > 2. But if i add another network interface to this VM....VM cannot boot >> up... >> > 3. What need to do if i want to assign multiple ip address on multiple >> > network interface ?? >> >> Can you share your vdsm.log of this boot failure? >> >> Regards, >> Dan. >> > >

2 2