Communication between host and guest VM when using virt-manager

Tutorials & Resources
41

Yes, you´re right. I was just reading up on the topic in the ubuntuusers-wiki and found out the same.

Right. I guess so, too. I might also give it a try on my main system. But as Linux Lite doesn´t have it by default I would have to create the rc.local file first.
Your fooslinux link provides some really good information for that, I think.

Thanks a lot, Neville

Cheers from Rosika :slightly_smiling_face:

UPDATE:

according to rc.local › Archiv › Wiki › ubuntuusers.de :

The rc.local file has been obsolete since 1983.
It served as a workaround for maintaining even older methods for system initialization the then new, now obsolete SysV-init system.

Services and scripts are started since version Ubuntu 15.04 via service units.

From Ubuntu 18.04 LTS onwards /etc/rc.local no longer exists by default.
It is also not recommended to set up such one manually.

An alternative option can be an entry @reboot under the file setting in /etc/crontab.

(translation via “TranslateLocally for Firefox” add-on)
(bold by me)

I guess the last sentence could provide a potential solution… :thinking: .

Many greetings from Rosika :slightly_smiling_face:

UPDATE 2:

I guess this would be the easiest way:

crontab -e, and then:

@reboot /path/to/script.sh

The @reboot keyword in the cron job entry specifies that the script should be executed when the system starts up.

After adding the entry to your crontab, the script will run each time your user account logs in. It won’t affect other user accounts on the system.

Also:

Make sure that the script you want to run has the execute permission (chmod +x /path/to/script.sh)
and that the script itself does not have any dependencies on the graphical environment or user session, as cron jobs typically run in a non-graphical environment. :wink:

It´s also possible to introduce a time delay (if you so wish) after system startup
before executing the script using cron. Instead of using the @reboot keyword alone, you can combine it with the sleep command to introduce a delay.

This should cover it:

@reboot sleep 300 && /path/to/script.sh

In this example, sleep 300 introduces a delay of 300 seconds (equivalent to 5 minutes) before executing the script.
That´s just an example, of course. You can add any user-defined delay you want.

Many greetings from Rosika :slightly_smiling_face:

2 Likes
42

[quote=“Rosika Schreck, post:41, topic:10841, username:Rosika”]The @reboot keyword in the cron job entry specifies that the script should be executed when the system starts up.
[/quote]
Hi Rosika,
I did not know cron could do that at reboot.
That sounds like a fine solution
Systemd is too complicated and only works in some distros
I will try it too, we need a sound recommdndation that will work in all distros
Regards
Neville

2 Likes
43

Hi Neville, :wave:

I guess the cronjob might me the simplest solution.
Don´t know, perhaps there´s even something simpler out there… something I don´t know of.

I also did some further research on the matter and for those who like to have any command or script be executed in a a time-delayed way, here´s an addirional note:

Keep in mind that the delay will be relative to the system startup time, so if the system takes longer to boot up, the actual execution of the script will be delayed accordingly.

Many greetings

Rosika :slightly_smiling_face:

2 Likes
44

This is a joint post by @nevj and @Rosika

and

Addendum

Making a virtiofs mount permanent

See reply No 3 in this topic for information on setting up a virtiofs mount
in virt-manager.

Unfortunately, in reply No.3 “Virtiofs filesystem mounts” we made the statement

“It is not possible to put a virtiofs mount in /etc/fstab
in the guest system. You have to remount it every time
you boot the guest system.”

That statement is incorrect.

To make a virtiofs mount
occur automatically every time a guest VM is booted,
put the following entry in /etc/fstab in the guest system

mnt-tag  /mnt/mymount  virtiofs  rw,relatime  0 0

Using virt9p instead of virtiofs

Virtiofs is only supported in systems with kernel version 5.4 or greater
and it requires libvirt6 or greater.
An alternative in older systems is to use virt9p in place of virtiofs.
The setup is the same, except choose virt9p

The mount statement in the guest for virt9p is

mount -t 9p mount-tag /mnt/mymount

and the line to put in /etc/fstab is

mount-tag /mnt/mymount 9p rw,relatime 0 0

Alternatives to using /etc/fstab

A search for alternatives considered using /etc/rc.local but that is
deprecated and not available in all distros.
The most promising alternative seemed to be to use cron.

Setting up crontab to do a mount on reboot

The following steps are needed in the guest system

  • setup a virtiofs mount as in reply No 3.
  • make sure the cron daemon is running
  • make a script file to do the mount
#! /bin/bash
mount -t virtiofs mount-tag /mnt/mymount

call the file mountscript.sh

  • put the script file somewhere like ~/bin

  • make the script file executable

  • as superuser, edit the system-wide crontab file /etc/crontab with any text editor, and add the line

@reboot root /path/to/mountscript.sh
  • Reboot and it should mount automatically

Permission issues with virtiofs mounts

The shared file on the host that is going to be mounted by the guest
should ideally be owned by the same user and group as is used in the guest, and the UID and GID should be the same too.

If this is not the case the same permission rules apply as would apply within a single operating system. So a different user in the guest may only be able to read files in the mounted filesystem, depending on its permissions for group and other.

Copy/paste issues with virt-manager

If one wishes to copy/paste between a guest window and the host, it is
necessary to install the package spice-vdagent in the guest.
After this package is installed there should be 2 daemons running in
the guest

   $ ps ax | grep spice
   1089 ?        Ssl    0:00 /usr/sbin/spice-vdagentd
   1488 ?        Ssl    0:00 /usr/bin/spice-vdagent

If they are not both running, try a reboot. If that fails start them by hand.

Links

VirtioFS — RavadaVDI documentation

https://unix.stackexchange.com/questions/109117/virt-manager-copy-paste-functionality-to-the-vm

1 Like
45

The markdown files used to produce replies in this topic can be found here

2 Likes
46

There is a follow up topic on virt-manager with a FreeBSD guest

1 Like