Bug 17417

Testing procedure:
https://bugs.mageia.org/show_bug.cgi?id=14192#c7

Whiteboard: (none) => has_procedure

Hi David,
In my mirror I was able to find libvirt-utils-1.2.9.3.1 but not the others.  They're at 1.2.9.2.2.  Installed utils, but wondering if my test is invalid until my mirror is sync'd.  Can you maybe republish and see if that causes a resync?

Yes - I did refresh my mirror twice, just the utils showing at that version.

CC: (none) => brtians1

On 64 bit they are lib64virt0 and lib64virt-devel, which are available on the mirrrors.

Thanks James.  Found the 64bit versions.

I'm getting the following message from virt-manager

---------------
Unable to connect to libvirt.

internal error: Cannot find suitable emulator for x86_64

Libvirt URI is: qemu:///system
---------------

Libraries installed fine - I'll try going to back version and see if something works.

After several attempts I'm not getting this to work on my system, old version or new version.  I can see the service running, but missing components (packages) in virt-manager that do not seem to be available.  

Not sure where to go from here.  Looks like I need the KVM/QEMU modules.

urpmi qemu

hmm - I did install that.  But this is the error I get.

------------
unable to connect to libvirt.

internal error: Cannot find suitable emulator for x86_64

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1025, in _open_notify
    logging.debug("conn version=%s", self._backend.conn_version())
  File "/usr/share/virt-manager/virtinst/connection.py", line 294, in conn_version
    self._conn_version = self._libvirtconn.getVersion()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3697, in getVersion
    if ret == -1: raise libvirtError ('virConnectGetVersion() failed', conn=self)
libvirtError: internal error: Cannot find suitable emulator for x86_64
-------------

Anybody else running into this?  Perm issue?

tested on real hardware per IRC conversation.

Still same errors.  Methinks virt-manager gods have frowned upon me and said - go elsewhere.

Try it now.

Advisory:
========================

Updated libvirt packages fix security vulnerability:

A path-traversal flaw was found in the way the libvirt daemon handled
file-system names for storage volumes. A libvirt user with privileges to
create storage volumes and without privileges to create and modify domains
could possibly use this flaw to escalate their privileges (CVE-2015-5313).

A bug in the package which caused qemu connections to fail has also been fixed.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5313
https://lists.fedoraproject.org/pipermail/package-announce/2015-December/174404.html
========================

Updated packages in core/updates_testing:
========================
libvirt0-1.2.9.3-1.1.mga5
libvirt-devel-1.2.9.3-1.1.mga5
libvirt-utils-1.2.9.3-1.1.mga5

from libvirt-1.2.9.3-1.1.mga5.src.rpm

Trying x64

Lost again. The 'test procedure' referred to is rather scant: "Start libvirtd service and then use virt-manager ... to create and start a VM. It will ask for your root password and connect to the libvirtd service running on localhost then allow you to create/start/stop/view/alter any VM's running on it. virt-manager has an icon in the menu in tools => emulators. If you can start a VM, even just start an installation, it's enough to show libvirtd is working."

I have just LXC, and installed lib64virt0-1.2.9.2-2.mga5

I cannot find lib[64]virtd anywhere. It is not in the MCC services list, nor visible to install under any similar name. Launching
 # virt-manager
popped up a window complaining about the lack of a hypervisor etc & libvirtd; trying to add (as it suggested) an LXC connection yielded:
"Unable to connect to libvirt.
Verify that the 'libvirtd' daemon is running."

FWIW Starting Virtual Machine Manager from the menus showed its empty window, which, under XFCE at least, did not respond to any menu or item click.

CC: (none) => lewyssmith

(In reply to Lewis Smith from comment #10)

libvirtd is in the libvirt-utils package

'systemctl start libvirtd.service' should launch it.

Testing on mga5-32

already installed:
qemu-2.1.3-2.11.mga5.i586
qemu-img-2.1.3-2.11.mga5.i586
virt-manager-1.1.0-7.mga5.noarch

installed from testing:
- libvirt-utils-1.2.9.3-1.1.mga5.i586
- libvirt0-1.2.9.3-1.1.mga5.i586

Packages installed cleanly.

Virtual Machine Manager reports:
"localhost(QEMU) - Connecting..." indefinitely. 
Attempting to create a new VM reports:
"No active connection"

(Using the previous version (1.2.9.2-2) of libvirt I was able to create a VM and launch the installation of mga5-32 using boot.iso)

A little more testing and I realise that the version in updates does not ask for the root password. The previous version does.

Testing on mga5-64

already installed:
qemu-2.1.3-2.11.mga5.x86_64
qemu-img-2.1.3-2.11.mga5.x86_64
virt-manager-1.1.0-7.mga5.noarch
libvirt-utils-1.2.9.2-2.mga5.x86_64
lib64virt0-1.2.9.2-2.mga5.x86_64

virt-manager asks for a root password. 
I can create a VM and boot an iso

Packages installed from testing:
- lib64virt0-1.2.9.3-1.1.mga5.x86_64
- libvirt-utils-1.2.9.3-1.1.mga5.x86_64

virt-manager does not ask for the root password and
displays "localhost(QEMU) - Connecting..." indefinitely. 
Attempting to create a new VM reports:
"No active connection"

confirmed this behaviour, adding feedback for now.

# systemctl status -l libvirtd
â libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Sat 2016-02-06 17:56:35 GMT; 2s ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 5030 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           ââ4409 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshelper
           ââ4410 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshelper
           ââ5030 /usr/sbin/libvirtd
           ââ5085 /usr/bin/qemu-system-arm -S -no-user-config -nodefaults -nographic -M none -qmp unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait -pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize

Feb 06 17:56:35 localhost.localdomain libvirtd[5030]: libvirt version: 1.2.9.3
Feb 06 17:56:35 localhost.localdomain libvirtd[5030]: Failed to acquire pid file '/var/lib/libvirt/qemu/capabilities.pidfile': Resource temporarily unavailable

# ll /var/lib/libvirt/qemu/
total 24
srwxr-x--- 1 root root    0 Feb  6 17:56 capabilities.monitor.sock=
-rw------- 1 root root    5 Feb  6 17:56 capabilities.pidfile
drwxr-xr-x 3 root root 4096 Feb  6 17:55 channel/
drwxr-xr-x 2 root root 4096 Feb  6 17:45 dump/
drwxr-xr-x 2 root root 4096 Feb  6 17:55 nvram/
drwxr-xr-x 2 root root 4096 Feb  6 17:45 save/
drwxr-xr-x 2 root root 4096 Feb  6 17:45 snapshot/

Whiteboard: has_procedure advisory => has_procedure advisory feedback

# systemctl stop libvirtd         

# ll /var/lib/libvirt/qemu/
total 24
srwxr-x--- 1 root root    0 Feb  6 17:56 capabilities.monitor.sock=
-rw------- 1 root root    5 Feb  6 17:56 capabilities.pidfile
drwxr-xr-x 3 root root 4096 Feb  6 17:55 channel/
drwxr-xr-x 2 root root 4096 Feb  6 17:45 dump/
drwxr-xr-x 2 root root 4096 Feb  6 17:55 nvram/
drwxr-xr-x 2 root root 4096 Feb  6 17:45 save/
drwxr-xr-x 2 root root 4096 Feb  6 17:45 snapshot/

Trying x64

(In reply to James Kerr from comment #11)
> (In reply to Lewis Smith from comment #10)
> libvirtd is in the libvirt-utils package
Thanks for this pointer. I did indeed need to install [issued] libvirt-utils:
 libvirt-utils-1.2.9.2-2.mga5
After doing so, I checked with MCC that libvirtd *was* running, but still got failures about it from both virt-install; and Virtual Machine Manager when trying to add a connection to lxc.

> 'systemctl start libvirtd.service' should launch it.
Did that, which advanced things. VMM created an LXC connection after asking for the root password. But hoping to launch an lxc VM creation from a local ISO file foundered:
 "# virt-install --connect lxc:/// -n LXCVM --memory 2 --cdrom /mnt/common/Mageia/KDE64/Mageia-5-LiveDVD-KDE4-x86_64-DVD.iso --disk /mnt/common/tmp/,size=10
ERROR    Install methods (--location URL, --cdrom CD/ISO, --pxe, --import, --boot hd|cdrom|...) cannot be specified for container guests"
Even worse:
 # virt-install
ERROR    Host does not support any virtualisation options 

Does this mean one cannot use lxc with an ISO image to test this thing? If so, how?  Alternatively, is there another ruse for testing libvirtd with lxc? (Yes, I did scour the long man page). QEMU/KVM or Xen are even heavier. I know this bug is greyed, but if I can get something working with the pre-update package, it will facilitate testing the eventual update.

Seems everyone uses different tests. It would probably be helpful if everybody agreed on a basic test which does not involve any external tools. virsh is the most basic tool for that which comes with libvirt-utils. The following would list all domains (VMs) as root and shows virsh debug messages:

virsh -d 0 -c qemu:///system list

# to enable really verbose libvirt debugging use
# LIBVIRT_DEBUG=1 virsh -d 0 -c qemu:///system list
# For more troubleshooting see http://wiki.libvirt.org/page/Troubleshooting

----

Easiest complete testcase to create a VM and start installation using an .iso as explained at http://virt-tools.org/learning/install-with-command-line/

# create a new harddisk
# disk images are located below /var/lib/libvirt/images/ by default
LC_ALL=C virsh vol-create-as --pool default guest 8192M

# create and boot a new VM, automatically opens virt-viewer
LC_ALL=C virt-install -r 2048 --accelerate -n Mageia-Test -f /var/lib/libvirt/images/guest --cdrom Mageia-5-dual-DVD.iso

which works just fine using the default mga5 packages.

----

After an update via 'urpmi --searchmedia "updates" libvirt-utils' and restart of libvirtd via 'systemctl restart libvirtd.service'
any connect to libvirtd just doesn't happen or times out. Some differences that I saw:

- one /usr/bin/qemu-system-arm process is spawned as a child of libvirtd.service which wasn't the case before the update. No clue what this is for.
- no more errors in libvirtd.service journal entries as with mga5 packages


Tried to start livbirtd and virsh in debug mode:

LC_ALL=C LIBVIRT_DEBUG=1 /usr/sbin/libvirtd --config /etc/libvirt/libvirtd.conf

and then try to connect via

LIBVIRT_DEBUG=1 virsh -d 0 -c qemu:///system list

and the processes don't even seem to talk to each other, simply nothing happens.


Cannot test libvirtd under cauldron for comparison as I don't have a physical cauldron install but the packages seem to be the same.

CC: (none) => doktor5000

In https://ml.mageia.org/l/arc/dev/2016-02/msg00066.html

Thierry Vignaud wrote:
"For the later patch issue, checking is simple: run virt-manager as root.
If it fails to connect to libvirtd, then the patch is still active."

When I execute virt-manager in a root terminal (on mga5-64), I get the same result as reported in comment #14: 
virt-manager displays "localhost(QEMU) - Connecting..." indefinitely.

(In reply to Florian Hubold from comment #18)
In cauldron (64 bit) virt-manager asks for the root password and I can create a VM and boot an iso.

(In reply to James Kerr from comment #20)
> (In reply to Florian Hubold from comment #18)
> In cauldron (64 bit) virt-manager asks for the root password and I can
> create a VM and boot an iso.

That might be the case, but doesn't really help with this update candidate nor with libvirt. virt-manager is a graphical frontend interfacing with what libvirt provides, and we don't want to test the frontend here, but libvirt as that's what the update candidate is about.

FWIW, I just tested with the removed patch added back and connection via virsh works as expected again. Not sure why it works in cauldron without the patch.

We've always used virt-manager to test libvirtd Florian. 
The test is valid, the package has issues.

(In reply to claire robinson from comment #22)
> We've always used virt-manager to test libvirtd Florian.

I didn't say the test is invalid, just pointed out that if you mention a sympton that doesn't point to the root cause.

And pointed out where the issue comes from - the dropped patch.

See comment 15 :)

(In reply to claire robinson from comment #24)
> See comment 15 :)

What should I see there? I didn't have the "Failed to acquire pid file" error, just the timeouts. In any case, just tell me whether I should submit a new build with the dropped patch added back or not. Apart from that can't help much further here.

If it fixes the problem then it sounds logical to do so. Thanks.

Submitted libvirt-1.2.9.3-1.2.mga5 to core/updates_testing.

In VirtualBox, M5, KDE, 32-bit

Package(s) under test:
libvirt0

default install of libvirt0 libvirt-devel & libvirt-utils

[root@localhost wilcal]# urpmi libvirt0
Package libvirt0-1.2.9.2-2.mga5.i586 is already installed
[root@localhost wilcal]# urpmi libvirt-devel
Package libvirt-devel-1.2.9.2-2.mga5.i586 is already installed
[root@localhost wilcal]# urpmi libvirt-utils
Package libvirt-utils-1.2.9.2-2.mga5.i586 is already installed

[root@localhost wilcal]# systemctl status -l libvirtd
â libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Thu 2016-02-11 20:25:02 PST; 1min 0s ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 1221 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           ââ1221 /usr/sbin/libvirtd
           ââ1375 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshelper
           ââ1376 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshelper

[root@localhost wilcal]# virt-manager
bash: virt-manager: command not found

Nor is there a launch icon in menu => tools => emulators.
Launch command in a terminal is supposed to be: virt-manager

This is all before adding the new version from updates_testing

CC: (none) => wilcal.int

(In reply to William Kenney from comment #28)

You need to install virt-manager package.
"Virtual Machine Manager" launch icon is in Tools/System Tools.

Testing on mga5-64

already installed:
qemu-2.1.3-2.11.mga5.x86_64
qemu-img-2.1.3-2.11.mga5.x86_64
virt-manager-1.1.0-7.mga5.noarch

Packages installed from testing:

lib64virt0-1.2.9.3-1.2.mga5
libvirt-utils-1.2.9.3-1.2.mga5

# systemctl restart libvirtd

# systemctl -l status libvirtd
â libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Fri 2016-02-12 08:51:26 GMT; 1min 11s ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 1725 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           ââ1725 /usr/sbin/libvirtd
           ââ2037 /sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf 
--dhcp-script=/usr/libexec/libvirt_leaseshelper
           ââ2038 /sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf 
--dhcp-script=/usr/libexec/libvirt_leaseshelper

Feb 12 08:51:26 mga5-64 libvirtd[1725]: internal error: cannot mix string I/O 
with daemon
Feb 12 08:51:26 mga5-64 libvirtd[1725]: Failed to probe capabilities for 
/usr/bin/qemu-system-sh4: internal error: cannot mix string I/O with daemon
Feb 12 08:51:26 mga5-64 libvirtd[1725]: internal error: cannot mix string I/O 
with daemon
Feb 12 08:51:26 mga5-64 libvirtd[1725]: Failed to probe capabilities for 
/usr/bin/qemu-system-sh4eb: internal error: cannot mix string I/O with daemon
Feb 12 08:51:26 mga5-64 libvirtd[1725]: internal error: cannot mix string I/O 
with daemon
Feb 12 08:51:26 mga5-64 libvirtd[1725]: Failed to probe capabilities for 
/usr/bin/qemu-system-sparc: internal error: cannot mix string I/O with daemon
Feb 12 08:51:26 mga5-64 libvirtd[1725]: internal error: cannot mix string I/O 
with daemon
Feb 12 08:51:26 mga5-64 libvirtd[1725]: Failed to probe capabilities for 
/usr/bin/qemu-system-x86_64: internal error: cannot mix string I/O with daemon
Feb 12 08:51:26 mga5-64 libvirtd[1725]: internal error: cannot mix string I/O 
with daemon
Feb 12 08:51:26 mga5-64 libvirtd[1725]: Failed to probe capabilities for 
/usr/bin/qemu-kvm: internal error: cannot mix string I/O with daemon


virt-manager asks for root password and reports:
Unable to connect to libvirt.
internal error: Cannot find suitable emulator for x86_64
localhost(QEMU) - not connected


# virsh vol-create-as --pool default guest 8192M
Vol guest created

# virt-install -r 2048 --accelerate -n Mageia-Test -f 
/var/lib/libvirt/images/guest --cdrom Mageia-5-i586-DVD.iso
ERROR    Host does not support any virtualisation options

Created attachment 7449 [details]
debug output

Result from:
# LIBVIRT_DEBUG=1 /usr/sbin/libvirtd --config /etc/libvirt/libvirtd.conf

Created attachment 7450 [details]
more debug output

Result from:
# LIBVIRT_DEBUG=1 virsh -d 0 -c qemu:///system list

In VirtualBox, M5, KDE, 32-bit

Package(s) under test:
libvirt0

default install of libvirt0 libvirt-devel libvirt-utils & virt-manager

[root@localhost wilcal]# urpmi libvirt0
Package libvirt0-1.2.9.2-2.mga5.i586 is already installed
[root@localhost wilcal]# urpmi libvirt-devel
Package libvirt-devel-1.2.9.2-2.mga5.i586 is already installed
[root@localhost wilcal]# urpmi libvirt-utils
Package libvirt-utils-1.2.9.2-2.mga5.i586 is already installed
[root@localhost wilcal]# urpmi virt-manager
Package virt-manager-1.1.0-7.mga5.noarch is already installed

VMM icon created in menu => tools => System Tools.

[root@localhost wilcal]# systemctl status -l libvirtd
â libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Fri 2016-02-12 07:42:31 PST; 12min ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 1247 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           ââ1247 /usr/sbin/libvirtd
           ââ1401 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/.....
           ââ1402 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/.....

Launching virt-manager results in a window with the
following error message:
Could not detect a default hypervisor. Make
sure the appropriate virtualzation packages
are installed (kvm, quem, libvert, etc.), and
that libvirtd is running.

A hypervisor connection can be manually added via File->Add Connection

Attempting to manually add a connection results in a ServiceUnknown
message.

Do you have qemu installed?

(In reply to James Kerr from comment #34)

> Do you have qemu installed?

Of course not. Where is it documented that I need "qemu" installed to test libvert?

See comment#5 and comment#6

We need a simple, understandable, workable procedure that simply ensures that libvert is working. We're not there yet.

I have never used libvirt or qemu. In order to determine how to test libvirt, I 
read through the bug reports for previous updates, starting with the one linked 
in comment#1.

I concluded that I need to have at least the following packages installed:
qemu
qemu-img
virt-manager
libvirt-utils
lib(64)virt0

I start/restart libvirtd
#systemctl restart libvirtd
and check that it launched without errors
#systemctl -l status libvirtd

On launching virt-manager from the menu (in mga5 KDE it is in Tools/System Tools), it should ask for the root password.
The window that opens should report that it is connected to localhost (QEMU).
There is an icon to create a new VM. 
Clicking on that icon opens a series of dialogues.
I leave all the default options selected and provide the path to an iso file where it is asked for. 
If on completing the final dialogue the iso boots, then I conclude that the packages are OK.

(In reply to James Kerr from comment #38)

> I have never used libvirt or qemu. In order to determine how to test
> libvirt........

Now this is what I call a procedure. I'll give it a go tomorrow (13feb16).
Then we'll finally have a usable procedure for this devil.

Sorry in advance for the long reply ^^


(In reply to James Kerr from comment #30)
> virt-manager asks for root password and reports:
> Unable to connect to libvirt.
> internal error: Cannot find suitable emulator for x86_64
> localhost(QEMU) - not connected

> # virt-install -r 2048 --accelerate -n Mageia-Test -f 
> /var/lib/libvirt/images/guest --cdrom Mageia-5-i586-DVD.iso
> ERROR    Host does not support any virtualisation options


There are still issues with the update candidate, probably also with the original mga5 packages but they don't show that easily.

In the meantime I've tried quite a number of other builds, as there seem to be some other issues in general between libvirtd and qemu. For one, qemu sometimes seems to crash and leaves it's socket and PID file behind, which it usually cleans up before shutdown, so that's a definite sign it crashed.

One can verify presence of those files after stopping libvirt and killing remaining libvirtd, dnsmasq and qemu processes via

ls -al /var/lib/libvirt/qemu/capabilities.{monitor.sock,pidfile}

They should _NOT_ be present anymore. Same for the libvirt socket in /var/run/libvirt/

And furthermore the hardware acceleration modules are not loaded or suggested to load, this applies later when virt-manager can establish a connection and if one tries to create a new virtual machine, virt-manager will tell you that hardware acceleration is missing (modprobe intel-kvm; modprobe kvm for intel boxes, probably kvm-amd and kvm for amd boxes).


For a complete testcase, this is what I'd suggest (including a cleanup of leftover socket files and such if there are issues starting libvirtd) - also please make sure to only test this on actual hardware, _not_ in a VM.


# install necessary packages
urpmi libvirt-utils qemu virt-manager

# load kernel modules
modprobe kvm-intel; modprobe kvm #(intel)
modprobe kvm-amd; modprobe kvm #(amd)
lsmod|grep kvm

# check the status of the services and last log outputs
systemctl status libvirtd libvirt-guests virtlockd -a

# start libvirtd
systemctl restart libvirtd.service

# check the resulting processes - pay attention if you see any <defunc> qemu ones
ps -ef|grep -v grep|grep -iE "virt|qemu|virsh"

# check the status of the services and last log output again
sudo systemctl status libvirtd libvirt-guests virtlockd -a


# now query the libvirt capabilities as a test if libvirt is running and responds to basic connections - there should be a lot of output
virsh capabilities

# if there's no output and prompt won't return, then libvirtd isn't running correctly and it needs to be fixed

# if it responds with a lot of text which shows all the hardware capabilities of the current host, then one can start virt-manager to create a VM or do whatever
LIBVIRT_DEBUG=1 virt-manager

----
# my cleanup procedure as follows

# stop relevant services
systemctl stop libvirtd libvirt-guests virtlockd libvirtd.socket

# check processes that might still be running and kill them, check again
ps -ef|grep -v grep|grep -iE "virt|qemu|virsh"; pkill -f libvirt; ps -ef|grep -v grep|grep -iE "virt|qemu|virsh"

# check the status of the services and last log output again
systemctl status libvirtd libvirt-guests virtlockd -a

# check if there are pid/sockets left behind
ls -al /var/lib/libvirt/qemu/capabilities*
# delete them
rm -f /var/lib/libvirt/qemu/capabilities*

# check if there are libvirt sockets left behind
ls -al /var/run/libvirt/libvirt-sock*
# delete the whole temporary folder to be safe
rm -rf /var/run/libvirt

# cleanup the qemu capabilities cache
rm -f /var/cache/libvirt/qemu/capabilities/*.xml

----

I'm still testing with different builds, original 1.2.9.2-2.mga5 plus the patch for CVE-2015-5313, 1.2.9.3 minus and plus the added upstream patches and minus and plus our libvirt-1.2.3-mga-no-daemonize.patch. Even switched to a different maintenance branch, libvirt-1.2.18.2, just for testing purposes. But there are issues with each build, 

But in each case it seems either during or after the update there are issues, as libvirtd is still running there that might be an issue. 
As a result, either all connections to libvirt time out, which seems to indicate some pid/socket files got left behind and libvirtd cannot be restarted normally  (systemctl restart won't help in that case).

Or in the other case no emulator/no virtualisation options are found, as in James' example quoted above.

(In reply to Florian Hubold from comment #40)

> ..There are still issues with the update candidate, probably also with the
> original mga5 packages but they don't show that easily.......

Many thanks to all for the work on this bug. I'm sure when we're finished
we'll have something that can be easily tested. Solder on.

Florian, to answer your question from IRC, no we can't revert this backwards if we intend to continue to support it going forwards.  Updating to 1.2.13.2 or 1.2.18.2 (including the latest commits from git in either case) would be fine if that would work better.  This package has no maintainer, which is why it was never updated past 1.2.9.x.

(In reply to David Walser from comment #42)
> Florian, to answer your question from IRC, no we can't revert this backwards
> if we intend to continue to support it going forwards.

Sure, granted - but we also need to make sure that the package keeps working in a stable manner as the current version does - old or not. Otherwise supporting it with new versions is somehow futile. Although if it doesn't work at all, then at least the security issues are patched with success :p

> Updating to 1.2.13.2 or 1.2.18.2 (including the latest commits from git in either
> case) would be fine if that would work better. This package has no maintainer,
> which is why it was never updated past 1.2.9.x.

Well, even had no success with clean build of current libvirt 1.3.1. Will probably open a bugreport upstream, and we also might need to look at qemu in parallel, because that is what libvirtd runs and eventually crashes when libvirt is probing capabilities. Sadly didn't find any good document about qemu <> libvirt cross dependencies wrt. versions.

Apart from that, our libvirt package also needs quite a lot of Requires added, e.g. on dmidecode and qemu-img from a comparison with Fedora. But first we should get a maintained version working, and then sort out smaller flaws.

(In reply to Florian Hubold from comment #43)
> Will probably open a bugreport upstream

Reported upstream: https://bugzilla.redhat.com/show_bug.cgi?id=1308736

Status: NEW => ASSIGNED

Did a git bisect as suggested by David, and seems found one commit, added results to https://bugzilla.redhat.com/show_bug.cgi?id=1308736#c4

Ok, for now I've reverted one upstream commit per feedback from upstream: https://bugzilla.redhat.com/show_bug.cgi?id=1308736#c4

libvirtd seems to be connectable again as usual. Pushed a new update candidate as libvirt-1.2.9.3-1.3.mga5, please test. Advisory see comment 9.

This is what I used as testcase:

sudo urpmi --searchmedia "updates" libvirt-utils qemu virt-manager
sudo systemctl start libvirtd.service
sudo systemctl status libvirtd libvirt-guests virtlockd -a
# the following should immediately return a long listing of capabilities, if it doesn't then something else is wrong and you may still be encountering a timeout
sudo virsh capabilities
sudo LIBVIRT_DEBUG=1 virt-manager

For some more details see comment 40.

Assignee: doktor5000 => qa-bugs

fyi - I used libvirt 1.2.9.3-1.2 utils and lib64virt0 1.2.9.3-1.2.

They seem to be working acceptably.

Testing on mga5-32

Packages installed:

qemu-2.1.3-2.11.mga5
libvirt0-1.2.9.3-1.3.mga5
libvirt-utils-1.2.9.3-1.3.mga5
virt-manager-1.1.0-7.mga5


# systemctl start libvirtd.service

# systemctl status libvirtd libvirt-guests virtlockd -a
â libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Tue 2016-03-08 07:42:18 GMT; 44s ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 5092 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           ââ5092 /usr/sbin/libvirtd
           ââ5209 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshel...
           ââ5210 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshel...

â libvirt-guests.service - Suspend Active Libvirt Guests
   Loaded: loaded (/usr/lib/systemd/system/libvirt-guests.service; enabled)
   Active: inactive (dead)
     Docs: man:libvirtd(8)
           http://libvirt.org

â virtlockd.service - Virtual machine lock manager
   Loaded: loaded (/usr/lib/systemd/system/virtlockd.service; static)
   Active: inactive (dead)
     Docs: man:virtlockd(8)
           http://libvirt.org

virsh capabilities
- returns a long list of capabilities

Using virt-manager I can create a vm which boots an iso.

OK for mga5-32

Whiteboard: has_procedure advisory => has_procedure advisory MGA5-32-OK

Testing on mga5-64

Packages:

already installed:
qemu-2.1.3-2.11.mga5
virt-manager-1.1.0-7.mga5

from testing:
- lib64virt0-1.2.9.3-1.3.mga5.x86_64
- libvirt-utils-1.2.9.3-1.3.mga5.x86_64

# systemctl start libvirtd
# systemctl status libvirtd libvirt-guests virtlockd -a
â libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Tue 2016-03-08 08:51:13 GMT; 22s ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 4220 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           ââ4220 /usr/sbin/libvirtd
           ââ4337 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshel...
           ââ4338 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --dhcp-script=/usr/libexec/libvirt_leaseshel...

â libvirt-guests.service - Suspend Active Libvirt Guests
   Loaded: loaded (/usr/lib/systemd/system/libvirt-guests.service; enabled)
   Active: inactive (dead)
     Docs: man:libvirtd(8)
           http://libvirt.org

â virtlockd.service - Virtual machine lock manager
   Loaded: loaded (/usr/lib/systemd/system/virtlockd.service; static)
   Active: inactive (dead)
     Docs: man:virtlockd(8)
           http://libvirt.org
           
# virsh capabilities        
- returns a long list of capabilities

Using virt-manager I can create a vm which boots an iso.

OK for mga5-64

Whiteboard: has_procedure advisory MGA5-32-OK => has_procedure advisory MGA5-32-OK MGA5-64-OK

This update is now validated

The Advisory in SVN may need to be amended:
- the source rpm is libvirt-1.2.9.3-1.3.mga5

The packages can then be pushed to updates.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

(In reply to James Kerr from comment #50)
> This update is now validated

Could we maybe wait for at least one other OK? I'd be more happy about that.
This has already taken 3 months overall, so one day more or less won't make much of a difference IMHO

I've removed the validation. Hopefully someone else will test.

Keywords: validated_update => (none)

Testing shortly

Tried a Mageia 6 dev1 iso install. It failed due to a conflict between bootloader-utils and samba-client, but it got far enough that I'm satisfied libvirt is ok,
so validating the update.

Keywords: (none) => validated_update

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2016-0103.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED