遇到3个nfs挂载的问题Connection timed out、no route to host、Protocol not supported(qemu虚拟机通过nfs共享主机侧的文件夹)

本文探讨了主机NFSServer与QEMU虚拟机Client之间的NFS问题,涉及网络连接问题、防火墙设置、协议版本不匹配等。通过ping测试、iptables调整和配置文件检查,作者逐步解决了noroutetohost和Protocolnotsupported错误。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前提:主机侧为nfs server端,启动的qemu虚拟机为client客户端。打算将主机侧的指定文件夹与虚拟机侧共享,遇到的nfs问题。

1. nfs:no route to host 或者 Connection timed out(我遇到的都是网络不通)

一、问题描述

在挂载server服务端下的文件夹时,出现如下错误:

mount -t nfs -o nolock,vers=4 192.168.1.1:/home/data  /data
mount.nfs::no route to host

二、问题分析

NFS(Network File System,网络文件系统),能使使用者访问网络上别处的文件,就像是在使用自己服务器下的文件一样。NFS 的默认传输协议是 UDP
我遇到上述问题可能存在的原因:

  1. 网络不通
  2. NFS服务没有配置好。

三、解决方案

关于配置的问题,先查一下
[root@host-26 zhyn]# showmount -e localhost
Export list for localhost:
/home/svp_docker_ci 10.89.235.0/24,10.234.72.0/24,192.168.1.0/24

1.确认虚拟机网络与主机侧server端是否是通的

在虚拟机内部ping server主机侧的虚拟网桥ip:
bash-4.4# ping 192.168.1.1  
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=0.401 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=0.187 ms
同时在server主机侧对虚拟网桥进行抓包:
[root@host-26 zhyn]# tcpdump -i qemu-br0 
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on qemu-br0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:05:41.305274 IP 192.168.1.105 > nfs-server: ICMP echo request, id 29697, seq 19, length 64
10:05:41.305300 IP nfs-server > 192.168.1.105: ICMP echo reply, id 29697, seq 19, length 64

然后在server主机侧ping 虚拟机内部ip
[root@host-26 zhyn]# ping 192.168.1.105
PING 192.168.1.105 (192.168.1.105) 56(84) bytes of data.
64 bytes from 192.168.1.105: icmp_seq=1 ttl=64 time=0.273 ms
64 bytes from 192.168.1.105: icmp_seq=2 ttl=64 time=8.04 ms
同时在虚拟机内部对虚拟网卡 进行抓包:
bash-4.4# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:14:32.608971 IP 192.168.1.1 > 192.168.1.105: ICMP echo request, id 605, seq 27, length 64
02:14:32.609000 IP 192.168.1.105 > 192.168.1.1: ICMP echo reply, id 605, seq 27, length 64

如上述过程中可能存在任意一方不通,或者双方相互可以ping通,但是nfs挂载不上——大概率是防火墙的问题。我遇到的是在虚拟机内部ping主机侧是可以ping通的,但是在主机侧ping虚拟机内部,遇到类似这样的报错:

[root@host-26 zhyn]# ping 192.168.1.105
ping:sendmsg 不允许的操作
ping:sendmsg 不允许的操作

ping自己的虚拟网桥ip
[root@host-26 ~]# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

同时在虚拟机内部抓包的情况是
bash-4.4# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:14:32.608971 IP 192.168.1.1 > 192.168.1.105: ICMP echo request, id 605, seq 27, length 0
02:14:32.609000 IP 192.168.1.105 > 192.168.1.1: ICMP echo reply, id 605, seq 27, length 0

上述情况主机侧的防火墙的问题:

1. 关闭防火墙和selinux
[root@host-26 ~]# systenctl stop firewalld
[root@host-26 ~]# setenforce 0
执行上述操作后,我的问题依然没有解决,主机侧任然无法ping通虚拟机

2.相关关于iptables的操作
iptables默认策略(Filter内建表)为拒绝所有:
iptables -P INPUT DROP
iptables -P OUTPUT DROP
查找相关资料的操作:
[root@host-26 ~]# systemctl stop iptables.service
[root@host-26 ~]# iptables  -A INPUT -p icmp --icmp 8 -j ACCEPT  #允许请求进来
[root@host-26 ~]# iptables -A OUTPUT  -p icmp --icmp 0 -j ACCEPT  #允许响应出去
经过上述操作以后,双方的的网络可以下相互ping通,但是nfs还是无法挂载

3.接着查找OpenStack相关帖子执行的操作:
修改iptables默认策略(Filter内建表,有三条内建链)为接收所有:
[root@host-26 ~]# iptables -P OUTPUT ACCEPT
[root@host-26 ~]# iptables -P INPUT ACCEPT
[root@host-26 ~]# iptables -P FORWARD ACCEPT
同时执行添加iptables规则
[root@host-26 ~]# iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
[root@host-26 ~]# iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

讲过上述操作,我的问题已经解决。
注意:在执行到server主机侧和虚拟机侧可以相互ping通的情况下,如果继续报no route to host
则不要急着执行第3步OpenStack查找的步骤,先查看server主机侧的/etc/exports文件(为nfs的配置文件,即nfs的配置问题)
[root@host-26 zhyn]# cat /etc/exports
/home/data 192.168.1.0/24(rw,no_root_squash,async) 
#/home/data为主机侧共享的目录,192.168.1.0/24对应可以挂载此目录的ip端,括号内部即为
#相关读写权限。自行查找资料看吧。查看ip段是否配对,以及相关读写权限设置是否正确。

2. nfs.mount:Protocol not supported

一、问题描述

在挂载server服务端下的文件夹时,出现如下错误:

mount -t nfs -o nolock,vers=4 192.168.1.1:/home/data  /data
mount.nfs: Protocol not support

二、问题分析

查找过相关资料,可能是nfs server和nfs client版本不匹配的原因

三、解决方案

在server主机侧执行nfsstat -s
在这里插入图片描述
在client虚拟机侧执行nfsstat -c
在这里插入图片描述
两个nfs版本一致即可。

mount -t nfs -o nolock,vers=4 192.168.1.1:/home/svp_docker_ci /svp_docker_ci
上述操作在client虚拟机内执行,vers对应指定版本,可以为2、3、4

这个配置文件在/etc/nfsmount.conf里面,找到和协议版本相关的内容:

[ NFSMount_Global_Options ]
# This statically named section defines global mount 
# options that can be applied on all NFS mount.
#
# Protocol Version [2,3,4]
# This defines the default protocol version which will
# be used to start the negotiation with the server.
# Defaultvers=4

相关参考资料

nfs安装
nfs安装
iptables手册
Ping: sendmsg: operation not permitted
nfs client connection timeout

<think>好的,用户遇到了dracut-initqueue超时的问题,需要帮助解决。首先,我得回忆一下dracut的作用。Dracut是用于生成initramfs的工具,在系统启动时负责加载必要的驱动和模块。当出现initqueue超时,通常是因为系统在启动过程中无法找到根文件系统所在的设备,导致等待超时。 接下来,我需要考虑可能的原因。常见的包括存储驱动未正确加载、设备路径变化(比如从/dev/sda变成/dev/sdb)、UUID或标签错误、磁盘阵列或LVM配置问题,以及硬件连接问题。此外,用户可能在虚拟机环境中遇到了网络存储配置问题,比如iSCSI或NFS挂载问题,这也会导致initqueue等待超时。 然后,思考解决方案。首先应该检查启动参数,确认root=参数是否正确,包括UUID或设备路径。如果使用UUID,需要确保与blkid显示的一致。如果设备路径变化,可能需要修改为正确的设备名。 接下来,考虑重新生成initramfs。有时候,更新系统或内核后,initramfs没有正确更新,导致缺少必要的驱动。用户需要进入救援模式,使用dracut命令重新生成,并加上--force参数覆盖旧文件。 添加驱动模块也是一个可能的解决方法。如果存储控制器驱动没有包含在initramfs中,需要手动添加。例如,对于某些硬件RAID卡,可能需要添加megaraid_sas模块。使用dracut --add-drivers模块名来更新。 检查文件系统是否正确,使用fsck进行修复。如果文件系统损坏,可能会导致无法挂载,进而超时。此外,检查/etc/fstab中的配置是否正确,避免错误的挂载点导致问题。 对于虚拟机环境,特别是像Proxmox或VMware这样的平台,检查虚拟磁盘的配置是否正确,是否使用了正确的总线类型(如SCSI或VirtIO)。如果是iSCSI或NFS存储,确认网络配置和存储连接正常。 如果以上方法都不奏效,可能需要在内核启动参数中添加rd.break或rd.shell,进入紧急shell手动排查问题,查看设备是否被正确识别,或者是否有必要的模块需要加载。 最后,用户可能需要参考相关的文档或社区资源,比如Red Hat的解决方案或者论坛讨论。例如,有些案例中提到,在Proxmox中创建虚拟网络时选择正确的隔离网络配置,可能影响存储设备的识别,需要检查虚拟机的设置是否正确[^1]。 总结下来,解决步骤大致是:检查启动参数,重新生成initramfs,添加必要驱动,检查文件系统和硬件连接,虚拟机环境配置确认,以及使用紧急shell调试。需要逐步排除可能的原因,直到找到具体问题所在。</think>针对**dracut initqueue timeout**问题,通常与系统启动时无法正确挂载根文件系统有关。以下是分步解决方案: --- ### 1. **检查根设备参数** - **现象**:系统启动时卡在`dracut-initqueue`提示符,提示`Warning: /dev/disk/by-uuid/... does not exist`。 - **解决方法**: 1. 在启动菜单中按`e`编辑内核参数,确认`root=`后的设备标识(如UUID或设备路径)是否正确。 2. 若使用UUID,检查是否与实际设备匹配: ```bash blkid /dev/sdX # 替换为实际设备名 ``` 3. 若设备路径错误(如从`/dev/sda`变为`/dev/sdb`),修改`root=/dev/sdX`为正确路径。 --- ### 2. **重新生成initramfs** - **适用场景**:内核更新或驱动缺失导致initramfs不包含必要模块。 - **步骤**: 1. 进入救援模式或Live CD环境。 2. 挂载原系统根分区: ```bash mount /dev/sdX /mnt ``` 3. 重新生成initramfs: ```bash dracut --force --verbose /boot/initramfs-$(uname -r).img $(uname -r) ``` --- ### 3. **添加缺失的驱动模块** - **适用场景**:存储控制器驱动(如RAID卡、NVMe驱动)未加载。 - **操作**: 1. 检查当前系统加载的驱动: ```bash lsmod | grep [驱动关键词] ``` 2. 手动添加驱动到initramfs: ```bash dracut --add-drivers "megaraid_sas nvme" --force ``` --- ### 4. **检查文件系统与硬件连接** - **硬件问题**:磁盘未正确连接或文件系统损坏。 - **步骤**: 1. 使用`fsck`修复文件系统: ```bash fsck -y /dev/sdX ``` 2. 检查硬盘连接(物理机)或虚拟机磁盘配置(如Proxmox/VirtualBox)。 --- ### 5. **虚拟机环境专用方案** - **现象**:虚拟机因虚拟磁盘配置错误或网络存储超时导致问题。 - **解决**: 1. 确认虚拟磁盘总线类型(如SCSI或VirtIO)与驱动匹配。 2. 若使用iSCSI/NFS,检查网络连通性及存储服务器状态。 3. 参考Proxmox配置建议:选择`Virtual network "isolated200" : isolated network`确保存储网络隔离[^1]。 --- ### 6. **调试模式定位问题** - **高级排查**: 1. 在内核参数添加`rd.break`或`rd.shell`进入紧急Shell。 2. 手动挂载根分区并检查设备: ```bash dracut:/# ls /dev/sd* dracut:/# journalctl -xb # 查看启动日志 ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值