Error creating new VM with OVMF

Bug #1483071 reported by Gannet
42
This bug affects 8 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Fix Released
High
Unassigned
Trusty
Won't Fix
High
Unassigned
Wily
Won't Fix
High
Unassigned

Bug Description

=================================
SRU Justification
Impact: cannot start VMs with UEFI
Test case:
Regression potential: virt-aa-helper is modified to add the nvram files to the allowed list, there should be no regressions.
=================================

When I'm trying to create new VM through virt-manager with OVMF firmware instead of BIOS an error appears:

Failed to complete an installation: «internal error: cannot load AppArmor profile «libvirt-0dc7297d-a474-47ed-88b0-026f1d6ae2a4»»

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1873, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 414, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 478, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3497, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error: cannot load AppArmor profile «libvirt-0dc7297d-a474-47ed-88b0-026f1d6ae2a4»

There is an appropriate lines at the end of /etc/libvirt/qemu.conf:

nvram = [ "/usr/share/OVMF/OVMF_CODE-pure-efi.fd:/usr/share/OVMF/OVMF_VARS-pure-efi.fd",
          "/usr/share/OVMF/OVMF_CODE-with-csm.fd:/usr/share/OVMF/OVMF_VARS-with-csm.fd" ]

Surely those files are present in /usr/share/OVMF/.

Kbuntu 15.10 Wily
Linux 4.2RC6 x86_64
virt-manager 1.2.1
libvirt 1.2.16
qemu 2.3

Tags: apparmor
Gannet (ken20001)
description: updated
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

This is a problem with virt-aa-helper.c. Basically, in valid_path() this:

    /* override the above with these */
    const char * const override[] = {
        "/sys/devices/pci", /* for hostdev pci devices */
        "/etc/libvirt-sandbox/services/" /* for virt-sandbox service config */
    };

should be changed to:
    /* override the above with these */
    const char * const override[] = {
        "/sys/devices/pci", /* for hostdev pci devices */
        "/etc/libvirt-sandbox/services/", /* for virt-sandbox service config */
        "/usr/share/ovmf/" /* for OVMF images */
    };

See https://lists.ubuntu.com/archives/apparmor/2015-August/008466.html for details.

no longer affects: apparmor (Ubuntu)
no longer affects: virt-manager (Ubuntu)
tags: added: apparmor
Revision history for this message
Gannet (ken20001) wrote :

So we need to wait for new libvirt bugfixed version?

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libvirt - 1.2.16-2ubuntu8

---------------
libvirt (1.2.16-2ubuntu8) wily; urgency=medium

  * Support OVMF images in virt-aa-helper. (LP: #1483071)
  * Fix the libvirt-bin.preinst to not stop libvirt-bin on upgrade
    from 1.2.16-2ubuntu7.

 -- Serge Hallyn <email address hidden> Fri, 14 Aug 2015 07:34:30 -0500

Changed in libvirt (Ubuntu):
status: New → Fix Released
Revision history for this message
Gannet (ken20001) wrote :

I've already 1.2.16-2ubuntu8 but error still appears:

Не вдалося завершити встановлення: «внутрішня помилка: не вдалося завантажити профіль AppArmor «libvirt-ba2976da-97bc-4f63-a9f6-66a8f1b23f38»»

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1873, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 414, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 478, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3497, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: внутрішня помилка: не вдалося завантажити профіль AppArmor «libvirt-ba2976da-97bc-4f63-a9f6-66a8f1b23f38»

What is wrong?

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Gannet, this feels like it might be influenced by restarting the libvirt-bin service; try this:

sudo service libvirt-bin restart

Then try recreating the new virtual machine.

Thanks

Revision history for this message
Gannet (ken20001) wrote :

I tried it yesterday:

'systemctl service libvirt-bin.service'

but not helped. Today my machine newly booted but the same massage still appears:

Не вдалося завершити встановлення: «внутрішня помилка: не вдалося завантажити профіль AppArmor «libvirt-75ecf2fe-fc4e-448d-a278-61fabcaf1851»»

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1873, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 414, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 478, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3497, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: внутрішня помилка: не вдалося завантажити профіль AppArmor «libvirt-75ecf2fe-fc4e-448d-a278-61fabcaf1851»

Revision history for this message
Gannet (ken20001) wrote :

Oh, I ment:
'systemctl restart libvirt-bin.service'

Gannet (ken20001)
Changed in libvirt (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Hi,

Is the failure exactly the same as before? Does it persist if you try with a newly defined VM?

Revision history for this message
Gannet (ken20001) wrote :

Yes, each time I'm checking by creating a new VM. Recently checked again and againe have got the same:

Не вдалося завершити встановлення: «внутрішня помилка: не вдалося завантажити профіль AppArmor «libvirt-a05215eb-12ea-498b-a168-45708c63e8bc»»

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1873, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 414, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 478, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3497, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: внутрішня помилка: не вдалося завантажити профіль AppArmor «libvirt-a05215eb-12ea-498b-a168-45708c63e8bc»

Revision history for this message
Peter Kieser (pfak) wrote :

https://www.redhat.com/archives/libvir-list/2015-August/msg00761.html

Might also be required for UEFI under libvirt with AppArmor enabled.

Revision history for this message
Gannet (ken20001) wrote :

I'm stil having this issue, even with apparmor stopped (through systemctl stop apparmor):

Не вдалося завершити встановлення: «внутрішня помилка: не вдалося завантажити профіль AppArmor «libvirt-656c15f3-4203-45df-bfcf-261421c96962»»

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1873, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 414, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 478, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3497, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: внутрішня помилка: не вдалося завантажити профіль AppArmor «libvirt-656c15f3-4203-45df-bfcf-261421c96962»

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Gannet, can you include the new DENIED lines?

Thanks

Revision history for this message
Gannet (ken20001) wrote :

What do you mean under "DENIED lines"? Do you mean asking me to show line 89 of asyncjob.py file etc?

Revision history for this message
Gannet (ken20001) wrote :
Download full text (3.6 KiB)

/usr/share/virt-manager/virtManager/asyncjob.py:

def cb_wrapper(callback, asyncjob, *args, **kwargs):
    try:
        callback(asyncjob, *args, **kwargs) <------------------------------------line 89
    except Exception, e:
        # If job is cancelled, don't report error to user.
        if (isinstance(e, libvirt.libvirtError) and
            asyncjob.can_cancel() and
            asyncjob.job_canceled):
            return

/usr/share/virt-manager/virtManager/create.py:

# Build a list of pools we should refresh, if we are creating storage
        refresh_pools = []
        for disk in guest.get_devices("disk"):
            if not disk.wants_storage_creation():
                continue

            pool = disk.get_parent_pool()
            if not pool:
                continue

            poolname = pool.name()
            if poolname not in refresh_pools:
                refresh_pools.append(poolname)

        logging.debug("Starting background install process")
        guest.start_install(meter=meter) <------------------------------------line 1873
        logging.debug("Install completed")

/usr/share/virt-manager/virtinst/guest.py, line 414

# Create devices if required (disk images, etc.)
            if not dry:
                for dev in self.get_all_devices():
                    dev.setup(meter)

            start_xml, final_xml = self._build_xml(is_initial)
            if return_xml:
                return (start_xml, final_xml)
            if dry:
                return

            # Remove existing VM if requested
            self.check_vm_collision(self.conn, self.name,
                                    do_remove=self.replace)

            self.domain = self._create_guest(meter,
                                             start_xml, final_xml, is_initial,
                                             noboot) <---------------------------------------------line 414
            # Set domain autostart flag if requested
            self._flag_autostart()

            return self.domain
        finally:
            self.installer.cleanup()

    def continue_install(self, meter=None,
                         dry=False, return_xml=False):
        """

/usr/share/virt-manager/virtinst/guest.py, line 478

"""
        Actually do the XML logging, guest defining/creating

        @param is_initial: If running initial guest creation, else we
                           are continuing the install
        @param noboot: Don't boot guest if no install phase
        """
        meter = self._build_meter(meter, is_initial)
        doboot = not noboot or self.installer.has_install_phase()

        if is_initial and doboot:
            dom = self.conn.createLinux(start_xml or final_xml, 0) <--------------line 478
        else:
            dom = self.conn.defineXML(start_xml or final_xml)
            if doboot:
                dom.create()

        self.domain = dom
        meter.end(0)

        self.domain = self.conn.defineXML(final_xml)

/usr/lib/python2.7/dist-packages/libvirt.py, line 3497

# virConnect functions from module libvirt-domain
    #

    def createLinux(self, xmlDesc, flags=0):
        """Deprecated after...

Read more...

Revision history for this message
Gannet (ken20001) wrote :
Download full text (3.6 KiB)

Also, here is /var/log/audit/audit.log contents after I tried to create VM with OVMF:

type=DAEMON_START msg=audit(1444934142.375:5639): auditd start, ver=2.4.2 format=raw kernel=4.3.0-040300rc5-generic auid=4294967295 pid=12344 subj=unconfined res=success
type=USER_END msg=audit(1444934148.419:29): pid=11588 uid=0 auid=1000 ses=2 msg='op=PAM:session_close acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
type=CRED_DISP msg=audit(1444934148.419:30): pid=11588 uid=0 auid=1000 ses=2 msg='op=PAM:setcred acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
type=USER_CMD msg=audit(1444934243.028:31): pid=12445 uid=1000 auid=1000 ses=2 msg='cwd="/var/log" cmd=6364206175646974 terminal=pts/1 res=failed'
type=USER_CMD msg=audit(1444934248.832:32): pid=12446 uid=1000 auid=1000 ses=2 msg='cwd="/var/log" cmd="-bash" terminal=pts/1 res=success'
type=CRED_REFR msg=audit(1444934248.832:33): pid=12446 uid=0 auid=1000 ses=2 msg='op=PAM:setcred acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
type=USER_START msg=audit(1444934248.832:34): pid=12446 uid=0 auid=1000 ses=2 msg='op=PAM:session_open acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
type=VIRT_RESOURCE msg=audit(1444934343.674:35): pid=841 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=disk reason=start vm="ubuntu13.10" uuid=e051ead3-f52b-4655-9e83-e7f783a6f912 old-disk="?" new-disk="/var/lib/libvirt/images/ubuntu13.10.qcow2" exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1444934343.674:36): pid=841 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=disk reason=start vm="ubuntu13.10" uuid=e051ead3-f52b-4655-9e83-e7f783a6f912 old-disk="?" new-disk="/var/lib/libvirt/images/ubuntu-15.04-server-amd64.iso" exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1444934343.674:37): pid=841 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=start vm="ubuntu13.10" uuid=e051ead3-f52b-4655-9e83-e7f783a6f912 old-net="?" new-net="52:54:00:ab:b9:85" exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1444934343.674:38): pid=841 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start vm="ubuntu13.10" uuid=e051ead3-f52b-4655-9e83-e7f783a6f912 bus=usb device=555342207265646972646576 exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1444934343.674:39): pid=841 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=dev reason=start vm="ubuntu13.10" uuid=e051ead3-f52b-4655-9e83-e7f783a6f912 bus=usb device=555342207265646972646576 exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1444934343.674:40): pid=841 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=mem reason=start vm="ubuntu13.10" uuid=e051ead3-f52b-4655-9e83-e7f783a6f912 old-mem=0 new-mem=2097152 exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=success'
type=VIRT_RESOURCE msg=audit(1444934343.674:41): pid=841 uid=0 auid=4294967295 ses=42949672...

Read more...

Revision history for this message
Gannet (ken20001) wrote :

Note, that previous audit.log I've got after installing auditd and tried to create an VM with OVMF and recieved an arror that noted in comment #11. Then I looked into /var/log/audit/audit.log file and here it is content in comment #15.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Thanks Gannet; all your error messages mentioned AppArmor, so I expected to see some DENIED lines from AppArmor preventing libvirt access to files or resources.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1483071] Re: Error creating new VM with OVMF

Hi Seth,

Quoting Seth Arnold (<email address hidden>):
> Thanks Gannet; all your error messages mentioned AppArmor, so I expected
> to see some DENIED lines from AppArmor preventing libvirt access to
> files or resources.

Actually I'm not sure. The error comes in the loading of the apparmor
policy, so I'd assume this is a apparmor userspace problem, well bad
aa policy generated by libvirt I assume)

Revision history for this message
Gannet (ken20001) wrote :

Also I wanna note again that I did:

systemctl stop apparmor.service

But it didn't helped.

Revision history for this message
Jean-Pierre van Riel (jpvr) wrote :

I have encoutered a similar bug related to the libvirt per guest AppArmor profile helper, libvirt-aa-helper

Virtual Machine Manager GUI reports
---
Error starting domain: internal error: process exited while connecting to monitor: 2015-11-16T09:39:50.572025Z qemu-system-x86_64: -drive file=/var/lib/libvirt/qemu/nvram
...
bvirtError: internal error: process exited while connecting to monitor: 2015-11-16T09:39:50.572025Z qemu-system-x86_64: -drive file=/var/lib/libvirt/qemu/nvram/Win10Raw_VARS.fd,if=pflash,format=raw,unit=1: Could not open '/var/lib/libvirt/qemu/nvram/Win10Raw_VARS.fd': Permission denied
---

And here is the AppArmour error seen in dmesg
---
[ 5576.944602] audit: type=1400 audit(1447663737.977:80): apparmor="DENIED" operation="open" profile="libvirt-bf7063cc-3a6a-4359-88a4-c84bb625a421" name="/var/lib/libvirt/qemu/nvram/Win10Raw_VARS.fd" pid=2802 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=123 ouid=123
---

As per http://wiki.apparmor.net/index.php/Libvirt, virt-aa-helper is used and as per https://www.redhat.com/archives/libvir-list/2015-August/msg00534.html there's a bugfix. However, it still doesn't include and cater for using NVRAM VAR OVMF files generated at /var/lib/libvirt/qemu/nvram/<domain>_VARS.fd.

The fix for this seems to be in this commit: http://libvirt.org/git/?p=libvirt.git;a=commit;h=91fdcefa7f145c1c39acc8e9a44fbfbf11568e54

The issue is that the libvirtd version in the ubuntu repo for 15.10 is too old to include the patch (i.e. v1.2.16)?

Revision history for this message
Jean-Pierre van Riel (jpvr) wrote :

A work-arround is to (ab)use the template file /etc/apparmor.d/libvirt/TEMPLATE.qemu

---
profile LIBVIRT_TEMPLATE {
  #include <abstractions/libvirt-qemu>
  /var/lib/libvirt/qemu/nvram/*_VARS.fd rw,
}
---

I'm not too familiar with AppArmour, nor kvm/libvirt's security model, but I assume the whole point of virt-aa-helper is to create custom per VM apparmor profiles with domain specific file names, so *_VARS.fd is technically insecure given all guest processes could in theory write to the EFI/OVFM NVRAM image files and proper guest vs guest isolation requires the fix in virt-aa-helper.

Revision history for this message
Gannet (ken20001) wrote :

Adding this line

> /var/lib/libvirt/qemu/nvram/*_VARS.fd rw,

into

/etc/apparmor.d/libvirt/TEMPLATE.qemu

didn't helped.

Interesting things: error messages says it can't load AppArmor profile "libvirt-203121ff-6933-4707-a851-3de158af5968". But it is really absent in

/etc/apparmor.d/libvirt

So why it is absent and what application should create it and when ?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

@jpvr,

The patch for virt-aa-helper to handle the nvram files is upstream, and should hit xenial with the next merge. Then you shouldn't need the template workaround.

Changed in libvirt (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Zycorax (zycorax-0) wrote :

I am a virt-manager and OVMF user and I think that the patch proposed and present in recent versions don't fix the issue here. In particular, virt-aa-helper allows to load firmware from /usr/share/ovmf/, while virt-manager's and libvirt's default path is /usr/share/OVMF. Fixing this path manually in /etc/libvirt/qemu.conf fixed the issue for me, however I feel that virt-aa-helper should allow both paths as valid. Note that the ovmf package installs in both, /usr/share/ovmf being for the united image and /usr/share/OVMF for the split CODE/VARS

Revision history for this message
Darth Revan (darth-revan43) wrote :

Thnak you @zycorax-0. That solved the problem for me.

Revision history for this message
Tuomas Heino (iheino+ub) wrote :

Reproduced the issue(*) with Xenial / 1.2.21-2ubuntu4.

Following Zycorax's line of thinking(**), binary-patched virt-aa-helper to get rid of the error.
$ perl -pi -e s/ovmf/OVMF/ virt-aa-helper

*: selecting UEFI when creating vm with virt-manager fails to create vm and giving the apparmor profile load error instead.
**: as well as further background discussions on the topic like https://www.redhat.com/archives/virt-tools-list/2014-September/msg00141.html referring to unified OVMF.fd as a dead-end solution.

Revision history for this message
Ryan Harper (raharper) wrote :
Download full text (3.2 KiB)

Ran into this bug trying to test running under UEFI.

I was able to get the VM booting (but it dropped into the EFI shell, no quite sure, but possible related to the use of the two files versus the single-combined file). Here's how I reproduced the issue:

On xenial amd64 host,

- sudo add-apt-repository multiverse
- sudo apt install uvtool uvtool-libvirt ovmf
- uvt-simplestreams-libvirt sync --source http://cloud-images.ubuntu.com/daily release=xenial arch=amd64
- uvt-kvm create --memory 1024 --cpu 4 --disk 10 x1 release=xenial arch=amd64
- virsh stop x1
- virsh edit x1
Add inside <os> section:
<os>
  ...
  <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
  <nvram template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/qemu/nvram/x1_VARS.fd</nvram>
  ...
</os>
- virsh start x1
... failed to start x1

This bug suggests to update the aa profile, but as already mentioned, this
complained about loading the profile. This comment here[1] helped me debug
and diagnose the issue. It appears that /usr/share is hardcoded as a no-go
place for libvirt/qemu to read from and hence aa denies access to the files.

I debugged that with:

% virsh dumpxml x1 | sudo /usr/lib/libvirt/virt-aa-helper -c -u libvirt-`virsh domuuid x1` x1
virt-aa-helper: error: /usr/share/OVMF/OVMF_CODE.fd
virt-aa-helper: error: skipped restricted file
virt-aa-helper: error: invalid VM definition

Even adding:

  /usr/share/OVMF/OVMF_CODE.fd r,

to the template didn't help either. The comment from jdstrand made me think this was
hardcoded and couldn't be changed, so decided to relocate the OVMF files to a place where
libvirt and qemu can read them.

sudo cp /usr/share/OVMF/OVMF* /var/lib/uvtool/libvirt/images/

And updated the x1 xml with the correct path to the OVFM files, then re-run the virt-aa-helper:

(funkmetal) libvirt % virsh dumpxml x1 | sudo /usr/lib/libvirt/virt-aa-helper -c -u libvirt-`virsh domuuid x1` x1
(funkmetal) libvirt % cat libvirt-`virsh domuuid x1`.files
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
  "/var/log/libvirt/**/x1.log" w,
  "/var/lib/libvirt/qemu/domain-x1/monitor.sock" rw,
  "/var/run/libvirt/**/x1.pid" rwk,
  "/run/libvirt/**/x1.pid" rwk,
  "/var/run/libvirt/**/*.tunnelmigrate.dest.x1" rw,
  "/run/libvirt/**/*.tunnelmigrate.dest.x1" rw,
  "/var/lib/uvtool/libvirt/images/x1.qcow" rw,
  "/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MTYuMDQ6YW1kNjQgMjAxNjAxMDU=" r,
  # don't audit writes to readonly files
  deny "/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MTYuMDQ6YW1kNjQgMjAxNjAxMDU=" w,
  "/var/lib/uvtool/libvirt/images/x1-ds.qcow" rw,
  "/var/lib/uvtool/libvirt/images/OVMF_CODE.fd" r,
  # don't audit writes to readonly files
  deny "/var/lib/uvtool/libvirt/images/OVMF_CODE.fd" w,
  "/var/lib/libvirt/qemu/nvram/x1_VARS.fd" rw,
  /dev/vhost-net rw,
(funkmetal) libvirt % cat libvirt-`virsh domuuid x1`
#
# This profile is for the domain whose UUID matches this file.
#

#include <tunables/global>

profile libvirt-10a7b819-a30e-4155-b61f-4402fc2daed2 {
  #include <abstractions/libvirt-qemu>
  #include <libvirt/libvirt-10a7b819-a30e-41...

Read more...

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

The patch to fix this should be 91fdcefa7f145c1c39acc8e9a44fbfbf11568e54 upstream. It is in the xenial package. So I'm marking this fix released and SRUing for wily.

Do we need this SRU'd to trusty too?

Changed in libvirt (Ubuntu Wily):
importance: Undecided → High
Changed in libvirt (Ubuntu):
status: Confirmed → Fix Released
importance: Medium → High
description: updated
Revision history for this message
Gannet (ken20001) wrote :

Since trusty is LTS, I think this wouldn't be superfluous.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libvirt (Ubuntu Trusty):
status: New → Confirmed
Changed in libvirt (Ubuntu Wily):
status: New → Confirmed
Revision history for this message
Gannet (ken20001) wrote :

In what libvirt version it will be fixed ?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Should be in the next version that gets SRUd, but that likely won't happen until after the 16.04 feature freeze (in 8 days).

Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Gannet, or anyone else affected,

Accepted libvirt into wily-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/1.2.16-2ubuntu11.15.10.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in libvirt (Ubuntu Wily):
status: Confirmed → Fix Committed
tags: added: verification-needed
Revision history for this message
Gannet (ken20001) wrote :

Hello. Sorry, I can't check in Wily. I'm using Xenial already and finally it works in it! Thanks.

Revision history for this message
Brian Murray (brian-murray) wrote :

Hello Gannet, or anyone else affected,

Accepted libvirt into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/1.2.2-0ubuntu13.1.18 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in libvirt (Ubuntu Trusty):
status: Confirmed → Fix Committed
Revision history for this message
Adam Conrad (adconrad) wrote :

Hello Gannet, or anyone else affected,

Accepted libvirt into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/1.2.2-0ubuntu13.1.19 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Mathew Hodson (mhodson)
Changed in libvirt (Ubuntu Trusty):
importance: Undecided → High
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote : [libvirt/wily] verification still needed

The fix for this bug has been awaiting testing feedback in the -proposed repository for wily for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

tags: added: removal-candidate
Revision history for this message
Martin Pitt (pitti) wrote : Proposed package removed from archive

The version of libvirt in the proposed pocket of Trusty that was purported to fix this bug report has been removed because the bugs that were to be fixed by the upload were not verified in a timely (105 days) fashion.

Changed in libvirt (Ubuntu Trusty):
status: Fix Committed → Won't Fix
Revision history for this message
Gannet (ken20001) wrote :

I'm sorry but I have no trusty VM machines anymore to check it.

Revision history for this message
Mathew Hodson (mhodson) wrote :

The package was removed due to its SRU bug(s) not being verified in a timely fashion.

Changed in libvirt (Ubuntu Wily):
status: Fix Committed → Won't Fix
tags: removed: removal-candidate verification-needed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.