> On 1 Sep 2017, at 13:39, Piotr Kliczewski <piotr.kliczewski(a)gmail.com&gt; wrote: > > All, > > I pulled the latest engine master [1] and I see following exception > below. Is it known issue? I wonder if that’s a regression from Milan’s vdsm work on recovery/external vms….

> [1] Based on 34f4d69117d916e52a7b2d5032d64b8d1185448c > > 2017-09-01 13:35:38,829+02 ERROR > [org.ovirt.engine.core.bll.AddUnmanagedVmsCommand] > (DefaultQuartzScheduler10) [353095e7] Command > 'org.ovirt.engine.core.bll.AddUnmanagedVmsCommand' failed: null > 2017-09-01 13:35:38,829+02 ERROR > [org.ovirt.engine.core.bll.AddUnmanagedVmsCommand] > (DefaultQuartzScheduler10) [353095e7] Exception: > java.lang.NumberFormatException: null > at java.lang.Integer.parseInt(Integer.java:542) [rt.jar:1.8.0_141] > at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_141] > at > org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerObjectsBuilder.parseIntVdsProperty(VdsBrokerObjectsBuilder.java:775) > [vdsbroker.jar:] > at org.ovirt.engine.core.bll.AddUnmanagedVmsCommand.convertVm(AddUnmanagedVmsCommand.java:119) > [bll.jar:] > at org.ovirt.engine.core.bll.AddUnmanagedVmsCommand.executeCommand(AddUnmanagedVmsCommand.java:96) > [bll.jar:] > at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1202) > [bll.jar:] > at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1342) > [bll.jar:] > at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1984) > [bll.jar:] > at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) > [utils.jar:] > at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) > [utils.jar:]

Piotr Kliczewski <piotr.kliczewski(a)gmail.com&gt; writes: > I pulled the latest engine master [1] and I see following exception > below. Is it known issue? Piotr, what's the libvirt version on your host? Is the cluster version 4.2? And did you migrate some VM?

Thanks, Milan > [1] Based on 34f4d69117d916e52a7b2d5032d64b8d1185448c > > 2017-09-01 13:35:38,829+02 ERROR > [org.ovirt.engine.core.bll.AddUnmanagedVmsCommand] > (DefaultQuartzScheduler10) [353095e7] Command > 'org.ovirt.engine.core.bll.AddUnmanagedVmsCommand' failed: null > 2017-09-01 13:35:38,829+02 ERROR > [org.ovirt.engine.core.bll.AddUnmanagedVmsCommand] > (DefaultQuartzScheduler10) [353095e7] Exception: > java.lang.NumberFormatException: null > at java.lang.Integer.parseInt(Integer.java:542) [rt.jar:1.8.0_141] > at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_141] > at > org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerObjectsBuilder.parseIntVdsProperty(VdsBrokerObjectsBuilder.java:775) > [vdsbroker.jar:] > at org.ovirt.engine.core.bll.AddUnmanagedVmsCommand.convertVm(AddUnmanagedVmsCommand.java:119) > [bll.jar:] > at org.ovirt.engine.core.bll.AddUnmanagedVmsCommand.executeCommand(AddUnmanagedVmsCommand.java:96) > [bll.jar:] > at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1202) > [bll.jar:] > at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1342) > [bll.jar:] > at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1984) > [bll.jar:] > at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) > [utils.jar:] > at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) > [utils.jar:] > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel

Piotr Kliczewski <piotr.kliczewski(a)gmail.com&gt; writes: > On Wed, Sep 6, 2017 at 6:35 PM, Milan Zamazal <mzamazal(a)redhat.com&gt; wrote: >> Piotr Kliczewski <piotr.kliczewski(a)gmail.com&gt; writes: >> > >>> I pulled the latest engine master [1] and I see following exception >>> below. Is it known issue? >> >> Piotr, what's the libvirt version on your host? Is the cluster version >> 4.2? And did you migrate some VM? > > I am using: > > Name : libvirt > Arch : x86_64 > Epoch : 0 > Version : 3.2.1 > Release : 3.fc25 > > My cluster version is: 4.2 > > I haven't performed any migrations in this environment. Thank you for info. There should be a VM unknown to Engine on one of your hosts, either an external VM (that would be OK) or a VM remnant in DOWN status, visible in `virsh -r list --all'. If the latter then I'm very interested in how you got it. You can get rid of it with `virsh undefine', Vdsm restart may be additionally needed. If you happen to get it again, could you please tell me what you did and provide Vdsm logs (preferably with DEBUG level) and `virsh -r list --all' from the host?

>>> [1] Based on 34f4d69117d916e52a7b2d5032d64b8d1185448c >>> >>> 2017-09-01 13:35:38,829+02 ERROR >>> [org.ovirt.engine.core.bll.AddUnmanagedVmsCommand] >>> (DefaultQuartzScheduler10) [353095e7] Command >>> 'org.ovirt.engine.core.bll.AddUnmanagedVmsCommand' failed: null >>> 2017-09-01 13:35:38,829+02 ERROR >>> [org.ovirt.engine.core.bll.AddUnmanagedVmsCommand] >>> (DefaultQuartzScheduler10) [353095e7] Exception: >>> java.lang.NumberFormatException: null >>> at java.lang.Integer.parseInt(Integer.java:542) [rt.jar:1.8.0_141] >>> at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_141] >>> at >>> org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerObjectsBuilder.parseIntVdsProperty(VdsBrokerObjectsBuilder.java:775) >>> [vdsbroker.jar:] >>> at org.ovirt.engine.core.bll.AddUnmanagedVmsCommand.convertVm(AddUnmanagedVmsCommand.java:119) >>> [bll.jar:] >>> at org.ovirt.engine.core.bll.AddUnmanagedVmsCommand.executeCommand(AddUnmanagedVmsCommand.java:96) >>> [bll.jar:] >>> at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1202) >>> [bll.jar:] >>> at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1342) >>> [bll.jar:] >>> at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1984) >>> [bll.jar:] >>> at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) >>> [utils.jar:] >>> at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) >>> [utils.jar:] >>> _______________________________________________ >>> Devel mailing list >>> Devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel

Piotr Kliczewski <piotr.kliczewski(a)gmail.com&gt; writes: > There few ways I could get there: > 1. Testing some code and creating vdsm and later dropping db and > reinstalling the host with "new db" > 2. Vms provisioned manually. I.e. outside oVirt? If they are external VMs then it explains why you get the tracebacks and we have a fix posted (https://gerrit.ovirt.org/81529). I was worried that the tracebacks could be caused by oVirt VMs.

> At this time it seems to be option #2 and I see: > > [root@f20 ~]# virsh -r list --all > Id Name State > ---------------------------------------------------- > - centos7 shut off > - rhel7.0-dev shut off > > which are machines where I test el7 compatibility of my changes (I use > fedora25 on bare metal). > > I see the failure every time I run the engine now since I sent the > email to this thread. It started > to occur recently event though I have those vms there for really long time.