Re: [ovirt-users] sanlock ids file broken after server crash (Fixed)

[Johan Bernhardsson]

I have two options. One it got there when we moved the servers from our
lab desk to the hosting site. We had some problems getting it running. 

Or two a couple of weeks ago two servers rebooted after high load. That
might have caused a damage to the file.

I did manage to move all servers from that storage and removed it,
cleaned it and added it as a new storage.

Not what i wanted but it solved the problem.

/Johan

On Sun, 2017-07-30 at 16:24 +0300, Maor Lipchuk wrote:
> Hi David,
> 
> I'm not sure how it got to that character in the first place.
> Nir, Is there a safe way to fix that while there are running VMs?
> 
> Regards,
> Maor
> 
> On Sun, Jul 30, 2017 at 11:58 AM, Johan Bernhardsson 
> wrote:
> > 
> > (First reply did not get to the list)
> > 
> > From sanlock.log:
> > 
> > 2017-07-30 10:49:31+0200 1766275 [1171]: s310751 lockspace
> > 0924ff77-
> > ef51-435b-b90d-50bfbf2e8de7:1:/rhev/data-
> > center/mnt/glusterSD/vbgsan02:_fs02/0924ff77-ef51-435b-b90d-
> > 50bfbf2e8de7/dom_md/ids:0
> > 2017-07-30 10:49:31+0200 1766275 [10496]: verify_leader 1 wrong
> > space
> > name 0924ff77-ef51-435b-b90d-50bfbf2eke7 0924ff77-ef51-435b-
> > b90d-
> > 50bfbf2e8de7 /rhev/data-
> > center/mnt/glusterSD/vbgsan02:_fs02/0924ff77-
> > ef51-435b-b90d-50bfbf2e8de7/dom_md/ids
> > 2017-07-30 10:49:31+0200 1766275 [10496]: leader1
> > delta_acquire_begin
> > error -226 lockspace 0924ff77-ef51-435b-b90d-50bfbf2e8de7 host_id 1
> > 2017-07-30 10:49:31+0200 1766275 [10496]: leader2 path /rhev/data-
> > center/mnt/glusterSD/vbgsan02:_fs02/0924ff77-ef51-435b-b90d-
> > 50bfbf2e8de7/dom_md/ids offset 0
> > 2017-07-30 10:49:31+0200 1766275 [10496]: leader3 m 12212010 v
> > 30003 ss
> > 512 nh 0 mh 4076 oi 1 og 2031079063 lv 0
> > 2017-07-30 10:49:31+0200 1766275 [10496]: leader4 sn 0924ff77-ef51-
> > 435b-b90d-50bfbf2eke7 rn <93>7^\afa5-3a91-415b-a04c-
> > 221d3e060163.vbgkvm01.a ts 4351980 cs eefa4dd7
> > 2017-07-30 10:49:32+0200 1766276 [1171]: s310751 add_lockspace fail
> > result -226
> > 
> > 
> > vdsm logs doesnt have any errors and engine.log does not have any
> > errors.
> > 
> > And if i check the ids file manually. I can see that everything in
> > it
> > is correct except for the first host in the cluster where the space
> > name and host id is broken.
> > 
> > 
> > /Johan
> > 
> > On Sun, 2017-07-30 at 11:18 +0300, Maor Lipchuk wrote:
> > > 
> > > Hi Johan,
> > > 
> > > Can you please share the vdsm and engine logs.
> > > 
> > > Also, it won't harm to also get the sanlock logs just in case
> > > sanlock
> > > was configured to save all debugging in a log file (see
> > > http://people.redhat.com/teigland/sanlock-messages.txt)).
> > > Try to share the sanlock ouput by running  'sanlock client
> > > status',
> > > 'sanlock client log_dump'.
> > > 
> > > Regards,
> > > Maor
> > > 
> > > On Thu, Jul 27, 2017 at 6:18 PM, Johan Bernhardsson  > > se>
> > > wrote:
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > The ids file for sanlock is broken on one setup. The first host
> > > > id
> > > > in
> > > > the file is wrong.
> > > > 
> > > > From the logfile i have:
> > > > 
> > > > verify_leader 1 wrong space name 0924ff77-ef51-435b-b90d-
> > > > 50bfbf2e�ke7
> > > > 0924ff77-ef51-435b-b90d-50bfbf2e8de7 /rhev/data-
> > > > center/mnt/glusterSD/
> > > > 
> > > > 
> > > > 
> > > > Note the broken char in the space name.
> > > > 
> > > > This also apears. And it seams as the hostid too is broken in
> > > > the
> > > > ids
> > > > file:
> > > > 
> > > > leader4 sn 0924ff77-ef51-435b-b90d-50bfbf2e�ke7 rn ��7 afa5-
> > > > 3a91-
> > > > 415b-
> > > > a04c-221d3e060163.vbgkvm01.a ts 4351980 cs eefa4dd7
> > > > 
> > > > Note the broken chars there as well.
> > > > 
> > > > If i check the ids file with less or strings the first row
> > > > where my
> > > > vbgkvm01 host are. That has broken chars.
> > > > 
> > > > Can this be repaired in some way without taking down all the
> > > > virtual
> > > > machines on that storage?
> > > > 
> > > > 
> > > > /Johan
> > > > ___
> > > > Users mailing list
> > > > Users@ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Pass Discard guest OS support?

[Yaniv Kaul]

On Tue, Aug 1, 2017 at 6:05 PM, Doug Ingham  wrote:

> Hi All,
>  Just today I noticed that guests can now pass discards to the underlying
> shared filesystem.
>

Or block storage. Most likely it works better on shared block storage.


>
> http://www.ovirt.org/develop/release-management/features/
> storage/pass-discard-from-guest-to-underlying-storage/
>
> Is this supported by all of the main Linux guest OS's running the virt
> agent?
>

It has nothing to do with the virt agent.
It is supported by all main and modern Linux guest OS. Depends mainly on
your mount options or your use of 'fstrim' or 'blkdiscard' utils.


> And what about Windows guests? (specifically, 2012 & 2016)
>

Yes to both.
Y.


>
> Cheers,
> --
> Doug
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] supervdsmd IOError to /dev/stdout

[Nir Soffer]

On Tue, Aug 1, 2017 at 3:07 PM Richard Chan 
wrote:

> Hi,
>
> Could this be the cause of the access issue (old system upgraded from 3.4
> all the way to 4.1)?
> ## change in python class name??
>
>  [handler_logfile]
> -class=logUtils.UserGroupEnforcingHandler
> +class=vdsm.logUtils.UserGroupEnforcingHandler
>
> When I copied  svdsm.logger.conf.rpmnew over svdsm.logger.conf, it could
> start up.
>

If this is the case, I don't think we should change anything.

Logging to syslog by default is problematic, we don't want to spam systlog
with unimportant debug logs.

Nir


>
> Thanks!
>
>
>
> On Tue, Aug 1, 2017 at 5:02 PM, Yaniv Bronheim 
> wrote:
>
>> Hi,
>>
>> Seems like I already bumped in such issue awhile ago -
>> https://bugzilla.redhat.com/show_bug.cgi?id=1216880
>> but now I see what's wrong -  it happens after failing to read
>> /etc/vdsm/svdsm.logger.conf for some reason
>> then we have a bug in our fallback which tries to run
>> logging.basicConfig(filename='/dev/stdout', filemode='w+',
>> level=logging.DEBUG)
>>
>> and this fails while running as systemd daemon
>>
>> sorry about that. check why it can't load  /etc/vdsm/svdsm.logger.conf
>> and update us
>> after fixing the access issue check if you can run
>> logging.config.fileConfig("/etc/vdsm/svdsm.logger.conf" ,
>> disable_existing_loggers=False)
>> Then supervdsmd should start properly
>>
>> I'll reopen the bugzilla and fix the wrong fallback to syslog print
>>
>> Thanks!
>>
>>
>> On Sun, Jul 30, 2017 at 3:23 PM Richard Chan <
>> rich...@treeboxsolutions.com> wrote:
>>
>>> Hi Yaniv,
>>>
>>> On this one node, it happened from 3.6 -> 4.0. It persisted after
>>> 4.0->4.1.
>>> Current: vdsm-4.19.24-1.el7.centos.x86_64
>>>
>>>
>>> In systemd override I now have to have:
>>> StandardOutput=null
>>>
>>>
>>>
>>>
>>> Jul 29 01:19:21  systemd[1]: Starting Auxiliary vdsm service for
>>> running helper functions as root...
>>> Jul 29 01:19:21  python2[39124]: detected unhandled Python
>>> exception in '/usr/share/vdsm/supervdsmServer'
>>> Jul 29 01:19:21  daemonAdapter[39124]: Traceback (most recent
>>> call last):
>>> Jul 29 01:19:21  daemonAdapter[39124]: File
>>> "/usr/share/vdsm/supervdsmServer", line 45, in 
>>> Jul 29 01:19:21  daemonAdapter[39124]: level=logging.DEBUG)
>>> Jul 29 01:19:21  daemonAdapter[39124]: File
>>> "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig
>>> Jul 29 01:19:21  daemonAdapter[39124]: hdlr =
>>> FileHandler(filename, mode)
>>> Jul 29 01:19:21  daemonAdapter[39124]: File
>>> "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__
>>> Jul 29 01:19:21  daemonAdapter[39124]:
>>> StreamHandler.__init__(self, self._open())
>>> Jul 29 01:19:21  daemonAdapter[39124]: File
>>> "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open
>>> Jul 29 01:19:21  daemonAdapter[39124]: stream =
>>> open(self.baseFilename, self.mode)
>>> Jul 29 01:19:21  daemonAdapter[39124]: IOError: [Errno 6] No
>>> such device or address: '/dev/stdout'
>>> Jul 29 01:19:21  systemd[1]: supervdsmd.service: main process
>>> exited, code=exited, status=1/FAILURE
>>>
>>>
>>>
>>> On Sun, Jul 30, 2017 at 3:47 PM, Yaniv Kaul  wrote:
>>>


 On Fri, Jul 28, 2017 at 8:37 PM, Richard Chan <
 rich...@treeboxsolutions.com> wrote:

> After an upgrade to 4.0 I have a single host that cannot start
> supervdsmd because of IOError on /dev/stdout. All other hosts upgraded
> correctly.
>

 Upgrade from which version? 3.6? Did you stay on 4.0 or continued to
 4.1?


>
> In the systemd unit I have to hack StandardOutput=null.
>
> Any thing I have overlooked? The hosts are all identical and it is
> just this one
> that has this weird behaviour.
>

 Any logs that you can share?
  Y.


>
> --
> Richard Chan
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>

>>>
>>>
>>> --
>>> Richard Chan
>>> Chief Architect
>>>
>>> TreeBox Solutions Pte Ltd
>>> 1 Commonwealth Lane #03-01
>>> Singapore 149544
>>> Tel: 6570 3725
>>> http://www.treeboxsolutions.com
>>>
>>> Co.Reg.No. 201100585R
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>> --
>> Yaniv Bronhaim.
>>
>
>
>
> --
> Richard Chan
> Chief Architect
>
> TreeBox Solutions Pte Ltd
> 1 Commonwealth Lane #03-01
> Singapore 149544
> Tel: 6570 3725
> http://www.treeboxsolutions.com
>
> Co.Reg.No. 201100585R
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>

Re: [ovirt-users] oVirt and Foreman

[Juan Hernández]

On 07/28/2017 06:03 PM, Davide Ferrari wrote:



On 28/07/17 17:46, Juan Hernández wrote:


The oVirt access log indeed shows that three disks are added to the 
virtual machine. May it be that Foreman thinks that it has to 
explicitly add a boot disk? Ohad, Ivan, any idea?




I've explicitly added the template id to the hammer command line and 
still adds 3 disks but at least now two of them respect the size I'm 
passing through Hammer. But it still sets a random disk as the bootable 
one and I cannot find a way to force to use the disk already present in 
the oVirt template as the bootable one
Is there a way in oVirt to log the JSONs passed in the various POST 
requests?




There is no such mechanism available by default You can get some more 
information about the requests and responses using the WildFly request 
dumping filter, but it won't give you the request or response bodies. If 
you want to do that first you need to go to the oVirt engine machine and 
start the "jboss-cli.sh" tool:


  # /usr/share/ovirt-engine-wildfly/bin/jboss-cli.sh \
  --controller=localhost:8706 \
  --user=admin@internal \
  --connect

That will as for the password of the "admin@internal" user, and then it 
should display you a prompt like this:


  [standalone@localhost:8706 /]

In that prompt you can type any WildFly management command. For more 
information see here:


  https://docs.jboss.org/author/display/WFLY/Command+Line+Interface

In this particular case you can first add the request dumping filter to 
the configuration, typing the following command:


  /subsystem=undertow/configuration=filter/custom-filter=myfilter:\
 add(class-name=io.undertow.server.handlers.RequestDumpingHandler,\
  module=io.undertow.core)

Then you can enable that filter for the /ovirt-engine/api/* URL:


/subsystem=undertow/server=default-server/host=default-host/filter-ref=myfilter:add(predicate="regex['/ovirt-engine/api.*']")

Note again that this won't give you the request and response bodies, so 
it may not be worth.


Another thing you may want to try, in the Foreman side, is to modify the 
"rbovirt" gem so it writes the request bodies to some place. For 
example, you can locate the "rbovirt.rb" file in your Foreman 
installation, and then, after this line:


  https://github.com/abenari/rbovirt/blob/v0.1.3/lib/rbovirt.rb#L131

Add something that writes the request body to a file, for example:

  open('/tmp/mylog', 'a') { |f| f.write(body) }

Then you will probably need to restart Foreman.

Remember to restore the "rbovirt.rb" file when you finish.



More over, looking at 
/ovirt-engine/api/vms/47f5035a-696c-4578-ace9-b23d865c6aa7/disks it 
throws a 404, the endpoint seems to be 
/ovirt-engine/api/vms/47f5035a-696c-4578-ace9-b23d865c6aa7/diskattachments 
while 
/ovirt-engine/api/vms/47f5035a-696c-4578-ace9-b23d865c6aa7/disks 
seems to work only with API v3. Maybe I should change the base URL 
for the ovirt's API in foreman config, shouldn't I?




I think you don't need to change anything there. Foreman uses 
'rbovirt', and 'rbovirt' explicitly requests version 3 of the API 
using the 'Version: 3' header. 


Well, I've added it anyway and it didn't break anything :)



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

[ovirt-users] Pass Discard guest OS support?

[Doug Ingham]

Hi All,
 Just today I noticed that guests can now pass discards to the underlying
shared filesystem.

http://www.ovirt.org/develop/release-management/features/storage/pass-discard-from-guest-to-underlying-storage/

Is this supported by all of the main Linux guest OS's running the virt
agent?
And what about Windows guests? (specifically, 2012 & 2016)

Cheers,
-- 
Doug
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt 4.1.2 update but rubygem-fluent-plugin-viaq_data_model package missing

[Sandro Bonazzola]

On Tue, Aug 1, 2017 at 3:36 PM, Fabrice Moyen 
wrote:

>
> Hello,
>
> I'm running Ovirt 4.1.2 onto ppc64le platforms (running centOS 7 LE). I
> see my ovirt manager has an issue upgrading my two hosts. When checking at
> the engine.log log, I can see the following error message:
>
> 2017-07-28 12:14:42,747+02 ERROR 
> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
> (VdsDeploy) [3693cd62] Yum: Cannot queue package 
> rubygem-fluent-plugin-viaq_data_model:
> Package rubygem-fluent-plugin-viaq_data_model cannot be found
>
> Indeed, when manually looking for this package, it is not available.
>


I'm sorry for that. The packages has been built and tagged for release:
http://cbs.centos.org/koji/buildinfo?buildID=17377
We are experiencing issues with ppc64le releases on CentOS, in the
meanwhile, please add the following repo as workaround:
https://cbs.centos.org/repos/opstools7-fluentd-012-release/ppc64le/os/




>
> I read here http://lists.ovirt.org/pipermail/users/2017-July/083070.html that
> it is new this package is needed starting with ovirt 4.1.3, so I guess
> that's why the ovirt upgrade process is now looking for it.
>
> Where should we find this package ? Centos7 repos ? ovirt4.1 repos ? I did
> not find it in both repos.
>
> Any help or clue ?
>
> Best Regards / Cordialement
>
> Fabrice MOYEN
> Power Systems Linux Center
> Cognitive Systems Lab
>
> IBM Client Center Montpellier
> P.I.T. La Pompignane C.S 81021
> 34060 MONTPELLIER Cedex 2
> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
> Compagnie IBM France
> Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex
> RCS Nanterre 552 118 465
> Forme Sociale : S.A.S.
> Capital Social : 657.364.587 €
> SIREN/SIRET : 552 118 465 03644 - Code NAF 6202A
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>


-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

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

Re: [ovirt-users] After upgrading to 4.1.4 unable to start VM or migrate them

[Arman Khalatyan]

It is unclear now, I am not able to reproduce the error...probably changing
the policy fixed the "null" record in the database.
My upgrade went w/o error from 4.1.3 to 4.1.4.
The engine.log from yesterday is here: with the password:BUG
https://cloud.aip.de/index.php/s/N6xY0gw3GdEf63H (I hope I am not imposing
the sensitive data:) 

most often errors are:
2017-07-31 15:17:08,547+02 ERROR
[org.ovirt.engine.core.bll.MigrateVmCommand] (default task-263)
[47ea10c5-0152-4512-ab07-086c59370190] Error during ValidateFailure.:
java.lang.NullPointerException

and

2017-07-31 15:17:10,729+02 ERROR
[org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl]
(DefaultQuartzScheduler4) [11ad31d3] Failed to invoke scheduled method
performLoadBalancing: null

On Tue, Aug 1, 2017 at 12:01 PM, Doron Fediuck  wrote:

> Yes, none is a valid policy assuming you don't need any special
> considerations when running a VM.
> If you could gather the relevant log entries and the error you see and
> open a new bug it'll help us
> track and fix the issue.
> Please specify exactly from which engine version you upgraded and into
> which version.
>
> On 1 August 2017 at 11:47, Arman Khalatyan  wrote:
>
>> Thank you for your response,
>> I am looking now in to records of the menu "Scheduling Policy": there is
>> an entry "none", is it suppose to be there??
>> Because when I selecting it then error occurs.
>>
>>
>> On Tue, Aug 1, 2017 at 10:35 AM, Yanir Quinn  wrote:
>>
>>> Thanks for the update, we will check if there is a bug in the upgrade
>>> process
>>>
>>> On Mon, Jul 31, 2017 at 6:32 PM, Arman Khalatyan 
>>> wrote:
>>>
 Ok I found the ERROR:
 After upgrade the schedule policy was "none", I dont know why it was
 moved to none but to fix the problem I did following:
 Edit Cluster->Scheduling Policy-> Select Policy: vm_evently_distributed
 Now I can run/migrate the VMs.

 I think there should be a some bug in the upgrade process.


 On Mon, Jul 31, 2017 at 5:11 PM, Arman Khalatyan 
 wrote:

> Looks like renewed certificates problem, in the
> ovirt-engine-setup-xx-xx.log I found following lines:
> Are there way to fix it?
>
>
> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
> up.ovirt_engine.pki.ca ca._enrollCertificates:330 processing:
> 'engine'[renew=True]
> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
> up.ovirt_engine.pki.ca plugin.executeRaw:813 execute:
> ('/bin/openssl', 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12',
> '-passin', 'pass:**FILTERED**', '-nokeys'), executable='None', cwd='None',
> env=None
> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
> up.ovirt_engine.pki.ca plugin.executeRaw:863 execute-result:
> ('/bin/openssl', 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12',
> '-passin', 'pass:**FILTERED**', '-nokeys'), rc=0
> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
> up.ovirt_engine.pki.ca plugin.execute:921 execute-output:
> ('/bin/openssl', 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12',
> '-passin', 'pass:**FILTERED**', '-nokeys') stdout:
> Bag Attributes
>
>
> On Mon, Jul 31, 2017 at 4:54 PM, Arman Khalatyan 
> wrote:
>
>> Sorry, I forgot to mention the error.
>> This error throws every time when I try to start the VM:
>>
>> 2017-07-31 16:51:07,297+02 ERROR [org.ovirt.engine.core.bll.RunVmCommand]
>> (default task-239) [7848103c-98dc-45d1-b99a-4713e3b8e956] Error
>> during ValidateFailure.: java.lang.NullPointerException
>> at org.ovirt.engine.core.bll.sche
>> duling.SchedulingManager.canSchedule(SchedulingManager.java:526)
>> [bll.jar:]
>> at org.ovirt.engine.core.bll.vali
>> dator.RunVmValidator.canRunVm(RunVmValidator.java:157) [bll.jar:]
>> at org.ovirt.engine.core.bll.RunV
>> mCommand.validate(RunVmCommand.java:967) [bll.jar:]
>> at org.ovirt.engine.core.bll.Comm
>> andBase.internalValidate(CommandBase.java:836) [bll.jar:]
>> at org.ovirt.engine.core.bll.Comm
>> andBase.validateOnly(CommandBase.java:365) [bll.jar:]
>> at org.ovirt.engine.core.bll.Prev
>> alidatingMultipleActionsRunner.canRunActions(PrevalidatingMultipleActionsRunner.java:113)
>> [bll.jar:]
>> at org.ovirt.engine.core.bll.Prev
>> alidatingMultipleActionsRunner.invokeCommands(PrevalidatingMultipleActionsRunner.java:99)
>> [bll.jar:]
>> at org.ovirt.engine.core.bll.Prev
>> alidatingMultipleActionsRunner.execute(PrevalidatingMultipleActionsRunner.java:76)
>> [bll.jar:]
>> at org.ovirt.engine.core.bll.Back
>> end.runMultipleActionsImpl(Backend.java:640) [bll.jar:]
>> 

[ovirt-users] oVirt 4.1.2 update but rubygem-fluent-plugin-viaq_data_model package missing

[Fabrice Moyen]

 
Hello, 
 
I'm running Ovirt 4.1.2 onto ppc64le platforms (running centOS 7 LE). I see my ovirt manager has an issue upgrading my two hosts. When checking at the engine.log log, I can see the following error message:
 
2017-07-28 12:14:42,747+02 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [3693cd62] Yum: Cannot queue package rubygem-fluent-plugin-viaq_data_model: Package rubygem-fluent-plugin-viaq_data_model cannot be found 
Indeed, when manually looking for this package, it is not available. 
 
I read here http://lists.ovirt.org/pipermail/users/2017-July/083070.html that it is new this package is needed starting with ovirt 4.1.3, so I guess that's why the ovirt upgrade process is now looking for it. 
 
Where should we find this package ? Centos7 repos ? ovirt4.1 repos ? I did not find it in both repos.
 
Any help or clue ?
Best Regards / Cordialement 
Fabrice MOYENPower Systems Linux Center
Cognitive Systems Lab
IBM Client Center Montpellier     P.I.T. La Pompignane C.S 8102134060 MONTPELLIER Cedex 2Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 657.364.587 €
SIREN/SIRET : 552 118 465 03644 - Code NAF 6202A

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

[ovirt-users] Install external certificate

[Marcelo Leandro]

Good morning

I bought a external certificate, in godaddy , and they send to me only
one archive crt. I saw this:
https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/

I don't know how I can generate a certificate p12.
Can someone help me ?

Thanks.

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

Re: [ovirt-users] Deploying training lab

[David Jaša]

Hi,

This sounds like something that might fit your needs:
https://github.com/ThinStation/thinstation
and the looks alive.

I didn't try it myself though.

If you're not satisfied with this or any other existing distro, you
could either slim down an existing distro (e.g. creating your own lean
Fedora spin) or build your own with minimum set of dependencies (e.g.
Gentoo is quite friendly to this approach).

Let us know what solution did you choose and how it went. ;)

Cheers,

David Jaša,
Spice QE


On Fri, 2017-07-28 at 21:19 +0200, Andy Michielsen wrote:
> Hello all,
> 
> Don't know if this is the right place to ask this but I would like to
> set up a trainingslab with oVirt.
> 
> I have deployed an engine and a host with local storage and want to
> run 1 server and 5 desktops off it.
> 
> But the desktops will be used on thin clients or old laptops with
> some minimal os installation running spice client or a webbrowser.
> 
> I was wondering if anyone can give me pointer in how to set up a
> minimal laptop which only need to run an spice client.
> 
> Kind regards. 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] supervdsmd IOError to /dev/stdout

[Richard Chan]

Hi,

Could this be the cause of the access issue (old system upgraded from 3.4
all the way to 4.1)?
## change in python class name??

 [handler_logfile]
-class=logUtils.UserGroupEnforcingHandler
+class=vdsm.logUtils.UserGroupEnforcingHandler

When I copied  svdsm.logger.conf.rpmnew over svdsm.logger.conf, it could
start up.

Thanks!



On Tue, Aug 1, 2017 at 5:02 PM, Yaniv Bronheim  wrote:

> Hi,
>
> Seems like I already bumped in such issue awhile ago -
> https://bugzilla.redhat.com/show_bug.cgi?id=1216880
> but now I see what's wrong -  it happens after failing to read
> /etc/vdsm/svdsm.logger.conf for some reason
> then we have a bug in our fallback which tries to run
> logging.basicConfig(filename='/dev/stdout', filemode='w+',
> level=logging.DEBUG)
>
> and this fails while running as systemd daemon
>
> sorry about that. check why it can't load  /etc/vdsm/svdsm.logger.conf
> and update us
> after fixing the access issue check if you can run
> logging.config.fileConfig("/etc/vdsm/svdsm.logger.conf" ,
> disable_existing_loggers=False)
> Then supervdsmd should start properly
>
> I'll reopen the bugzilla and fix the wrong fallback to syslog print
>
> Thanks!
>
>
> On Sun, Jul 30, 2017 at 3:23 PM Richard Chan 
> wrote:
>
>> Hi Yaniv,
>>
>> On this one node, it happened from 3.6 -> 4.0. It persisted after
>> 4.0->4.1.
>> Current: vdsm-4.19.24-1.el7.centos.x86_64
>>
>>
>> In systemd override I now have to have:
>> StandardOutput=null
>>
>>
>>
>>
>> Jul 29 01:19:21  systemd[1]: Starting Auxiliary vdsm service for
>> running helper functions as root...
>> Jul 29 01:19:21  python2[39124]: detected unhandled Python
>> exception in '/usr/share/vdsm/supervdsmServer'
>> Jul 29 01:19:21  daemonAdapter[39124]: Traceback (most recent
>> call last):
>> Jul 29 01:19:21  daemonAdapter[39124]: File 
>> "/usr/share/vdsm/supervdsmServer",
>> line 45, in 
>> Jul 29 01:19:21  daemonAdapter[39124]: level=logging.DEBUG)
>> Jul 29 01:19:21  daemonAdapter[39124]: File
>> "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig
>> Jul 29 01:19:21  daemonAdapter[39124]: hdlr =
>> FileHandler(filename, mode)
>> Jul 29 01:19:21  daemonAdapter[39124]: File
>> "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__
>> Jul 29 01:19:21  daemonAdapter[39124]:
>> StreamHandler.__init__(self, self._open())
>> Jul 29 01:19:21  daemonAdapter[39124]: File
>> "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open
>> Jul 29 01:19:21  daemonAdapter[39124]: stream =
>> open(self.baseFilename, self.mode)
>> Jul 29 01:19:21  daemonAdapter[39124]: IOError: [Errno 6] No such
>> device or address: '/dev/stdout'
>> Jul 29 01:19:21  systemd[1]: supervdsmd.service: main process
>> exited, code=exited, status=1/FAILURE
>>
>>
>>
>> On Sun, Jul 30, 2017 at 3:47 PM, Yaniv Kaul  wrote:
>>
>>>
>>>
>>> On Fri, Jul 28, 2017 at 8:37 PM, Richard Chan <
>>> rich...@treeboxsolutions.com> wrote:
>>>
 After an upgrade to 4.0 I have a single host that cannot start
 supervdsmd because of IOError on /dev/stdout. All other hosts upgraded
 correctly.

>>>
>>> Upgrade from which version? 3.6? Did you stay on 4.0 or continued to 4.1?
>>>
>>>

 In the systemd unit I have to hack StandardOutput=null.

 Any thing I have overlooked? The hosts are all identical and it is just
 this one
 that has this weird behaviour.

>>>
>>> Any logs that you can share?
>>>  Y.
>>>
>>>

 --
 Richard Chan


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


>>>
>>
>>
>> --
>> Richard Chan
>> Chief Architect
>>
>> TreeBox Solutions Pte Ltd
>> 1 Commonwealth Lane #03-01
>> Singapore 149544
>> Tel: 6570 3725
>> http://www.treeboxsolutions.com
>>
>> Co.Reg.No. 201100585R
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
> --
> Yaniv Bronhaim.
>



-- 
Richard Chan
Chief Architect

TreeBox Solutions Pte Ltd
1 Commonwealth Lane #03-01
Singapore 149544
Tel: 6570 3725
http://www.treeboxsolutions.com

Co.Reg.No. 201100585R
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] After upgrading to 4.1.4 unable to start VM or migrate them

[Doron Fediuck]

Yes, none is a valid policy assuming you don't need any special
considerations when running a VM.
If you could gather the relevant log entries and the error you see and open
a new bug it'll help us
track and fix the issue.
Please specify exactly from which engine version you upgraded and into
which version.

On 1 August 2017 at 11:47, Arman Khalatyan  wrote:

> Thank you for your response,
> I am looking now in to records of the menu "Scheduling Policy": there is
> an entry "none", is it suppose to be there??
> Because when I selecting it then error occurs.
>
>
> On Tue, Aug 1, 2017 at 10:35 AM, Yanir Quinn  wrote:
>
>> Thanks for the update, we will check if there is a bug in the upgrade
>> process
>>
>> On Mon, Jul 31, 2017 at 6:32 PM, Arman Khalatyan 
>> wrote:
>>
>>> Ok I found the ERROR:
>>> After upgrade the schedule policy was "none", I dont know why it was
>>> moved to none but to fix the problem I did following:
>>> Edit Cluster->Scheduling Policy-> Select Policy: vm_evently_distributed
>>> Now I can run/migrate the VMs.
>>>
>>> I think there should be a some bug in the upgrade process.
>>>
>>>
>>> On Mon, Jul 31, 2017 at 5:11 PM, Arman Khalatyan 
>>> wrote:
>>>
 Looks like renewed certificates problem, in the
 ovirt-engine-setup-xx-xx.log I found following lines:
 Are there way to fix it?


 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
 up.ovirt_engine.pki.ca ca._enrollCertificates:330 processing:
 'engine'[renew=True]
 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
 up.ovirt_engine.pki.ca plugin.executeRaw:813 execute: ('/bin/openssl',
 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12', '-passin',
 'pass:**FILTERED**', '-nokeys'), executable='None', cwd='None', env=None
 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
 up.ovirt_engine.pki.ca plugin.executeRaw:863 execute-result:
 ('/bin/openssl', 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12',
 '-passin', 'pass:**FILTERED**', '-nokeys'), rc=0
 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
 up.ovirt_engine.pki.ca plugin.execute:921 execute-output:
 ('/bin/openssl', 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12',
 '-passin', 'pass:**FILTERED**', '-nokeys') stdout:
 Bag Attributes


 On Mon, Jul 31, 2017 at 4:54 PM, Arman Khalatyan 
 wrote:

> Sorry, I forgot to mention the error.
> This error throws every time when I try to start the VM:
>
> 2017-07-31 16:51:07,297+02 ERROR [org.ovirt.engine.core.bll.RunVmCommand]
> (default task-239) [7848103c-98dc-45d1-b99a-4713e3b8e956] Error
> during ValidateFailure.: java.lang.NullPointerException
> at org.ovirt.engine.core.bll.sche
> duling.SchedulingManager.canSchedule(SchedulingManager.java:526)
> [bll.jar:]
> at org.ovirt.engine.core.bll.vali
> dator.RunVmValidator.canRunVm(RunVmValidator.java:157) [bll.jar:]
> at org.ovirt.engine.core.bll.RunV
> mCommand.validate(RunVmCommand.java:967) [bll.jar:]
> at org.ovirt.engine.core.bll.Comm
> andBase.internalValidate(CommandBase.java:836) [bll.jar:]
> at org.ovirt.engine.core.bll.Comm
> andBase.validateOnly(CommandBase.java:365) [bll.jar:]
> at org.ovirt.engine.core.bll.Prev
> alidatingMultipleActionsRunner.canRunActions(PrevalidatingMultipleActionsRunner.java:113)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Prev
> alidatingMultipleActionsRunner.invokeCommands(PrevalidatingMultipleActionsRunner.java:99)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Prev
> alidatingMultipleActionsRunner.execute(PrevalidatingMultipleActionsRunner.java:76)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Back
> end.runMultipleActionsImpl(Backend.java:640) [bll.jar:]
> at org.ovirt.engine.core.bll.Back
> end.runMultipleActions(Backend.java:610) [bll.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) [rt.jar:1.8.0_141]
> at sun.reflect.NativeMethodAccess
> orImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_141]
> at sun.reflect.DelegatingMethodAc
> cessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_141]
> at java.lang.reflect.Method.invoke(Method.java:498)
> [rt.jar:1.8.0_141]
> at org.jboss.as.ee.component.Mana
> gedReferenceMethodInterceptor.processInvocation(ManagedRefer
> enceMethodInterceptor.java:52)
> at org.jboss.invocation.Intercept
> orContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.Intercept
> orContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299Bi
> 

Re: [ovirt-users] After upgrading to 4.1.4 unable to start VM or migrate them

[Arman Khalatyan]

Thank you for your response,
I am looking now in to records of the menu "Scheduling Policy": there is an
entry "none", is it suppose to be there??
Because when I selecting it then error occurs.


On Tue, Aug 1, 2017 at 10:35 AM, Yanir Quinn  wrote:

> Thanks for the update, we will check if there is a bug in the upgrade
> process
>
> On Mon, Jul 31, 2017 at 6:32 PM, Arman Khalatyan 
> wrote:
>
>> Ok I found the ERROR:
>> After upgrade the schedule policy was "none", I dont know why it was
>> moved to none but to fix the problem I did following:
>> Edit Cluster->Scheduling Policy-> Select Policy: vm_evently_distributed
>> Now I can run/migrate the VMs.
>>
>> I think there should be a some bug in the upgrade process.
>>
>>
>> On Mon, Jul 31, 2017 at 5:11 PM, Arman Khalatyan 
>> wrote:
>>
>>> Looks like renewed certificates problem, in the
>>> ovirt-engine-setup-xx-xx.log I found following lines:
>>> Are there way to fix it?
>>>
>>>
>>> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
>>> up.ovirt_engine.pki.ca ca._enrollCertificates:330 processing:
>>> 'engine'[renew=True]
>>> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
>>> up.ovirt_engine.pki.ca plugin.executeRaw:813 execute: ('/bin/openssl',
>>> 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12', '-passin',
>>> 'pass:**FILTERED**', '-nokeys'), executable='None', cwd='None', env=None
>>> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
>>> up.ovirt_engine.pki.ca plugin.executeRaw:863 execute-result:
>>> ('/bin/openssl', 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12',
>>> '-passin', 'pass:**FILTERED**', '-nokeys'), rc=0
>>> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
>>> up.ovirt_engine.pki.ca plugin.execute:921 execute-output:
>>> ('/bin/openssl', 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12',
>>> '-passin', 'pass:**FILTERED**', '-nokeys') stdout:
>>> Bag Attributes
>>>
>>>
>>> On Mon, Jul 31, 2017 at 4:54 PM, Arman Khalatyan 
>>> wrote:
>>>
 Sorry, I forgot to mention the error.
 This error throws every time when I try to start the VM:

 2017-07-31 16:51:07,297+02 ERROR [org.ovirt.engine.core.bll.RunVmCommand]
 (default task-239) [7848103c-98dc-45d1-b99a-4713e3b8e956] Error during
 ValidateFailure.: java.lang.NullPointerException
 at org.ovirt.engine.core.bll.scheduling.SchedulingManager.canSc
 hedule(SchedulingManager.java:526) [bll.jar:]
 at 
 org.ovirt.engine.core.bll.validator.RunVmValidator.canRunVm(RunVmValidator.java:157)
 [bll.jar:]
 at 
 org.ovirt.engine.core.bll.RunVmCommand.validate(RunVmCommand.java:967)
 [bll.jar:]
 at 
 org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:836)
 [bll.jar:]
 at 
 org.ovirt.engine.core.bll.CommandBase.validateOnly(CommandBase.java:365)
 [bll.jar:]
 at org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner
 .canRunActions(PrevalidatingMultipleActionsRunner.java:113) [bll.jar:]
 at org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner
 .invokeCommands(PrevalidatingMultipleActionsRunner.java:99) [bll.jar:]
 at org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner
 .execute(PrevalidatingMultipleActionsRunner.java:76) [bll.jar:]
 at 
 org.ovirt.engine.core.bll.Backend.runMultipleActionsImpl(Backend.java:640)
 [bll.jar:]
 at 
 org.ovirt.engine.core.bll.Backend.runMultipleActions(Backend.java:610)
 [bll.jar:]
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [rt.jar:1.8.0_141]
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 [rt.jar:1.8.0_141]
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 [rt.jar:1.8.0_141]
 at java.lang.reflect.Method.invoke(Method.java:498)
 [rt.jar:1.8.0_141]
 at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.
 processInvocation(ManagedReferenceMethodInterceptor.java:52)
 at org.jboss.invocation.InterceptorContext.proceed(InterceptorC
 ontext.java:340)
 at org.jboss.invocation.InterceptorContext$Invocation.proceed(I
 nterceptorContext.java:437)
 at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInte
 rception(Jsr299BindingsInterceptor.java:70)
 [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
 at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInte
 rception(Jsr299BindingsInterceptor.java:80)
 [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
 at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvoc
 ation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.1.0.Final.jar
 :10.1.0.Final]
 at 

Re: [ovirt-users] After upgrading to 4.1.4 unable to start VM or migrate them

[Jiri Belka]

> Ok I found the ERROR:
> After upgrade the schedule policy was "none", I dont know why it was moved to
> none but to fix the problem I did following:
> Edit Cluster->Scheduling Policy-> Select Policy: vm_evently_distributed
> Now I can run/migrate the VMs.
> 
> I think there should be a some bug in the upgrade process.

Well, if you would like to help us to find the cause then we need to know more 
details.

- what was your original version?
- what was your original scheduling policy on the cluster
- could you provide
  * /var/log/ovirt-engine/setup/ovirt-engine-setup-20170801112218-piffzl.log
  * /var/log/ovirt-engine/engine.log

You have backup of your original engine DB in /var/lib/ovirt-engine/backups/,
thus you can import this DB via psql into a temporary DB and inspect the DB
for original settings.

Ideally you can submit a BZ at 
https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt

j.

> Sorry, I forgot to mention the error.
> This error throws every time when I try to start the VM:
> 
> 2017-07-31 16:51:07,297+02 ERROR [org.ovirt.engine.core.bll.RunVmCommand]
> (default task-239) [7848103c-98dc-45d1-b99a-4713e3b8e956] Error during
> ValidateFailure.: java.lang.NullPointerException
> at
> org.ovirt.engine.core.bll.scheduling.SchedulingManager.canSchedule(SchedulingManager.java:526)
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.validator.RunVmValidator.canRunVm(RunVmValidator.java:157)
> [bll.jar:]
> at org.ovirt.engine.core.bll.RunVmCommand.validate(RunVmCommand.java:967)
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:836)
> [bll.jar:]
> at org.ovirt.engine.core.bll.CommandBase.validateOnly(CommandBase.java:365)
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.canRunActions(PrevalidatingMultipleActionsRunner.java:113)
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.invokeCommands(PrevalidatingMultipleActionsRunner.java:99)
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.execute(PrevalidatingMultipleActionsRunner.java:76)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runMultipleActionsImpl(Backend.java:640)
> [bll.jar:]
> at org.ovirt.engine.core.bll.Backend.runMultipleActions(Backend.java:610)
> [bll.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.8.0_141]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [rt.jar:1.8.0_141]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_141]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_141]
> at
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
> [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80)
> [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
> at
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
> at
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at
> org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13)
> [bll.jar:]
> at sun.reflect.GeneratedMethodAccessor95.invoke(Unknown Source) [:1.8.0_141]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_141]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_141]
> at
> org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89)
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.in
> vocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> [wildfly-ejb3-10.1.0.Final.jar:10.1.0.Final]
> at
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at
> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> [weld-core-impl-2.3.5.Final.jar:2.3.5.Final]
> at
> 

Re: [ovirt-users] Yum error while installing host on Centos7

[Yanir Quinn]

where did you manually install the packages ?  engine or host machine ?
you can you provide the engine.log to see what might cause the error on the
engine's side.
maybe rollback the last yum transaction you did and try to run the engine
again.

as far as for the host installation you might need to check the exiting
repositories (Cenots or other existing repos on the machine)
, its not recommended to use --skip-broken usually when adding a host.



On Tue, Aug 1, 2017 at 11:51 AM, Iurcev, Massimiliano 
wrote:

> Unfortunately this didn't work. I tried also to disable totally selinux
> without success.
>
> Then I decided to install gtk2 manually with the --skip-broken option, and
> apparently everything went fine.
> After this, the host installation goes on without errors.
> It says "Installation is closing up", then gets stuck indefinitely.
> Now the host-engine looks dead or messed up, even after a reboot... more
> in detail, the web portal is no longer accessible. :(
>
>
>
> On 30 July 2017 at 10:58, Yanir Quinn  wrote:
>
>> Might be a selinux related issue, similar threads suggest either to
>> disable selinux completely or run on host:
>>
>> # setenforce 0
>> # yum clean expire-cache
>> # yum update selinux-policy\*
>> # setenforce 1
>>
>> keeping an eye out for other reasons/solutions.
>>
>> Regards,
>> Yanir Quinn
>>
>> On Thu, Jul 27, 2017 at 5:32 PM, Iurcev, Massimiliano 
>> wrote:
>>
>>> I installed ovirt-engine on Centos7. My target is to have a single host
>>> machine.
>>> During the installation of the (first and unique) host, I get an error:
>>>
>>> Failed to install Host . Yum Non-fatal POSTIN scriptlet failure in
>>> rpm package gtk2-2.24.28-8.el7.x86_64.
>>>
>>> This error is followed by other errors:
>>>
>>> Failed to install Host . Failed to execute stage 'Package
>>> installation': One or more elements within Yum transaction failed.
>>>
>>> and finally:
>>> Host  installation failed. Command returned failure code 1 during
>>> SSH session 'r...@.mydomain.it'.
>>>
>>> All other libraries are yum-installed without problems.
>>>
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] supervdsmd IOError to /dev/stdout

[Yaniv Bronheim]

Hi,

Seems like I already bumped in such issue awhile ago -
https://bugzilla.redhat.com/show_bug.cgi?id=1216880
but now I see what's wrong -  it happens after failing to read
/etc/vdsm/svdsm.logger.conf for some reason
then we have a bug in our fallback which tries to run
logging.basicConfig(filename='/dev/stdout', filemode='w+',
level=logging.DEBUG)

and this fails while running as systemd daemon

sorry about that. check why it can't load  /etc/vdsm/svdsm.logger.conf and
update us
after fixing the access issue check if you can run
logging.config.fileConfig("/etc/vdsm/svdsm.logger.conf" ,
disable_existing_loggers=False)
Then supervdsmd should start properly

I'll reopen the bugzilla and fix the wrong fallback to syslog print

Thanks!


On Sun, Jul 30, 2017 at 3:23 PM Richard Chan 
wrote:

> Hi Yaniv,
>
> On this one node, it happened from 3.6 -> 4.0. It persisted after 4.0->4.1.
> Current: vdsm-4.19.24-1.el7.centos.x86_64
>
>
> In systemd override I now have to have:
> StandardOutput=null
>
>
>
>
> Jul 29 01:19:21  systemd[1]: Starting Auxiliary vdsm service for
> running helper functions as root...
> Jul 29 01:19:21  python2[39124]: detected unhandled Python
> exception in '/usr/share/vdsm/supervdsmServer'
> Jul 29 01:19:21  daemonAdapter[39124]: Traceback (most recent call
> last):
> Jul 29 01:19:21  daemonAdapter[39124]: File
> "/usr/share/vdsm/supervdsmServer", line 45, in 
> Jul 29 01:19:21  daemonAdapter[39124]: level=logging.DEBUG)
> Jul 29 01:19:21  daemonAdapter[39124]: File
> "/usr/lib64/python2.7/logging/__init__.py", line 1529, in basicConfig
> Jul 29 01:19:21  daemonAdapter[39124]: hdlr =
> FileHandler(filename, mode)
> Jul 29 01:19:21  daemonAdapter[39124]: File
> "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__
> Jul 29 01:19:21  daemonAdapter[39124]:
> StreamHandler.__init__(self, self._open())
> Jul 29 01:19:21  daemonAdapter[39124]: File
> "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open
> Jul 29 01:19:21  daemonAdapter[39124]: stream =
> open(self.baseFilename, self.mode)
> Jul 29 01:19:21  daemonAdapter[39124]: IOError: [Errno 6] No such
> device or address: '/dev/stdout'
> Jul 29 01:19:21  systemd[1]: supervdsmd.service: main process
> exited, code=exited, status=1/FAILURE
>
>
>
> On Sun, Jul 30, 2017 at 3:47 PM, Yaniv Kaul  wrote:
>
>>
>>
>> On Fri, Jul 28, 2017 at 8:37 PM, Richard Chan <
>> rich...@treeboxsolutions.com> wrote:
>>
>>> After an upgrade to 4.0 I have a single host that cannot start
>>> supervdsmd because of IOError on /dev/stdout. All other hosts upgraded
>>> correctly.
>>>
>>
>> Upgrade from which version? 3.6? Did you stay on 4.0 or continued to 4.1?
>>
>>
>>>
>>> In the systemd unit I have to hack StandardOutput=null.
>>>
>>> Any thing I have overlooked? The hosts are all identical and it is just
>>> this one
>>> that has this weird behaviour.
>>>
>>
>> Any logs that you can share?
>>  Y.
>>
>>
>>>
>>> --
>>> Richard Chan
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>
>
> --
> Richard Chan
> Chief Architect
>
> TreeBox Solutions Pte Ltd
> 1 Commonwealth Lane #03-01
> Singapore 149544
> Tel: 6570 3725
> http://www.treeboxsolutions.com
>
> Co.Reg.No. 201100585R
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
-- 
Yaniv Bronhaim.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] After upgrading to 4.1.4 unable to start VM or migrate them

[Yanir Quinn]

Thanks for the update, we will check if there is a bug in the upgrade
process

On Mon, Jul 31, 2017 at 6:32 PM, Arman Khalatyan  wrote:

> Ok I found the ERROR:
> After upgrade the schedule policy was "none", I dont know why it was moved
> to none but to fix the problem I did following:
> Edit Cluster->Scheduling Policy-> Select Policy: vm_evently_distributed
> Now I can run/migrate the VMs.
>
> I think there should be a some bug in the upgrade process.
>
>
> On Mon, Jul 31, 2017 at 5:11 PM, Arman Khalatyan 
> wrote:
>
>> Looks like renewed certificates problem, in the
>> ovirt-engine-setup-xx-xx.log I found following lines:
>> Are there way to fix it?
>>
>>
>> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
>> up.ovirt_engine.pki.ca ca._enrollCertificates:330 processing:
>> 'engine'[renew=True]
>> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
>> up.ovirt_engine.pki.ca plugin.executeRaw:813 execute: ('/bin/openssl',
>> 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12', '-passin',
>> 'pass:**FILTERED**', '-nokeys'), executable='None', cwd='None', env=None
>> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
>> up.ovirt_engine.pki.ca plugin.executeRaw:863 execute-result:
>> ('/bin/openssl', 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12',
>> '-passin', 'pass:**FILTERED**', '-nokeys'), rc=0
>> 2017-07-31 15:14:28 DEBUG otopi.plugins.ovirt_engine_set
>> up.ovirt_engine.pki.ca plugin.execute:921 execute-output:
>> ('/bin/openssl', 'pkcs12', '-in', '/etc/pki/ovirt-engine/keys/engine.p12',
>> '-passin', 'pass:**FILTERED**', '-nokeys') stdout:
>> Bag Attributes
>>
>>
>> On Mon, Jul 31, 2017 at 4:54 PM, Arman Khalatyan 
>> wrote:
>>
>>> Sorry, I forgot to mention the error.
>>> This error throws every time when I try to start the VM:
>>>
>>> 2017-07-31 16:51:07,297+02 ERROR [org.ovirt.engine.core.bll.RunVmCommand]
>>> (default task-239) [7848103c-98dc-45d1-b99a-4713e3b8e956] Error during
>>> ValidateFailure.: java.lang.NullPointerException
>>> at org.ovirt.engine.core.bll.scheduling.SchedulingManager.canSc
>>> hedule(SchedulingManager.java:526) [bll.jar:]
>>> at 
>>> org.ovirt.engine.core.bll.validator.RunVmValidator.canRunVm(RunVmValidator.java:157)
>>> [bll.jar:]
>>> at 
>>> org.ovirt.engine.core.bll.RunVmCommand.validate(RunVmCommand.java:967)
>>> [bll.jar:]
>>> at 
>>> org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:836)
>>> [bll.jar:]
>>> at 
>>> org.ovirt.engine.core.bll.CommandBase.validateOnly(CommandBase.java:365)
>>> [bll.jar:]
>>> at org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner
>>> .canRunActions(PrevalidatingMultipleActionsRunner.java:113) [bll.jar:]
>>> at org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner
>>> .invokeCommands(PrevalidatingMultipleActionsRunner.java:99) [bll.jar:]
>>> at org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner
>>> .execute(PrevalidatingMultipleActionsRunner.java:76) [bll.jar:]
>>> at 
>>> org.ovirt.engine.core.bll.Backend.runMultipleActionsImpl(Backend.java:640)
>>> [bll.jar:]
>>> at 
>>> org.ovirt.engine.core.bll.Backend.runMultipleActions(Backend.java:610)
>>> [bll.jar:]
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> [rt.jar:1.8.0_141]
>>> at 
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>> [rt.jar:1.8.0_141]
>>> at 
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> [rt.jar:1.8.0_141]
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>> [rt.jar:1.8.0_141]
>>> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.
>>> processInvocation(ManagedReferenceMethodInterceptor.java:52)
>>> at org.jboss.invocation.InterceptorContext.proceed(InterceptorC
>>> ontext.java:340)
>>> at org.jboss.invocation.InterceptorContext$Invocation.proceed(I
>>> nterceptorContext.java:437)
>>> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInte
>>> rception(Jsr299BindingsInterceptor.java:70)
>>> [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
>>> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInte
>>> rception(Jsr299BindingsInterceptor.java:80)
>>> [wildfly-weld-10.1.0.Final.jar:10.1.0.Final]
>>> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvoc
>>> ation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.1.0.Final.jar
>>> :10.1.0.Final]
>>> at org.jboss.as.ee.component.interceptors.UserInterceptorFactor
>>> y$1.processInvocation(UserInterceptorFactory.java:63)
>>> at org.jboss.invocation.InterceptorContext.proceed(InterceptorC
>>> ontext.java:340)
>>> at org.jboss.invocation.InterceptorContext$Invocation.proceed(I
>>> nterceptorContext.java:437)
>>> at