Fedora 18 KVM guest in Fedora 17 - few tips and tweaks

Making sure KVM tools not pointing to the wrong (vbox) URI

I decided to try the Fedora 17 command line kvm (libvirtd) tools to create a Fedora 18 virtual machine. This was met with failure, although for some reason the GUI tool, virt-manager, worked fine for this purpose. (I still don't know why the GUI "just worked", when the command line did not - I guess it assumes the correct URI while the command line tools do not.)

I was following the Fedora VM "Getting Started" guide found here and even the simplest commands resulted in failure.


# virt-install --prompt
ERROR    Error in network device parameters: Virtual network 'default' does not exist: An error occurred, but the cause is unknown

# virsh dumpxml default
error: failed to get domain 'default'
error: An error occurred, but the cause is unknown

# virsh net-list --all
Name                 State      Autostart
-----------------------------------------

# virsh net-start default
error: failed to get network 'default'
error: An error occurred, but the cause is unknown

# virsh net-define default
error: Failed to open file 'default': No such file or directory

The problem turned out to be that the tools based on libvirt (virsh, virt-install, virt-viewer, and others) seem to default to the Virtualbox URI  on my system (I have and use Virtualbox on the same system).

This can be demonstrated by doing

# virsh uri
vbox:///system

I had inferred this by doing

#LIBVIRT_DEBUG=1 virsh list --all

and then noticing a lot of debug messages related to the vbox driver which seemed wrong to me.

If this is the problem then the fix is easy. We just need to specify the QEMU URI on the command line with "-c" like so

# virsh -c qemu:///system uri
qemu:///system

# virsh -c qemu:///system  net-list --all
Name                 State      Autostart
-----------------------------------------
default              active     yes   

or alternatively just specify the LIBVIRT_DEFAULT_URI as an environment variable.

#export LIBVIRT_DEFAULT_URI=qemu:///system

Also looks like /etc/libvirt/libvirt.conf allows a default URI to be specified as well. 

Once any of these are done all the libvirtd commands produce the expected results.

Making the "shutdown" command work from the host

I  had some trouble making the shutdown command work from either the virsh command line, or from the Virtual Manager GUI controls. I think a total of 4 things are needed.

  1. (On Host) The VM must have been created with acpi enabled. It's said that the simplest test for this is to look for acp in the output of the virsh dumpxml command - something like
    #virsh dumpxml MYVMNAME | grep -C 4 acpi
    should produce some output.  If not present it might be possible to edit the xml, but if not the VM will have to be recreated this time with acpi support.
  2. (On Guest) The guest OS needs acpid downloaded and running.
    sudo yum install acpid
    -- reboot --
    ps waux | grep acpid (should show acpid running).
  3. (On Host) Edit /etc/init.d/libvirt-guests to specify something likeON_SHUTDOWN=shutdown
    SHUTDOWN_TIMEOUT=10
  4. (On Guest) Edit /etc/acpi/actions/power.sh and remove logic that requires that a a power manager not be running before shutdown action is undertaken. Until I took this step (but had completed 1-3 above) I noted that the shutdown action was received in the guest and logged in /var/log/messages but was rejected with something like "dbus - rejected send message".  In truth, my version of this file simply issues the shutdown command and that's it.

Allow cut and paste from guest to host

Basically what's needed is SPICE and spice-vdagentd (on the guest). So on the guest one needs to do 
# yum install spice-vdagent
# chkconfig spice-vdagentd on
# shutdown -r now
If you look here you'll see how to have SPICE as the display type in the guest but in my case this seems to have been done by default.

Allow sharing of files from host to guest (but apparently not the other way round)

Uses the 9p virtio filesystem.

Follow these instructions on the host. I used the GUI based instructions by adding a filesystem to my VM. Then on the guest I was able to do

# mkdir /mnt/host_files
# mount -t 9p -o trans=virtio,version=9p2000.L /hostshare /mnt/host_files


Which I then turned into an /etc/fstab entry like this:


/hostshare /mnt/host_files/hostshare  /mnt/host_files 9p trans=virtio,version=9p2000.L 0 0

With this approach there are permissions issue

# ls -dal /mnt/host_files
drwxr-xr-x. 2 500 500 4096 Dec 30 11:24 /mnt/host_files

which I have to this point been unable to fix with chown, chmod etc. and thus I cannot write to this directory from the guest but I am perfectly able to write to /tmp/share on the host and read from /mnt/host_files from the guest. Alternatively one can use scp to move files between guest and host - the ip address of the host can be gotten from the routel command. Or perhaps there is a way to fix the directory ownership (The problem is that the mount operation changes owner and group to 500 where 500 is not a normal user or group. And after that occurs the ownership can't be changed even by root.)


Comments

Popular posts from this blog

Hit failing alternator with a hammer to confirm diagnosis of failing alternator due to bad brushes

alternatives --install gets stuck: failed to read link: No such file or directory

Using SSH, SOCKS, tsocks, and proxy settings to create a simultaneous "dual use" work/home computer