qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] QEMU with pre-created TAP in user mode


From: Mike Lovell
Subject: Re: [Qemu-discuss] QEMU with pre-created TAP in user mode
Date: Mon, 23 Jul 2012 15:13:11 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 07/23/2012 02:47 PM, anatoly techtonik wrote:
On Mon, Jul 23, 2012 at 10:50 PM, Mike Lovell <address@hidden> wrote:
On 07/20/2012 03:23 PM, anatoly techtonik wrote:
Thanks. Now QEMU starts ok, but I still unable to connect to guest
using SSH after giving both guest eth1 and host tap0 IPs from the same
network. Pings work ok both sides. SSH to other virtual machines on
the same host (under libvirt) works ok. The error:

$ ssh -vvv address@hidden
OpenSSH_5.9p1, OpenSSL 1.0.0j-fips 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 50: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.16.15 [192.168.16.15] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/user/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
ssh_exchange_identification: read: Connection reset by peer

/var/logs/auth.log on guest shows this:
... sshd[1446]: Did not receive identification string from 192.168.16.1

For other machines output is different:
...
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.5p1 Debian-6+squeeze2
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
...

it sound like you are using multiple guests. are you specifying the macaddr=
option on the guest network devices for each one? if you don't specify it,
each qemu process will use the same mac address for each guest,
52:54:00:12:34:56. using multiple guests with the same mac address can lead
to very weird behaviors. "-net nic,macaddr=52:54:00:aa:bb:cc" will tell the
guest to use 52:54:00:aa:bb:cc instead of the default.
Not the cause. I have several virtual machines in virt-manager (`other
machines` referenced above), but this time I ensured they are all shut
them down. Only one qemu process is running.

$ ps aux | grep qemu
user  21221  6.4  1.4 251424 120936 pts/0   Sl+  23:29   0:15 qemu-kvm
-hda linux.img -net user -net nic -net nic -net
tap,ifname=tap0,script=no
user  21320  0.0  0.0   4744   796 pts/1    S+   23:33   0:00 grep
--color=auto qemu

Host (Fedora 17) interface:
tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
         inet 192.168.16.1  netmask 255.255.255.0  broadcast 192.168.16.255
         ether 22:04:19:e7:bb:0e  txqueuelen 500  (Ethernet)

Guest (Debian Squeeze):
eth2: HWaddr 52:54:00:12:34:57
eth3: HWaddr 52:54:00:12:34:56  inet addr:192.168.16.15/24

$ ssh address@hidden
ssh_exchange_identification: read: Connection reset by peer


I've tried `-net nic,macaddr=52:54:00:aa:bb:cc` and qemu-kvm
segfaulted when I tried to assign IP address with:
$ ifconfig eth4 192.168.16.15/24

`qemu-kvm -hda linux.img -net user -net nic -net nic -net tap,ifname=tap0,script=no` is the command you are running? this creates a little bit of a weird situation as well. using the -net option to create network backends (socket, tap, vde, etc) also creates a kind of hub that multiple network backends and guest devices can be connected to. the command listed will result in the two guest network devices, the user mode network, and the tap device all being connected. packets sent from one device will be delivered to all of the rest. i wouldn't be surprised if the user mode backend is messing with things.

you can separate out the guest devices and backends by using what the documentation calls 'vlans.' these are not ethernet 802.1q vlans like most people think. they are the hub like devices connecting network components inside the qemu process. try modifying your command to have '-net user,vlan=0 -net nic,vlan=0 -net nic,vlan=1 -net tap,ifname=tap0,script=no,vlan=1' which just adds the vlan options. you might need to figure out which guest device is in vlan1 with the tap backend. 'info network' on the qemu monitor will tell you. it will probably be the device ending with 57 in the mac address since it would be the second guest network device with the tap.

mike




reply via email to

[Prev in Thread] Current Thread [Next in Thread]