Fedora has issued an advisory on December 28: https://lists.fedoraproject.org/pipermail/package-announce/2015-December/174404.html Updated and patched packages uploaded for Mageia 5 and Cauldron. 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). 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.mga5 libvirt-devel-1.2.9.3-1.mga5 libvirt-utils-1.2.9.3-1.mga5 from libvirt-1.2.9.3-1.mga5.src.rpm Reproducible: Steps to Reproduce:
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.
CC: (none) => davidwhodginsWhiteboard: has_procedure => has_procedure advisory
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.
Whiteboard: has_procedure advisory feedback => has_procedure advisory
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.
Hardware: i586 => AllAssignee: qa-bugs => doktor5000
CC: (none) => qa-bugs
(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
CC: lewyssmith => (none)
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_updateCC: (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 => RESOLVEDResolution: (none) => FIXED