What a day. I spent about 10 hours working solely on KVM virtualization. I have installed the Fedora virtualization package (sudo yum groupinstall ‘Virtualization’) and I worked through the SELinux concerns with choosing an alternate location for your virtual disk images (which are stored in a qcow2 format, btw – weird). The standard location for one’s virtual machine disks is /var/lib/libvirt/images, apparently, and it uses the SELinux context type virt_image_t, so when one chooses a new location to store items which should be of that type, one must apply that context to the folder and its child items as so:
semanage fcontext -a -t virt_image_t “/folder/path(/.*)?”
sudo restorecon -R /folder/path/
I did this somewhat out of a formality I keep with my system for the sake of sanity and organization, but largely out of the knowledge that I’m going to make a substantial number of VMs and I want adequate space, so I put them on a separate hard disk.
Beyond that, SELinux complains that the SE Boolean variable virt_use_execmem needs to be set to 1 rather than 0 to allow the qemu-system-x86_64 process to do something it wanted to do. Some Internet searching was relatively fruitless, though it did demonstrate that others had this issue, it just failed to provide any explanation for it.
The manpage for virt_selinux reads as follows:
If you want to allow confined virtual guests to use executable memory and executable stac, you must turn on the virt_use_execmem boolean.
From that, I can grasp loosely the security issue at hand, and it is likely related to the capacity for a compromised virtual guest domain to adversely impact the host. I think I can risk it while I do very sane, bare-bones things to get my VMs up and running at the beginning. More research is clearly warranted, but no need to halt progress.
I get some other SELinux alerts (and I’m in enforcing mode, so it’s actually blocking activity) whose descriptive text reads:
Error: The source process: /usr/bin/qemu-system-x86_64 attempted this access: search
On this directory:
The directory is blank, as I have it, but the details seem to yield that it is perhaps an inquiry into the /proc virtual directory. I will likely build an SELinux module to allow this behavior once I get the time to exercise due diligence and ensure I’m not doing something horribly stupid.
Beyond that, I had to perform the arduous task of learning to use these virtualization tools. It is an unfortunate fact that the open source community is lacking in documentation, and I found this area to be particularly rough going. It’s a good thing I had a lot of experience with Hyper-V on the Windows side prior to this; I certainly don’t recommend learning about virtualization for the first time with KVM in Fedora 20 without a thoroughly good manual or text which I cannot find (referrals and/or advice welcome).
I’d like to post more about it, but I’ll wait until I know more about it. I did manage to get a Fedora 20 VM and a CentOS 6.5 VM up and running, connected to my host network adapter, and fully updated, so success has been had, but it’s no assurance of the remaining work’s completion. Getting interrupt remapping to work with my setup may require intervention from Gigabyte developers (see the previous post). If that fails, I may be able to modify the kernel to ignore the error, so long as it turns out to be ignore-able (and some theories seem to point that way) and proceed nonetheless, but as I wrote previously, vendor support here is obviously preferred.
I will offer this, though, as an example command for installing your own virtual machine:
First, I have to note that I ran into less SELinux alerts after I went into virt-manager’s GUI and stepped through the build process. I received a few messages such as:
The emulator may not have search permissions for the path
Do you want to correct this now?”
That may have been a significant part of my SELinux work I mentioned previously, so if you’re still having SELinux trouble, give it a shot. I can’t tell if it’s modifying context information or file modes (brief investigation was inconclusive) but whatever it did, it, combined with the rest of the work described above, got rid of some SELinux difficulty.
The command, then:
sudo virt-install –hvm –video vga -n DemoVM –memory=4096 –cpu host \
–cdrom /demoVMinstallLocation/Fedora-Live-Desktop-x86_64-20-1.iso –livecd –os-variant fedora20 \
That creates from the Fedora-Live-Desktop ISO file I obtained from their site a DemoVM, fully virtualized (not paravirtualized), with 4 GB of RAM assigned to it, the host machine’s CPU specs exactly, customized for the Fedora 20 OS, with its disk image in my custom disk path (whose SELinux type context I modified per the instructions above) which is called DemoVM.qcow2 and is limited to 50 GB in size. Notice too that the –livecd option informs virt-install that the media being used is a Live CD, which is important.
Once you install the OS, you’ll need to dismount the cd-rom ISO from it (and I lazily did it through virt-manager, I’ll admit it). But that’s it! Create a network adapter bridge in your virt-manager (similar enough to Hyper-V that it shouldn’t be too hard to figure out; if you don’t have any analogous experience to draw on here, I doubt you got this far yet – like I said, rough waters) and get your updates!
Finally, I recommend checking out the man pages for virsh and not solely making use of virt-manager, since professional production environments will often lack GUI options.