Randomly can't connect to guest vm in libvirt - qemu

I cannot reliably trigger this, although if I spin up many vms at a time and then attempt to connect to some of them, I run into this condition:
$ ping 192.168.122.135
PING 192.168.122.135 (192.168.122.135) 56(84) bytes of data.
From 192.168.122.1 icmp_seq=1 Destination Host Unreachable
From 192.168.122.1 icmp_seq=2 Destination Host Unreachable
From 192.168.122.1 icmp_seq=3 Destination Host Unreachable
Note that this does not happen for all VMs that I create and start, only a handful of them (randomly).
The vm that has obtained the ip 192.168.122.135 has the following for its network in its domain xml:
<interface type='network'>
<mac address='52:54:00:3d:72:ab'/>
<source network='default'/>
<target dev='vnet0'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</interface>
And the default network is defined as (and yes, 22 vms are currently running):
<network connections='22'>
<name>default</name>
<uuid>69674b8b-f067-4513-b594-3e52360f391b</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr0' stp='on' delay='0'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>
The output from ifconfig for vnet0 (referenced by the VM's network domain xml) and virbr0 (used by the default network as shown above):
$ sudo ifconfig vnet0
vnet0 Link encap:Ethernet HWaddr fe:54:00:3d:72:ab
inet6 addr: fe80::fc54:ff:fe3d:72ab/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:425 errors:0 dropped:0 overruns:0 frame:0
TX packets:1304 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:57503 (57.5 KB) TX bytes:67257 (67.2 KB)
and
$ sudo ifconfig virbr0
virbr0 Link encap:Ethernet HWaddr fe:54:00:08:e9:a4
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:882508 errors:0 dropped:0 overruns:0 frame:0
TX packets:2527165 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:93980992 (93.9 MB) TX bytes:3047773583 (3.0 GB)
Below is the partial output from ip route list:
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
The route output above makes me think that it should be working. BUT ITS NOT. and it only fails sometimes, and works most of the time.
Why can't I connect to the guest (192.168.122.135) from the host??
I was originally using filters, but removing the filters from the VM's domain xml has no effect on this condition randomly showing up. If I spin up many VMs at the same time I can get it to happen to a lot of them. Some of the VMs work just fine though and allow me to connect.
Also, I am using ubuntu 14.04.3:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
With kernel 3.19.0-30-generic.
More info - virsh version:
$ virsh --version
1.2.2
libvirtd version:
$ libvirtd --version
libvirtd (libvirt) 1.2.2

I don't have enough reputation to comment... But I have a few suggestions on things you could try to further explore the problem.
Question: Does assigning an IP address in the 192.168.122.X subnet on vnet0 do anything? The route that is configured seems to suggest that your traffic will go to virbr0 since it has the 192.168.122.1 IP address. If you can't ping any other devices in that subnet, then I suspect that's the issue.
If that doesn't get you anywhere...
Packet trace on host / VM
Try doing a packet dump on virbr0 and on the internal VM interface when this occurs. Ping the VM, and see what kind of traffic you see.
sudo tcpdump -n -i virbr0 -v "icmp or arp"
Depending on what you see there, will help narrow down the source of the problem. If you're not even getting your pings on that interface, then it's a routing issue on the host. If pings are going in, but the VM isn't seeing them, then it's a network/routing issue with the libvirt network.
I recommend also doing the above with a working VM, so you have a reference to compare the traffic against.
Check ARP Cache
Check your ARP cache on the host when this occurs. Does the mac address exist in the cache? Maybe it's getting mangled...
To dump the arp cache:
# arp
Check your libvirt logs
If configured, libvirt will log to syslog using the 'libvirtd' tag. Check your configuration to be sure this is enabled. It seems unlikely it's a libvirt issue, but it wouldn't hurt to turn on the logging.
To enable this setting
# vi /etc/libvirt/libvirtd.conf
Add the line
log_outputs_"1:syslog:libvirtd"
Restart libvirt
# service libvirt-bin restart

I had similar issue. I just tried following command to check whether machine is installed properly or not.
lsmod | grep kvm
If it is showing kvm details then machine is installed properly.
After that to restart the services
service libvirtd restart
Also check gateway using the below command
netstat -rn

I have the same network setting, and similar problem in a CentOS 7 host. Eventually, it turned out that the problem was guest VM's firewall setting blocked echo request and other external connection. After changing the firewall setting, the problem is solved.

My case, I've a hardware server where Libvirt is installed.
On this server I create VM in where install libvirt and after that I've get random network interruption and ping response with 192.168.122.1:
From 192.168.122.1 icmp_seq=1 Destination Host Unreachable
I've fixed this be deleting default libvirt network on hardware server like this:
virsh net-destroy default
virsh net-undefine default

Related

Ubuntu 20.04 NetworkManager ignoring eth0 configuration? Netplan configuration abandoned?

Until sometime last night, my UBUNTU 20.04 system was working fine with this configuration file at /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
ethernets:
eth0:
dhcp4: no
addresses:
- 192.168.1.6/24
gateway4: 192.168.1.254
nameservers:
addresses: [192.168.1.2]
This has been working great for a couple of years, but sometime during the evening, connection to 192.168.1.6 was lost from other servers (I know because I had ssh connections that were dropped during the night).
Upon investigation I found that the (normally headless) server had a new IP address (.92 rather than .6), and apparently this configuration file is no longer applicable.
I found that network-manager is in the /etc/init.d/ directory which seems to mean that, for whatever reason, the system is now ignoring that previous configuration. It's a mystery to me why this would suddenly change.
Anyway, I found how to configure NetworkManager for the result I want, and came up with this, which I placed into (new file) /etc/NetworkManager/conf.d/ethernet.conf:
[802-3-ethernet]
auto-negotiate=true
mac-address=b4:2e:99:a2:58:77
[connection]
id=Wired connection 1
uuid=06563f32-7cd9-3ee1-ac71-e5bb775a4840
type=802-3-ethernet
timestamp=0
[ipv6]
method=ignore
[ipv4]
method=manual
dns=192.168.1.2
address1=192.168.1.6/24,192.168.1.254
(I got the uuid value from 'nmcli conn show' and I got the mac addr from 'ip a show eth0')
dennis#velmicro:/etc/NetworkManager 01/10 10:01:12
> nmcli conn show
NAME UUID TYPE DEVICE
Wired connection 1 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ethernet eth0
ls2021.lovelady.com a4fa8d23-a06d-4955-bfd9-5d7de76584c2 wifi wlan0
dennis#velmicro:/etc/NetworkManager 01/10 10:01:30
> ip a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether b4:2e:99:a2:58:77 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.92/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 84428sec preferred_lft 84428sec
Here's what /etc/NetworkManager/NetworkManager.conf looks like:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no
[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan,except:type:ethernet
Restarting NetworkManager, and even a complete reboot seems to produce no errors and yet the configuration is apparently ignored: the 192.168.1.92 address persists.
What am I missing to make this system static IP to the address I need?
Bonus points: How would I determine what caused the sudden (apparent) switch to NetworkManager from netplan?
The following commands, entered at the command line as user root, solved this problem:
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv4.address 192.168.1.6/24
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv4.gateway 192.168.1.254
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv4.dns "192.168.1.2"
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv4.method manual
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv4.dns-search "lovelady.com"
nmcli con modify 06563f32-7cd9-3ee1-ac71-e5bb775a4840 ipv6.method disabled
nmcli connection up 06563f32-7cd9-3ee1-ac71-e5bb775a4840
After executing those commands, the following configuration could be found in /etc/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection (it was created for me)
[connection]
id=Wired connection 1
uuid=06563f32-7cd9-3ee1-ac71-e5bb775a4840
type=ethernet
autoconnect-priority=-999
interface-name=eth0
permissions=
timestamp=1673626973
[ethernet]
mac-address-blacklist=
[ipv4]
address1=192.168.1.6/24,192.168.1.254
dns=192.168.1.2;
dns-search=lovelady.com;
method=manual
[ipv6]
method=disabled
[proxy]
The placement of a device configuration into the /etc/NetworkManager/conf.d structure was a mistake. No device configurations should be placed into that directory.
Command journalctl -u NetworkManager.service (executable by any user) ultimately helped reveal what was going on, and why the configuration file I created did not have the desired effect.
All device configurations should go under /etc/NetworkManager/system-connections/ and ideally should be created via a sequence of nmcli commands as above.
This device is now (again) configured as I like. Note that the former configuration file (/etc/netplan/01-network-manager-all.yaml) is no longer used by the system, for an unknown reason. ls -lu /etc/netplan/01* reveals that it has not been read in several days, despite a series of reboots.

issue in Downloading Platform-specific Binaries

I want to download Binary files for running Hyperledger Fabric. I am trying to execute this command. I am behind proxy too.
Also I have docker Installed, OS being used Win 10.
export HTTP_PROXY=http://172.16.30.30:80/
export HTTPS_PROXY=https://172.16.30.30:8080/
export NO_PROXY=localhost,127.0.0.1,::1
$ curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s 1.1.0 1.1.0 0.4.6
Installing hyperledger/fabric-samples repo
===> Checking out v1.1.0 of hyperledger/fabric-samples
HEAD is now at 1252c7a... [FAB-8920] Pin fabric-samples to node.js "~1.1.0"
Installing Hyperledger Fabric binaries
===> Downloading version x86_64-1.1.0 platform specific fabric binaries
===> Downloading: https://nexus.hyperledger.org/content/repositories/releases/org/hyperledger/fabric/hyperledger-fabric/windows-amd64-1.1.0/hyperledger-fabric-windows-amd64-1.1.0.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 28.0M 100 28.0M 0 0 91407 0 0:05:21 0:05:21 --:--:-- 145k
... Here 2 files are downloaded and Then i get this erros continiously
Warning: failed to get default registry endpoint from daemon (error during connect: Get https://127.0.0.1:2376/v1.37/info: dial tcp 127.0.0.1:2376: connectex: No connection could be made because the target machine actively refused it.). Using system default: https://index.docker.io/v1/
error during connect: Post https://127.0.0.1:2376/v1.37/images/create?fromImage=hyperledger%2Ffabric-peer&tag=x86_64-1.1.0: dial tcp 127.0.0.1:2376: connectex: No connection could be made because the target machine actively refused it.
error during connect: Post https://127.0.0.1:2376/v1.37/images/hyperledger/fabric-peer:x86_64-1.1.0/tag?repo=hyperledger%2Ffabric-peer&tag=latest: dial tcp 127.0.0.1:2376: connectex: No connection could be made because the target machine actively refused it.
==> FABRIC IMAGE: orderer
===> List out hyperledger docker images
error during connect: Get https://127.0.0.1:2376/v1.37/images/json: dial tcp 127.0.0.1:2376: connectex: No connection could be made because the target machine actively refused it.

writing data to linux tun interface

i have created a linux tun interface, set ipaddr, broadcast etc.. using open/ioctl apis.
This is how the tun interface looks like,
TEST_TUN: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 45.45.45.1/24 scope global TEST_TUN
valid_lft forever preferred_lft forever
Any message written by a virtual host(binded on addr 45.45.45.1:udp=7070) is received by tun_fd(fd returned during tun device creation).
If tun_fd writes an msg ( IP(dst=45.45.45.1)+transport(udp_dst=7070)+payload) is not received on the virtual host. wireshark capture shows that the packet is being received on the kernel side, but virtual host doesnot received any packet.
what could be the reasons for kernel not forwarding the packet to virtual host ?
Had turned your tun device in up state?
if not then you can simply do that via..
$sudo ifconfig tun0 up
and you also can do that via ioctle commands..
if your device is already in a up state then you linux destro must have forwarding on..
you can do this via..
#echo "1" > /proc/sys/net/ipv4/ip_forwarding
or
$sudo sysctl net.ipv4.ip_forward=1
$sudo sysctl -p
then it comes to routing rules..you must have to set routing rule so that all the traffic is captured via your virtual interface..
$sudo ip route 128/1 dev tun
this command will add a route in you kernel routing table and all the traffic will flow through your virtual interface..
If I understood you correctly then may be this will be helpful for you..

Bash VPN accepting HTML conditions

I am trying to configure my Linux server to connect via a VPN using the following command:
sudo pppd pty "pptp UKIPVPN.com --nolaunchpppd" file /etc/ppp/options.pptp user ukipvpn.com password freevpn
Using ifconfig I can confirm the pppd connection is established:
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.162.0.74 P-t-P:10.162.0.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1496 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:60 (60.0 B) TX bytes:66 (66.0 B)
I have added the ppp0 to the route using:
$ sudo route add default ppp0
The issue I have is that the VPN normally serves a HTML 'I accept' page before allowing a connection to the internet.
The page is served every time I try and connect to any pages from the CLI:
curl ipecho.net/plain
<html>
<head><title>UFreeVPN.COM Service from UK</title></head>
<br>
<br>
<font color=blue><center> <h1>UFreeVPN.COM Service from UK</h1> </center></font>
<center><h2><a href='http://uk.ufreevpn.com'>I Agree</a> to use the Free VPN Service</h2></center>
<center><font size='2'>No illegal activities allowed. In case of abuse, users' VPN access log is subjected to expose to related authorities.</font></center>
Is there a way I can 'Agree' from Bash to allow this connection to work?
EDIT:
Having checked the source of the "I agree" page it is just as returned by curl above with no Javascript etc.
On clicking I agree you get auto redirected to http://www.ukipvpn.com.
I tried the following:
curl http://www.ukipvpn.com
and curl http://www.ukipvpn.com -e--referer
but each time i try and grab a page with curl then I am presented with the "I agree" page from the vpn.
So after reading around slightly more on curl the key is to use the POST data function:
curl --data "button=%20I%20AGREE%20&sessionid=<SESSION ID HERE>" http://www.ukipvpn.com
Now the VPN accepts requests and is working. Thanks for the help.
http://curl.haxx.se/docs/httpscripting.html

Debian 7.4 - Wifi configuration fails ... Again [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I've been installing multiple versions of ubunutu over years and now I better understand why I faced always problems with wifi configuration on these different baselines : Debian root of course.
 Issue
Now on Debian 7.4 :
The Broadcom BCM4313 driver is not loaded by default (not free product) for my wifi card. This is stated thru the UNCLAIMED declaration when looking at the network hardware status excerpt :
sudo lshw -c network
*-network UNCLAIMED
description: Network controller
product: BCM4313 802.11b/g/n Wireless LAN Controller
vendor: Broadcom Corporation
physical id: 0
bus info: pci#0000:03:00.0
version: 01
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress cap_list
configuration: latency=0
resources: memory:f1100000-f1103fff
Unclaimed means : no driver found (no kernel association)
So I installed the driver located in the non-free backports by adding this target into the local packages repository /etc/apt/sources.list
deb http://http.debian.net/debian/ wheezy main contrib non-free
and install :
sudo apt-get update && sudo apt-get install firmware-brcm80211
sudo modprobe brcm80211
and restart
sudo shutdown now -r
Check seems OK :
sudo lshw -c network
*-network
description: Wireless interface
product: BCM4313 802.11b/g/n Wireless LAN Controller
vendor: Broadcom Corporation
physical id: 0
bus info: pci#0000:03:00.0
logical name: wlan0
version: 01
serial: 78:e4:00:4e:49:a3
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=brcmsmac driverversion=3.2.0-4-amd64 firmware=N/A latency=0 link=no multicast=yes wireless=IEEE 802.11bgn
resources: irq:19 memory:f1100000-f1103fff
 Network Configuration
minimal /etc/network/interfaces as required by NetworManager
auto lo
iface lo inet loopback
.. and restart
Failure
No wifi network is detected and of course I can't connect using wlan0
it doesn't work.
I found informations here regarding WPA2/PSK wifi configuration on debian :
http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_wireless_lan_interface_with_wpa_wpa2
so I added this setup to my interfaces file an got :
auto lo
iface lo inet loopback
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid Hznteam-Datacenter
# hexadecimal psk is encoded from a plaintext passphrase
wpa-psk 12345678901234567890123456
Same as above no wifi network detected and ifconfig gives no allocated ip address :
wlan0 Link encap:Ethernet HWaddr 78:e4:00:4e:49:a3
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0:avahi Link encap:Ethernet HWaddr 78:e4:00:4e:49:a3
inet addr:169.254.7.34 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
Note that my required WPA2/PSK AES key length is 26 chars as requested on my other PC that connect successfully to my wifi router
Any idea ? it's boring wasting hours on the same problem again ..
Help welcome ...
Wrong wifi kernel module selected
I should have installed the brcmsmac module instead of the brcm80211 one. The latter is the Squeeze version kernel module. Wheezy needs the brcmsmac module as mentioned here
Althouhg the package is named brcm80211 the kernel module to load for Wheezy is brcmsmac instead of brcm80211 for the Squeeze version
more detail in this StackoverFlow post and a summary is also available here
Interfaces
I also set the /etc/network/interfaces conf file to only
$ sudo nano /etc/network/interfaces
auto lo
iface lo inet loopback
this seems to allow Network-Manager to take any discovered interfaces in account.
Everything's OK. Wifi up and running now.
.. And so much wasted time for a stupid version error !