7:29 p.m.
Thank you for the reply. I truly appreciate them.
I used virt-manager to set up my VMs and manage them on a daily basis.
After reading your responses I used the commands below to gather some
information:
$sudo virsh net-list --all
Name State Autostart Persistent
----------------------------------------------
default inactive no yes
$sudo virsh net-info default
Name: default
UUID: some-number
Active: no
Persistent: yes
Autostart: no
Bridge: virbr0
I thought it was interesting that the default network was not marked to
restart at boot and changed that:
$sudo virsh net-autostart default
Network default marked as autostarted
Then due to its inactive status, I thought it would be a good idea to
start it with:
$sudo virsh net-start default
Network default started
Of note, even though the default network was marked as inactive as
above, it was working. In other words, I was able to reach the VMs,
which are part of that network, even before the `virsh net-start
default` command. Nothing seemed to break with the command either, and
everyting still seemed to work afterwards.
$sudo virsh net-info default
Name: default
UUID: some-number
Active: yes
Persistent: yes
Autostart: yes
Bridge: virbr0
I would really appreciate if you can confirm that this is the desired
state for my network for the purposes I discussed previously. I
apologize if I am oversimplifying things here, it is because of my lack
of in-depth understanding the appropriate set up.
Thanks,
Hakan
On 22/01/24 05:30PM, Laine Stump wrote:
On 1/24/22 4:35 AM, Martin Kletzander wrote:
> On Fri, Jan 21, 2022 at 08:42:58AM -0600, Hakan E. Duran wrote:
> > Hi,
> >
> > I would like some help to troubleshoot the problem I have been having
> > lately with my VM host, which contains 5 VMs, one of which is for
> > pi-hole, unbound services. It has been a relatively common occurrence in
> > the last few weeks for me to find that the host machine has lost its
> > network when I get back home from work. Restoring the VM/VMs do not fix
> > the problem, the host needs to be restarted for a fix, otherwise there
> > is both loss of name resolution, as well as an internet connection; I
> > cannot ping even IPs such as 8.8.8.8. Since I use the pi-hole VM as
> > the DNS
> > server for my LAN, this means that my whole LAN gets disconnected from
> > internet, until the host machine is rebooted. The host machine has a
> > little complicated network setup: the two gigabit connections are bonded
> > and bridged to the VMs; however this set up has been serving me so well
> > for several years now. The problem, on the other hand, appeared a few
> > weeks ago. This doesn't happen every day but often enough to be annoying
> > and disruptive for my family.
> >
>
> Always good to check what has changed those weeks ago, but I understand
> it is difficult to find out what you were updating and where.
>
> > My question is, how can I troubleshoot this problem and figure out
> > whether it is truly due to network bridging somehow collapsing or not? I
> > tried to find some log files but all I could find were the
> > /var/log/libvirt/qemu/$VM files, and the particular log file for the
> > pi-hole
> > VM reported the following lines; however, I am not sure if they are
> > associated with a real crash or just due to shutting down and restarting
> > the host (please excuse the word-wrapping):
> >
> > char device redirected to /dev/pts/2 (label charserial0)
> > qxl_send_events: spice-server bug: guest stopped, ignoring
> > 2022-01-20T23:41:17.012445Z qemu-system-x86_64: terminating on
> > signal 15 from pid 1 (/sbin/init)
>
> Probably restarting the host as it got SIGTERM'd by init. Maybe it was
> restarted in a bad time and there is some inconsistency on the disk?
> Using something like libvirt-guests which can manage your machines when
> rebooting would be a good idea.
>
> > 2022-01-20 23:41:17.716+0000: shutting down, reason=crashed
> > 2022-01-20 23:42:46.059+0000: starting up libvirt version: 7.10.0, qemu
> > version: 6.2.0, kernel: 5.10.89-1-MANJARO, hostname: -redacted-
> >
> > Please excuse my ignorance but is there a way to restart the
> > networking without rebooting the host machine? This will not solve my
>
> You can do:
>
> virsh net-destroy <network_name>
> virsh net-start <network_name>
>
> but depending on what the network looks like, how it is set up etc. you
> might need to restart some of the VMs or manually plug them in.
The connection between any guest tap device and a host bridge device will be
broken by virsh net-destroy, and not restored by virsh net-start (because
the network driver has no good way of notifying the QEMU driver that it has
restarted a network). This is something that's been on my "list of annoying
things I should fix some day" for a very long time, but I've never been
motivated enough to figure out a clean solution.
In the meantime, if you destroy/start a network, you can get all the guest
tap devices reconnected by restarting libvirtd:
systemctl restart libvirtd.service
or if you're using split daemons:
systemctl restart virtqemud.service
One of the things the QEMU driver does when it's initializing is to check
where each guest tap device *should* be connected, compare that to where it
*is* connected, and if those don't match then fix it.