[7669] in testers
Re: vmware interfaces on linux box
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Sun Dec 23 20:54:25 2007
Cc: testers@mit.edu, Laura E Baldwin <boojum@mit.edu>
Message-Id: <0E34A6A0-7A15-4571-B0B9-261FCE33767F@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Jonathon Weiss <jweiss@mit.edu>
In-Reply-To: <200712231916.lBNJGtvC026504@vorpal-blade.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Sun, 23 Dec 2007 20:53:29 -0500
D'oh, I meant to send mail before I left on Thursday. This was
responsible for Laura's sendmail problems that were being discussed on
Zephyr on Thursday. At that time, I had forgotten that VMware player
was added to the release, so Laura and I removed it and the problems
went away.
I wonder, however, why we're creating all these interfaces? Is it to
support all potential vmware networking modes? Wouldn't it be easier
to simply support bridged networking, and leave it at that? That
would avoid the 192.168/16 issue, and in fact it's probably poor to
support NAT mode anyway (*mumble* Rules of Use *mumble*)
$0.02
-Jon
On Dec 23, 2007, at 2:16 PM, Jonathon Weiss wrote:
>
> Hi,
>
> After updating my linux box to the latest release, I noticed that I
> had a couple of vmware interfaces created:
>
> vorpal-blade:~$ athinfo vorp interfaces
> Kernel Interface table
> Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-
> DRP TX-OVR Flg
> eth0 1500 0 468397 0 52 0 66672
> 0 0 0 BMRU
> lo 16436 0 46516 0 0 0 46516
> 0 0 0 LRU
> vmnet1 1500 0 0 0 0 0 5
> 0 0 0 BMRU
> vmnet8 1500 0 0 0 0 0 5
> 0 0 0 BMRU
>
> I notice this doens't seem to have happened on any of the test cluster
> machines, so it's possible that one of my customizations are at fault,
> but it's possible that it's some differences between PUBLIC true and
> false machines. Has anyone else seen these interfaces appear on their
> linux (or sun, I suppose, though I haven't seen it there) boxes?
>
> I'll note also that the existance of these interfaces interact poorly
> with sendmail, since it tries and fails to reverse-resolve the 192.168
> addresses assigned to them before doing anything, which adds a 40
> second delay.
>
>
> Jonathon
