Bug 1778049

Summary: [machines] There is an Ooops during creating VM
Product: Red Hat Enterprise Linux 8 Reporter: YunmingYang <yunyang>
Component: cockpit-appstreamAssignee: Katerina Koukiou <kkoukiou>
Status: CLOSED ERRATA QA Contact: YunmingYang <yunyang>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.2CC: leiwang, mpitt, wshi, xchen, ymao
Target Milestone: rc   
Target Release: 8.2   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 15:43:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description YunmingYang 2019-11-29 06:56:47 UTC
Description of problem:
If there is no 'default' storage pool, then creating/importing a VM will raise an Ooops.

Version-Release number of selected component (if applicable):
cockpit-machines-206-1.el8.noarch
libvirt-dbus-1.2.0-3.module+el8.1.0+4066+0f1aadab.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a storage pool with '/var/lib/libvirt/images/', don't set 'default' for its name
2. Create/Import a VM

Actual results:
There will be raise an Ooops.

Expected results:
No Ooops is raised.

Additional info:
If importing VM, the error message from console is:
machines.js:87 Uncaught TypeError: Cannot read property 'connectionName' of undefined
    at Function.<anonymous> (machines.js:87)
    at Function.<anonymous> (machines.js:1)
    at s (cockpit.js:961)
    at cockpit.js:973
    at n (cockpit.js:879)

If creating VM, the error message from console is:
Uncaught TypeError: Cannot read property 'connectionName' of undefined
    at machines.js:87
    at machines.js:1

Comment 2 Martin Pitt 2019-11-29 14:08:14 UTC
*** Bug 1778056 has been marked as a duplicate of this bug. ***

Comment 5 Xianghua Chen 2019-12-23 11:46:54 UTC
Failed to verify with packages:
cockpit-machines-209-1.el8.noarch
libvirt-dbus-1.2.0-3.module+el8.1.0+4066+0f1aadab.x86_64

Steps:
1. Create a storage pool with '/var/lib/libvirt/images/', don't set 'default' as its name
2. Create/Import a VM

The Ooops is still there, so set status back to ASSIGNED.

Comment 6 Katerina Koukiou 2019-12-23 16:05:45 UTC
Xianghua, you are right, 209 addressed only the case where no storage pool was not defined and the path `/var/lib/libvirt/images` didn't exist either.

So the fix will be in release 210. For the record this was fixed with:

commit 84778e3c128dbd622712406e062f71b5fcbf3a17
Author: Simon Kobyda <skobyda>
Date:   Wed Dec 18 12:50:05 2019 +0100

    machines: Fix typo for default storage pool search

$ git describe 84778e3c128dbd622712406e062f71b5fcbf3a17
209-37-g84778e3c1

Comment 8 Xianghua Chen 2020-01-10 14:13:58 UTC
Verified with packages:
cockpit-machines-210-1.el8.noarch
libvirt-dbus-1.2.0-3.module+el8.1.0+4066+0f1aadab.x86_64

Steps:
1. Create a storage pool with '/var/lib/libvirt/images/', don't set 'default' as its name
2. Create/Import a VM

There is no Ooops and the VM can be created successfully.
So verified.

Comment 10 errata-xmlrpc 2020-04-28 15:43:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1639