linux – 配置QEMU(Guest Debian-9.0 Sparc64 – Host MacOS Hig

发布时间：2020-12-14 01:41:15 所属栏目：Linux 来源：网络整理

导读：首先,使用QEMU虚拟机(Debian Sparc64 Etch 4.0),我已经能够成功地从Guest到Host(MacOS Hight Sierra OS 10.13.3)获取ssh和scp命令. 我只想在来宾和主机之间传输文件. 为了得到它,我已经遵循了这个tutorial： 1)我已经安装了TUN / TAP驱动程序 2)像这样启动QE

首先,使用QEMU虚拟机(Debian Sparc64 Etch 4.0),我已经能够成功地从Guest到Host(MacOS Hight Sierra OS 10.13.3)获取ssh和scp命令.

我只想在来宾和主机之间传输文件.

为了得到它,我已经遵循了这个tutorial：

1)我已经安装了TUN / TAP驱动程序

2)像这样启动QEMU：

qemu-system-sparc -boot c -hda debian_etch.img -m 512M -net nic -net tap,script=no,downscript=no

3)VM启动后,在MacOS主机上执行：ifconfig tap0 192.168.10.1

4)在Debian Etch主机上,进入/ etc / network / interfaces：

auto eth0
iface eth0 inet static
address 192.168.10.2
netmask 255.255.255.0
gateway 192.168.10.1

并执行：/etc/init.d/networking restart

5)最后,在guest上制作：$scp -r dir user_host@192.168.10.1：?/

现在,我想用“Debian Sparc64 Stretch 9.0”来访同样的事情.

似乎不赞成使用最新版本的Debian ifconfig.

无论如何,我尝试使用以下命令启动Sparc64映像：

qemu-system-sparc64 
-drive file=debian-9.0-sparc64.qcow2,if=none,id=drive-ide0-0-1,format=qcow2,cache=none 
-m 1024 
-boot c 
-net nic 
-net tap,ifname=tap0,downscript=no 
-nographic

并再次执行步骤1),3),4)但不幸的是,客人的ssh和scp不起作用.

我必须注意到,使用这个Debian Sparc64 9.0来宾,网络逻辑名称正在发生变化(可能是每次启动).例如,/ etc / network / interfaces包含：

auto enp0s5
allow-hotplug enp0s5
iface enp0s5 inet static
address 192.168.10.2
netmask 255.255.255.0
gateway 192.168.10.1

最后,我从客人那里得到以下结果：

# ssh user_host@192.168.10.1
  ssh: connect to host 192.168.10.1 port 22: No route to host

ip a给出：

# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s5: <BROADCAST,MULTICAST,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.2/24 brd 192.168.10.255 scope global enp0s5
       valid_lft forever preferred_lft forever
    inet6 fec0::5054:ff:fe12:3456/64 scope site mngtmpaddr dynamic 
       valid_lft 86207sec preferred_lft 14207sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

如果有人可以给我一些线索来修复它并让ssh / scp命令从guest到host工作(我没有网络访客和没有sshd服务器,所以我只想要方向guest – > host for ssh / scp ).

更新1：

我继续调试这个问题.

1)首先,从this link开始,我在每次启动时将访客“Debian 9.0 Sparc64”的网络接口重命名为eth0：

vi /etc/udev/rules.d/10-network.rules

   SUBSYSTEM=="net",ACTION=="add",ATTR{address}=="52:54:00:12:34:56",NAME="eth0"

MAC地址给出：

$ip a
1: lo: <LOOPBACK,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.2/24 brd 192.168.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

2)我在主机MacOS High Sierra的TAP接口上使用了tcpdump：

# tcpdump -vv -i tap0
tcpdump: listening on tap0,link-type EN10MB (Ethernet),capture size 262144 bytes
00:23:06.112155 ARP,Ethernet (len 6),IPv4 (len 4),Request who-has 192.168.10.1 tell 192.168.10.2,length 46
00:23:06.112228 ARP,Reply 192.168.10.1 is-at fe:22:e7:8c:7f:fa (oui Unknown),length 28
00:23:07.128440 ARP,length 46
00:23:07.128499 ARP,length 28
00:23:08.152323 ARP,length 46
00:23:08.152381 ARP,length 28
00:23:11.119346 ARP,length 46
00:23:11.119396 ARP,length 28
00:23:12.120190 ARP,length 46
00:23:12.120250 ARP,length 28
00:23:13.145028 ARP,length 46
00:23:13.145075 ARP,length 28
00:23:16.127525 ARP,length 46
00:23:16.127575 ARP,length 28
00:23:17.145202 ARP,length 46
00:23:17.145272 ARP,length 28

我应该得出结论,guest(guest / etc / network / interfaces上的192.168.10.2)和主机(由ifconfig tap0 192.168.10.1设置的192.168.10.1)正在通信,因为我看到上面的tcpdump这两个地址？

如果我在guest上重新启动networkin时在主机上执行tcpdump -vv -i tap0,我会得到：

00:27:07.648620 IP6 (hlim 1,next-header Options (0) payload length: 36) :: > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6,multicast listener report v2,1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:07.804644 IP6 (hlim 1,1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:08.569140 IP6 (hlim 255,next-header ICMPv6 (58) payload length: 32) :: > ff02::1:ff12:3456: [icmp6 sum ok] ICMP6,neighbor solicitation,length 32,who has fe80::5054:ff:fe12:3456
      unknown option (14),length 8 (1): 
        0x0000:  3bd4 4c86 3dd6
00:27:08.612632 IP (tos 0x0,ttl 255,id 37381,offset 0,flags [none],proto UDP (17),length 118)
    192.168.10.1.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QU)? 6.5.4.3.2.1.e.f.f.f.0.0.4.5.0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
00:27:09.592322 IP6 (hlim 1,next-header Options (0) payload length: 36) fe80::5054:ff:fe12:3456 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6,1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]
00:27:09.592483 IP6 (hlim 255,next-header ICMPv6 (58) payload length: 16) fe80::5054:ff:fe12:3456 > ip6-allrouters: [icmp6 sum ok] ICMP6,router solicitation,length 16
      source link-address option (1),length 8 (1): 52:54:00:12:34:56
        0x0000:  5254 0012 3456
00:27:09.616466 IP (tos 0x0,id 18614,length 118)
    192.168.10.1.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QM)? 6.5.4.3.2.1.e.f.f.f.0.0.4.5.0.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
00:27:09.976787 IP6 (hlim 1,1 group record(s) [gaddr ff02::1:ff12:3456 to_ex { }]

这些消息中是否有有用的信息,以便从客户端到主机获取ssh / scp？

最后,对于guest eth0具有以下状态(UNKNOWN)是正常的：

eth0: <BROADCAST,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN

更新2：我也尝试使用带有“-net tap”标志的guestfwd标志启动,如下所示：

qemu-system-sparc64 
-boot c 
-hda debian-9.0-sparc64.qcow2 
-net nic 
-net tap,downscript=no 
-net 'user,guestfwd=tcp::22-tcp::22' 
-m 1024 
-nographic

但仍然没有从客户到主机的ssh访问.

我不知道是否,进入-net’user,guestfwd = tcp :: 22-tcp :: 22′,在哪个顺序我必须把guest和主机的IP以及每个端口用于它们(I这里使用了22个)

如果有人能给我一些关于“guestfwd”旗帜的精确度.

更新3：

最后,通过在MacOS主机(以root身份)上执行来解决此问题：

1)使用“ifconfig bridge0 192.168.10.1”在bridge0上设置IP 190.168.10.1

2)使用以下命令启动Qemu：

qemu-system-sparc64 
-boot c 
-hda debian-9.0-sparc64.qcow2 
-device virtio-balloon 
-net nic,model=virtio,macaddr=52:54:00:12:34:56 
-vga none 
-net tap,downscript=no 
-m 1024 
-nographic

MAC Adress 52：54：00：12：34：56很重要.

3)启动Qemu后,将tap0接口添加到bridge0：ifconfig bridge0 addm tap0

4)最后,从访客Debian Sparc64,我可以用(作为简单的用户或root)连接到MacOS主机：

ssh user_host@192.168.10.1

解决方法

一些评论：

是的,ifconfig已被弃用,但据我所知,至少已有六年左右的时间,而且它仍然在这里……这有其原因.我认为你可以毫无良心地使用它.

关于你的tcpdump摘录：你觉得它包含有用的信息是正确的.但它并未显示来宾和主机之间的真实通信,但它显示了ARP查询. ARP是地址解析协议,因以下原因需要：

基本上,只要TCP / IP堆叠在以太网之上,计算机(无论它们是否是虚拟的)都需要知道其通信伙伴的以太网硬件地址(MAC(媒体访问控制)地址).

因此,如果具有IP地址a.a.a.a的计算机A想要与具有IP地址b.b.b.b的计算机B通信,则A需要首先知道B的MAC地址.因此,A将以太网广播帧发送到本地以太网段(基本上,广播帧是连接到相应段的所有机器的帧),询问：“我需要与具有IP地址bbbb的人交谈.你们中的任何人都有这个IP地址,你的以太网MAC地址是什么？“

您的tcpdump摘录显示此ARP解析失败.你的客人一遍又一遍地问,没有得到答案.只要是这种情况,guest虚拟机就无法与主机进行任何TCP / IP通信.

所以你的问题只与SCP / SSH无关,而是与IP协议有关.例如,访客将无法显示位于主机上的网站.

此外,由于主持人不想发送答案,任何其他客人都会遇到同样的问题.我强烈认为你的旧debian蚀刻会以同样的方式失败,如果你以完全相同的方式启动它的VM并且在完全相同的主机上具有与具有新debian拉伸的VM完全相同的配置.

当然,来自guest虚拟机的ARP请求首先会到达guest虚拟机VM的TAP所连接的网桥.只要该网桥没有为访客请求分配的IP地址,就不会回答访客的ARP请求.这个问题通常通过以下方式解决：

在主机上,从物理网络接口取出IP地址并将其分配给网桥.然后桥接器回答客户的ARP查询.但这还没有让你到任何地方,因为现在你不能再使用主机的物理网络接口(你已经拿走了它的IP地址).

因此,您还将主机的物理网络接口连接到网桥.通常,这是静态配置,即在启动VM时不会动态完成.这意味着主机上的操作系统配置为创建网桥,并在启动时将其物理网络接口添加到网桥.相比之下,客人的TAP会在客人启动时动态添加到桥上,并在客人关闭时从桥上移除.

动态添加和删除guest虚拟机的TAP到主机的桥接器通常由您提供给-tap …配置选项的upscript和downscript参数完成.显然,您是手动执行此操作(更新3的第3项).

总而言之,您的问题是主机没有回答来宾的ARP查询.发生这种情况是因为这些查询到达了VM的TAP附加到的桥接器,但是您没有为该桥接器分配IP地址(更准确地说,至少不是访客的ARP查询所要求的IP地址).

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!