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








Post a Comment













Popular posts from this blog









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





















Hitting something with a hammer often feels good but does nothing useful. Here's one case where it actually helps. On my 2004 Ford Explorer the alternator light came on. I brought it to the auto parts store and they put a volt meter on it. The alternator needs to put out a voltage that is higher than the battery's full charged voltage in order to properly function - somewhere in the 14 volt range. Mine came in low - probably below 13.5 volts. So the guy at the auto parts store took a rubber mallet to the alternator and just briefly, for a period of 10 seconds or maybe less the voltage jumped up into the normal range before falling back to where it was before. This confirmed the diagnosis of a bad alternator in general and worn brushes in particular. The brushes are spring loaded, are located in the are a wearable item and must make contact with the fixed part of the alternator. Tapping the alternator with the hammer temporarily changes spatial relationships between the brushes 








Read more










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





















 Alternatives utility gets stuck doing install. Fedora 17 x86_64.   Removing the /var/lib/alternatives/javaws file resolved the issue (for me).   # alternatives --install /usr/bin/javaws javaws /usr/java/jdk1.7.0_07/jre/bin/javaws  20000  failed to read link /usr/bin/javaws: No such file or directory    # ls /usr/bin/javaws  ls: cannot access /usr/bin/javaws: No such file or directory     # ls -al /var/lib/alternatives/javaws  -rw-r--r--. 1 root root 105 Sep 22 11:39 /var/lib/alternatives/javaws   # rm /var/lib/alternatives/javaws  rm /var/lib/alternatives/javaws  rm: remove regular file `/var/lib/alternatives/javaws'? y   # alternatives --install /usr/bin/javaws javaws /usr/java/jdk1.7.0_07/jre/bin/javaws  20000   # which javaws  /bin/javaws   # ls /usr/bin/javaws  /usr/bin/javaws    # ls -al /var/lib/alternatives/javaws  -rw-r--r--. 1 root root 65 Sep 22 11:50 /var/lib/alternatives/javaws   # cat /var/lib/alternatives/javaws  auto  /usr/bin/javaws   /usr/java/jdk1.7.0_07/jre/bin/








Read more










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





















       The Problem:  Allow one linux workstation to be simultaneously used for both work and non-work purposes so that work and non-work traffic are segregated.          The Requirements:  I would like to be able to use the following applications in the corporate environment    VNC  Web (typically Google Chrome but potentially other browsers as well)  Email - IMAP, SMTP, LDAP using Thunderbird  IM - pidgin    As already mentioned here  the corporate network has an SSH server that you authenticate and connect to and from there you can reach the other corporate network resources.     I would like non-work related traffic to bypass the corporate network - this is mostly web traffic but might also include things like Spotify, yum updates, and other assorted tasks.     Finally it would be nice (but not essential) to wrap all this up in a handy GUI operation or series of operations.          The Environment:   Fedora Core 16 (x86_64) and Gnome 3.        The Solution:   Use SSH, SOCKS, tsocks








Read more