Virtual Machine Manager (VMM)

[securitybreach]

Well mine are all set to where I ssh in as the normal user to access them via:

qemu+ssh://comhack@192.168.1.123:9686/system

As far as internet, they should all have internet. I just use the defaults which gives me internet but puts them on a virtual lan but you can choose host, tunnel, etc.

 

 

 

[Hedon James]

When I look at the qemu.conf file, it appears that all lines are commented out:

Quote

 

# The default security driver is SELinux. If SELinux is disabled

# on the host, then the security driver will automatically disable

# itself. If you wish to disable QEMU SELinux security driver while

# leaving SELinux enabled for the host in general, then set this

# to 'none' instead. It's also possible to use more than one security

# driver at the same time, for this use a list of names separated by

# comma and delimited by square brackets. For example:

#

# security_driver = [ "selinux", "apparmor" ]

#

# Notes: The DAC security driver is always enabled; as a result, the

# value of security_driver cannot contain "dac". The value "none" is

# a special value; security_driver can be set to that value in

# isolation, but it cannot appear in a list of drivers.

#

#security_driver = "selinux"

 

 

usually, I remove the # to enable a setting, or add a # to disable.  The entire file is commented with #, which makes me question what I think I know.  Do I just remove the # to enable what I want?  Or add an uncommented line that simply indicates:

Quote

security_driver = "none"

 

And should I be modifying the first section (default) with selinux & apparmor, or the 2nd section (DAC security) with selinux only?  It seems I should be modifying the default, correct? 

 

And scrolling that file, I also saw this section:

Quote

 

# Path to the setuid helper for creating tap devices. This executable

# is used to create <source type='bridge'> interfaces when libvirtd is

# running unprivileged. libvirt invokes the helper directly, instead

# of using "-netdev bridge", for security reasons.

#bridge_helper = "/usr/libexec/qemu-bridge-helper"

 

From earlier readings that I didn't understand, I recognize some of this to enable the shared network settings for a qemu:///session.  Is this where I enable the bridge interface for the virbr0 setting?  Same question as above...uncomment lines, or add new one?

 

[securitybreach]

Honestly, I have no idea as I do not use apparmor or selinux. Both are fine if you are in an enterprise environment but a complete overkill for a home user to use.

[securitybreach]

The network settings are done in virt-manager. I have never edited any config file for network settings or anything else.

[Hedon James]

14 hours ago, securitybreach said:

To disable apparmor for libvirt, run this as root:

 aa-complain /etc/apparmor.d/libvirt/libvirt-04e95526-692b-4409-88fe-b5b756ac5c17

 

 

I added the uncommented line security_driver = "none" to the qemu.conf but still get the error.  I tried the command above but got a message that aa-complain wasn't installed.  more googling and it appears its part of apparmor-utils, so installed that.  tried the above command again (but changing the UUID to match the error from virt-manager) and got this:

Quote

Profile for /etc/apparmor.d/libvirt/libvirt-9243c288-694d-44b3-bd88-e04cd02ac261 not found, skipping

 

that would certainly explain the error virt-manager displays:

Unable to complete install: 'internal error: cannot load AppArmor profile 'libvirt-9243c288-694d-44b3-bd88-e04cd02ac261''

But how to resolve?  WTH am I missing, or doing wrong?

[securitybreach]

I can do some googling when I get home but I know absolutely nothing about apparmor

[Hedon James]

Alternatively, trying to create a VM user qemu:///system (root), I get the following message after adding my *.vdi disk image on dev/sdc

 

This looks familiar in my old Lubuntu "proof of concept" setup so I hit yes....only to be greeted with THIS error:

 

And I'm back to the theory that virt-manager/qemu/kvm doesn't like my disks on a different dive as my /root or /home drive.  Starting to wonder if I haven't outsmarted myself and virt-manager was a mistake.  Virtualbox was never this complicated.

 

Any help would be much appreciated.

[securitybreach]

All of my VMs are on a separate drive than my install or home is located on so that's not the issue

[Hedon James]

14 minutes ago, securitybreach said:

I can do some googling when I get home but I know absolutely nothing about apparmor

 

me neither.  I had never even heard of apparmor before this issue.  aren't we a pair?

[Hedon James]

I'm wondering if this isn't helpful information:

https://wiki.ubuntu.com/LibvirtApparmor#preview

 

The section "uncommon paths" seems applicable.  I took a look inside the referenced file and see this section:

# for hostdev

/sys/devices/ r,

/sys/devices/** r,

/sys/bus/usb/devices/ r,

deny /dev/sd* r,

deny /dev/vd* r,

deny /dev/dm-* r,

deny /dev/drbd[0-9]* r,

deny /dev/dasd* r,

deny /dev/nvme* r,

deny /dev/zd[0-9]* r,

deny /dev/mapper/ r,

deny /dev/mapper/* r,

If I'm understanding correctly (and it's debatable whether I am), it looks like my virtual disk storage path /media/jim.... is being blocked by the line deny/dev/sd* r,

 

You said you're not familiar with apparmor, so wondering if you even have that directory & file.  Would be nice to compare contents if you did...

 

Don't want to seem pushy for a resolution, just trying to continue researching for myself.  And if it helps you with a diagnosis and proposed solution...even better!

Edited February 25, 2020 by Hedon James

[securitybreach]

Nope, I do not have that directory as I do not have apparmor installed. My VMs are on /dev/sdb1, mount /Drive1/VMs

 

[Hedon James]

Update:  I am not entirely convinced my issues with virt-manager are being driven by apparmor.  In the interests of science, I copied over my *vdi image to my /home directory on the same disk as my /root directory.  Proceeded to create a VM, using qemu:///session, and got a very similar failure error, as follows:

Unable to complete install: 'internal error: cannot load AppArmor profile 'libvirt-a370de2d-13e7-4980-9cfb-4aed2672937a''

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 2119, in _do_async_install
    guest.installer_instance.start_install(guest, meter=meter)
  File "/usr/share/virt-manager/virtinst/installer.py", line 419, in start_install
    doboot, transient)
  File "/usr/share/virt-manager/virtinst/installer.py", line 362, in _create_guest
    domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib/python3/dist-packages/libvirt.py", line 3732, in createXML
    if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirt.libvirtError: internal error: cannot load AppArmor profile 'libvirt-a370de2d-13e7-4980-9cfb-4aed2672937a'

Alternatively, using the same *vdi image on my /home directory, I created a VM using qemu:///system, as I've successfully done before, and TADA...there's my "Test VM" booting up and running in virt-manager.  So I'm guessing this is a permissions issue (root permissions of qemu:///system versus username permissions of qemu:///session), as I can create a VM using qemu:///system but not qemu:///session. 

 

However, conversely, while my VM creation using qemu:///session is successful with a *vdi image on my /home directory, the same *vdi image on my automounted 2nd HDD at /media/jim/sdc1/jim/home throws the permission error:

 

And I can't tell if this is a permissions issue for the root qemu:///system or a configuration issue for libvirt, or qemu, or apparmor?

 

So I CAN create a qemu:///system VM if the disk image is located in my /home directory; but it fails on external automounted drive (note location of attempted storage path).  Unfortunately, I cannot keep my VM disk images in /home directory, as my SSD isn't large enough.  They have to go on my 2nd 2TB HDD.  And as you pointed out, you do the same thing on your system.  Any thoughts on troubleshooting?

 

Ideally, I'd like to run my VMs with username in qemu:///session and disk images on external drive.  But I could live with my VMs running as qemu:///system sessions, with disk image on external drive...it's less than ideal because of permission issues with rsync backups, but working "less than ideal" is still working.  I can't run VMs on /home directory due to insufficient disk space. 

 

I'm not sure where to look next for solution...

 

[securitybreach]

Well if I guess, all of the errors are due to the top one:

 

unable to complete install: 'internal error: cannot load AppArmor profile 'libvirt-a370de2d-13e7-4980-9cfb-4aed2672937a''

[securitybreach]

Change the permissions of the VMs to your username:

 

chown -R hedon:users file

[Hedon James]

1 hour ago, securitybreach said:

Change the permissions of the VMs to your username:

 

chown -R hedon:users file

my VMs or my *vdi disk images?

 

my sdc disk image was indeed owned by root, so changed it to jim (username), but same error:

Unable to complete install: 'internal error: cannot load AppArmor profile 'libvirt-0f82c9ef-278d-4f2b-bb2f-3cf142f7d0e0''

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 2119, in _do_async_install
    guest.installer_instance.start_install(guest, meter=meter)
  File "/usr/share/virt-manager/virtinst/installer.py", line 419, in start_install
    doboot, transient)
  File "/usr/share/virt-manager/virtinst/installer.py", line 362, in _create_guest
    domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib/python3/dist-packages/libvirt.py", line 3732, in createXML
    if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirt.libvirtError: internal error: cannot load AppArmor profile 'libvirt-0f82c9ef-278d-4f2b-bb2f-3cf142f7d0e0'

 

 

[securitybreach]

 Apparmor is the root cause of your issue as noted by the top part of your error:

 

unable to complete install: 'internal error: cannot load AppArmor profile 'libvirt-0f82c9ef-278d-4f2b-bb2f-3cf142f7d0e0''

[securitybreach]

Basically the error is the top line, the next lines are trying to trace the error with the last line repeating the error.

[Hedon James]

You said apparmor is unnecessary and, in fact, overkill for a home user desktop scenario, correct?  If so, consider this resolved.

 

I nuked apparmor from the system.

sudo apt remove apparmor

it also took apparmor-utils with it, and I need to autoremove some orphans, but POOF....gone!

 

Tried to create a VM, but same errors.  Realized the libvirt.services probably needed to be restarted, so checked status:

sudo systemctl status libvirtd.service

sure enough, a red error line, so restarted service

sudo systemctl restart libvirtd.service

Tried to create a VM but same error.  Then realized that qemu/KVM is a kernel-based service, so maybe I needed to reboot the whole system.

 

Rebooted the system, tried to create a VM with user session and external disk image on /media/jim/sdc1 and TADA...there it is...VM booting in VMM.  THAT is what I've been looking for...exactly as desired!

 

Not sure what apparmor is, what it does, or why its installed by default on Debian 10, but it's gone now.  And VMM seems to be working (knock on wood) the way I thought it should.  I've probably swatted a fly with a sledgehammer, but I don't care right now.  I just need my VM available so I can use those windows-only programs that I need for my business!

 

Thanks for your help SB!

[securitybreach]

Sweet! Glad that it was just apparmor. This is why I said overkill

 

Quote

AppArmor is a Linux kernel security module that allows the system administrator to restrict programs' capabilities with per-program profiles. Profiles can allow capabilities like network access, raw socket access, and the permission to read, write, or execute files on matching paths.

 

https://en.wikipedia.org/wiki/AppArmor