Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Routing from host to vmware (server) guests

  1. #1
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    22,724

    Default Routing from host to vmware (server) guests

    Hi,

    I just installed (n this 11.2 system) vmware server (v 2.02), to have
    access to a few small systems. One of them is a 11.1 guest which I just
    upgraded to 11.3, successfully (almost).

    I have a problem, though: from the host I can not ping/ssh the guest.
    Guest to host works fine (including names).

    Code:
    --------------------
    Telcontar:~ # ping eleanor
    PING eleanor (172.16.108.129) 56(84) bytes of data.

    (nothing)

    Telcontar:~ # traceroute eleanor
    traceroute to eleanor (172.16.108.129), 30 hops max, 40 byte packets
    using UDP
    1 * * *
    2 * * *
    3 * * *
    4 * * *
    ....
    30 * * *

    --------------------

    The firewall is down on both sides. I don't see anything with iptraf in
    the guest. The IP addres of the guest is correct, unless I'm too tired
    to see.

    Why?


    Code:
    --------------------
    Telcontar:~ # route
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use
    Iface
    192.168.18.0 * 255.255.255.0 U 0 0 0
    vmnet1
    192.168.1.0 * 255.255.255.0 U 0 0 0
    eth0
    172.16.108.0 * 255.255.255.0 U 0 0 0
    vmnet8
    link-local * 255.255.0.0 U 0 0 0
    eth0
    loopback * 255.0.0.0 U 0 0 0 lo
    default router 0.0.0.0 UG 0 0 0
    eth0
    --------------------



    --
    Cheers / Saludos,

    Carlos E. R.
    (from 11.2 x86_64 "Emerald" at Telcontar)

  2. #2
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    3,390

    Default Re: Routing from host to vmware (server) guests

    Yeah,
    An issue every new VMware Workstation/Server User runs into is that the host does not use the same name resolution lookup configuration or otherwise share name resolution resources as the guests unless you deploy in a network and point everyone to your network resources(eg Localdomain DNS).

    Solution:
    Configure LMhosts and Hosts on your Hostmachine pointing to your Guest VMs. I typically create shortcuts to these files so that anytime the VMware DHCP changes an IP address, I can re-configure the appropriate files easily.

    HTH,
    Tony

  3. #3
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    22,724

    Default Re: Routing from host to vmware (server) guests

    On 2010-10-30 23:36, tsu2 wrote:
    >
    > Yeah,
    > An issue every new VMware Workstation/Server User runs into is that the
    > host does not use the same name resolution lookup configuration or
    > otherwise share name resolution resources as the guests unless you
    > deploy in a network and point everyone to your network resources(eg
    > Localdomain DNS).
    >
    > *Solution:*
    > Configure LMhosts and Hosts on your Hostmachine pointing to your Guest
    > VMs. I typically create shortcuts to these files so that anytime the
    > VMware DHCP changes an IP address, I can re-configure the appropriate
    > files easily.


    Lmhost is for samba, and I'm not using it. The hosts file is for
    translating names to IP, and that is working correctly.

    The problem is that I can not ping, ssh or anything from the host to the
    guest, using IP numbers or names. It hangs for ever, no answer.

    From guest to guest or guest to host it works perfect. Name resolution
    is working perfect on both sides.


    --
    Cheers / Saludos,

    Carlos E. R.
    (from 11.2 x86_64 "Emerald" at Telcontar)

  4. #4
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    3,390

    Default Re: Routing from host to vmware (server) guests

    Didn't notice eaiiler that you expressly tried PING or TRACE using IP addresses...

    Looks like you may have to take a closer look at the details...
    1. Are you using the vMware Server DHCP?
    2. Is your machine standalone or are you connect in any way to a network (esp one running DHCP)?
    3. I haven't presonally looked closely at whether OpenSuSE supports NIC auto-sensing, if it does then you may want to place a dongle or connect to a powered hub with nothing else connected.
    4. Has your Gues VM always lived on this one Hostmachine, or was it created or deployed on another machine at any time?

    5. Pls post the following
    VMware VM config file
    IFCONFIG of each machine
    ROUTE of each machine

    Tony

  5. #5
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    22,724

    Default Re: Routing from host to vmware (server) guests

    On 2010-11-01 17:06, tsu2 wrote:
    >
    > Didn't notice eaiiler that you expressly tried PING or TRACE using IP
    > addresses...
    >
    > Looks like you may have to take a closer look at the details...
    > 1. Are you using the vMware Server DHCP?


    Yes, default setting. NAT.

    > 2. Is your machine standalone or are you connect in any way to a
    > network (esp one running DHCP)?


    I don't understand. If you mean the host, no, it is a fixed local IP. It
    is my desktop work machine. However, I'm not attempting to connect from
    one computer to another, I'm connecting from the host linux system to
    the guest linux system inside vmware, all in the same iron. It works
    from guest to guest or guest to host, just not from host to guest.

    > 3. I haven't presonally looked closely at whether OpenSuSE supports NIC
    > auto-sensing, if it does then you may want to place a dongle or connect
    > to a powered hub with nothing else connected.


    I don't understand.

    > 4. Has your Gues VM always lived on this one Hostmachine, or was it
    > created or deployed on another machine at any time?


    Yes, the VM were copied from another machine that originally had VMW
    server version 1, and this one has version 2.

    I may try soon to create a new guest machine, running 11.3.


    > 5. Pls post the following
    > VMware VM config file
    > IFCONFIG of each machine
    > ROUTE of each machine


    As I can't ssh-in to the guest, I can't copy that data. I can't copy
    paste in the version 2 server, i don't know how to do that. i have to
    hand copy.

    it has an inet 6 address, and an... NO! It does not show an IPV4
    address. So that's it... [...] No, false alarm. It did not, now it has.
    I have just de-hibernated the guest for your question, the dhcp lease
    was timed out, and needed some time to obtain a new (the same) IP address.

    Ok, it reads that it has an inet addres of 172.16.108.129, bcas, mask,
    and ipv6 addr, packets sents/received, no errors. If you need exact
    data, I only can do a PNG capture, not text (gnome print screen on the
    host).


    routing:

    code:
    ---------------------
    kernel ip routing table
    destination gateway genmask ..... iface
    172.16.108.0 * 255.255.255.0 eth0
    link local
    loopback
    default 172.16.108.2 0.0.0.0. eth0


    ---------------------


    But as I say, the guest has no problems, it is the host that can not
    even ping the guest.

    From the guest I can reach internet or another guest, or the host
    system, no problem (by name or by IP). But what I need is the reverse,
    host to guest

    code:
    ---------------------
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use
    Iface
    minas-tirith.va router 255.255.255.255 UGH 0 0 0
    eth0
    192.168.18.0 * 255.255.255.0 U 0 0 0
    vmnet1
    192.168.1.0 * 255.255.255.0 U 0 0 0
    eth0
    172.16.108.0 * 255.255.255.0 U 0 0 0
    vmnet8
    link-local * 255.255.0.0 U 0 0 0
    eth0
    loopback * 255.0.0.0 U 0 0 0 lo
    default router 0.0.0.0 UG 0 0 0
    eth0
    ---------------------


    The guest is on 172.16.108.129, so a ping to it should be routed via
    vmnet8. AFAIK the table is correct. Or does it need a gateway explicitly
    defined? The route is set by vmware, not by me.

    code:
    ---------------------

    ping local host from host:

    Telcontar:/etc/named/zone # ping 172.16.108.1
    PING 172.16.108.1 (172.16.108.1) 56(84) bytes of data.
    64 bytes from 172.16.108.1: icmp_seq=1 ttl=64 time=0.027 ms

    Telcontar:~ # ping -I vmnet8 172.16.108.1
    PING 172.16.108.1 (172.16.108.1) from 172.16.108.1 vmnet8: 56(84) bytes
    of data.
    64 bytes from 172.16.108.1: icmp_seq=1 ttl=64 time=0.025 ms

    ping guest "gateway"

    PING 172.16.108.2 (172.16.108.2) from 172.16.108.1 vmnet8: 56(84) bytes
    of data.
    ^C
    --- 172.16.108.2 ping statistics ---
    5 packets transmitted, 0 received, 100% packet loss, time 3999ms

    ping guest

    Telcontar:~ # ping -I vmnet8 172.16.108.129
    PING 172.16.108.129 (172.16.108.129) from 172.16.108.1 vmnet8: 56(84)
    bytes of data.
    ^C
    --- 172.16.108.129 ping statistics ---
    11 packets transmitted, 0 received, 100% packet loss, time 9997ms

    ---------------------

    An interesting thing I just noticed is that the guest can not ping
    172.16.108.1, which is the IP number of the host in the interface
    vmnet8. It has to use the 192.168.1.* IP to succeed.


    I think that what is missing is forwarding between 192.168.1.0 and
    172.16.108.0...

    I'm going to bed.


    --
    Cheers / Saludos,

    Carlos E. R.
    (from 11.2 x86_64 "Emerald" at Telcontar)

  6. #6
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    3,390

    Default Re: Routing from host to vmware (server) guests

    OK,
    While I'm looking at your data,
    Here's some feedback on your comments...

    1. One thing I'm considering is whether the physical NIC your virtual adapters are bound to are active or disabled. Windows has a feature called "autosense" which is enabled by default and has to be disabled so that the NIC is usable even when not actively connected to another physical network device. Although you describe successful ping in one direction, a physical NIC not active could conceivably be weird, not entirely on or off. But, it's only a consideration, not a certain problem.

    2. The reason why I asked about the origin of the VM is only to narrow down network mis-configuration possibilities. So, based on what you described, I would ask you to take a close look at how each VMware Server NAT virtual network is configured, if I were to guess for instance since VMware randomly assigns new networkIDs with every installation, you should take a particularly close look at the networkID and verify a new DHCP lease has been issued (typically, you should expect a different IP address than what existed with the first deployment). I don't think that you need to get into the technical nitty-gritty, but a wireshark analysis of ARP might also reveal using a lease from the previous deployment. In fact, now that I think of it, although it requires checking, I remember that in the real world I ran into exactly the problem you're describing when the machines had mis-matched subnet masks, one machine accepted the other machine on its network but vice versa the other machine didn't (just a possibility, not certain that's happening here without more inspection).

    3. AFAIK there should not be any issue moving VMs from VMware Server 1 to VMware Server 2 or back again or any VMware product as long as you don't upgrade the VM (normally within reason VMware Products are backwards compatible with VMs from previous versions). Once you upgrade a VM though, you can't go back.

    4. If you have VMware Extensions installed, typically the GuestVMs should have access to the Host's clipboard which means that Copy/Paste between VMs should work (but not DragNDrop). By default, OpenSuSE installs the Open Source version of the Extensions which is less capable than the proprietary version, if you want more features than you're getting now, then you should consider installing the proprietary version... It's free but you have to get it from VMware (The code can't be distributed by others).

    Tony

  7. #7
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    3,390

    Default Re: Routing from host to vmware (server) guests

    The first things I'm noticing is that although you say that the Guest to Host works, unless I'm misreading your info that's not true...

    I also noticed that whether you forced/re-configured or not, as you say you are trying to preserve the same NAT NetworkID, I recommend you don't do that to avoid confusion. If you have a good reason to preserve the NetworkID, I would suggest you manually clear your arp and nbstat caches, then try again.

    But, those are based on especially if the client is unable to ping the gateway if I'm interpreting your data correctly.

    What is in the Hosts file of your Host machine? Did you configure entries for your GuestVMs? As I suggested before, that a Host file entry only addresses Host name resolution for IP utilities like PING. If you configure Shares you will likely have to configure a LMhost entry that matches any Host file entry you make.

    Tony

  8. #8
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    22,724

    Default Re: Routing from host to vmware (server) guests

    On 2010-11-03 14:40, tsu2 wrote:
    >
    > The first things I'm noticing is that although you say that the Guest to
    > Host works, unless I'm misreading your info that's not true...


    I'll write a table. Using pings by number, not name.

    The guest is 172.16.108.129 and the host 192.168.1.14.

    The host is also 172.16.108.1, and the guest has 172.16.108.2 as its
    gateway.

    Host side:

    192.168.1.14 (H) --> 172.16.108.1 (H) Yes
    192.168.1.14 (H) --> 172.16.108.2 (GstGw) No
    192.168.1.14 (H) --> 172.16.108.129 (GstGw) No

    Guest side:

    172.16.108.129 (Gst) --> 192.168.1.14 (H) Yes
    172.16.108.129 (Gst) --> 172.16.108.1 (H) No
    172.16.108.129 (Gst) --> 172.16.108.2 (GW) Yes


    > I also noticed that whether you forced/re-configured or not, as you say
    > you are trying to preserve the same NAT NetworkID,


    What is that? I dunno what is "NAT NetworkID".

    > I recommend you don't
    > do that to avoid confusion. If you have a good reason to preserve the
    > NetworkID, I would suggest you manually clear your arp and nbstat
    > caches, then try again.
    >
    > But, those are based on especially if the client is unable to ping the
    > gateway if I'm interpreting your data correctly.


    The client can ping the host, using the "official" IP of the host (or
    its name), but not the IP in the 172 network (see the lone "no" in the
    guest part of the table above).

    Notice also that services in the host called from the guest work: ssh,
    bind... but services in the guest can not be called from the host. That
    is the problem.


    > What is in the Hosts file of your Host machine? Did you configure
    > entries for your GuestVMs? As I suggested before, that a Host file entry
    > only addresses Host name resolution for IP utilities like PING. If you
    > configure Shares you will likely have to configure a LMhost entry that
    > matches any Host file entry you make.


    Name resolution works, on both sides.


    To me it appears there is a barrier on the VMware server configuration
    that blocks network going from host to guest in NAT mode.

    If I set the network type to "host only" I have the same problem.

    In "bridge mode" it works almost fine - almost because it got an IP from
    my adsl router, and uses my ISP as name server, thus local names do not
    work. This is solvable, but I don't want my guest to be that accessible.
    I want them isolated.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 11.2 x86_64 "Emerald" at Telcontar)

  9. #9
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    22,724

    Default Re: Routing from host to vmware (server) guests

    On 2010-11-03 14:40, tsu2 wrote:
    >
    > OK,
    > While I'm looking at your data,
    > Here's some feedback on your comments...
    >
    > 1. One thing I'm considering is whether the physical NIC your virtual
    > adapters are bound to are active or disabled. Windows has a feature
    > called "autosense" which is enabled by default and has to be disabled so
    > that the NIC is usable even when not actively connected to another
    > physical network device. Although you describe successful ping in one
    > direction, a physical NIC not active could conceivably be weird, not
    > entirely on or off. But, it's only a consideration, not a certain
    > problem.


    In NAT mode in vmware the guests only see a "faked" network card, which
    to me is fine.

    In another post I comment that networking works in bridge mode (without
    rebooting the VM). It is NAT and HostOnly which fail in the direction
    host to guest.

    But I don't want bridged mode, I do not want my VM to be accesible from
    my local network, I can not firewall it that easily if it shares the
    same eth0 interface with the host.

    I might use NAT or HostOnly for my windows VM, and Bridge mode for the
    linux guest - it has a good firewall, after all.

    > 2. The reason why I asked about the origin of the VM is only to narrow
    > down network mis-configuration possibilities. So, based on what you
    > described, I would ask you to take a close look at how each VMware
    > Server NAT virtual network is configured, if I were to guess for
    > instance since VMware randomly assigns new networkIDs with every
    > installation, you should take a particularly close look at the networkID


    What is the network ID?

    If you mean the number by which the web console identifies them (80 in
    this guest), I don't see how to access that in the network configuration.

    > and verify a new DHCP lease has been issued (typically, you should
    > expect a different IP address than what existed with the first
    > deployment).


    The IP ends the same, 129. The rest of the numbers have changed
    (172.16.108), which happens when you run the vmware server install. I
    simple rewrote the DNS and hostnames.

    > I don't think that you need to get into the technical
    > nitty-gritty, but a wireshark analysis of ARP might also reveal using a
    > lease from the previous deployment. In fact, now that I think of it,
    > although it requires checking, I remember that in the real world I ran
    > into exactly the problem you're describing when the machines had
    > mis-matched subnet masks, one machine accepted the other machine on its
    > network but vice versa the other machine didn't (just a possibility, not
    > certain that's happening here without more inspection).


    Mmm.

    I may try wireshark.


    > 3. AFAIK there should not be any issue moving VMs from VMware Server 1
    > to VMware Server 2 or back again or any VMware product as long as you
    > don't upgrade the VM (normally within reason VMware Products are
    > backwards compatible with VMs from previous versions). Once you upgrade
    > a VM though, you can't go back.


    I did upgrade the VM, as a matter of fact. Version 7 virtual hardware,
    it says. I had to rerun network configuration in YaST.


    > 4. If you have VMware Extensions installed, typically the GuestVMs
    > should have access to the Host's clipboard which means that Copy/Paste
    > between VMs should work (but not DragNDrop). By default, OpenSuSE
    > installs the Open Source version of the Extensions which is less capable
    > than the proprietary version, if you want more features than you're
    > getting now, then you should consider installing the proprietary
    > version... It's free but you have to get it from VMware (The code can't
    > be distributed by others).



    The guest additions are running, it says, the open version, I guess, but
    I have no graphical system, it locks. That is precisely the reason I
    wanted to ssh-in from the host, to kill the graphical server. Currently
    I have to reboot the VM from the host.

    This VM was OS 11.1, and I upgraded it to 11.3 precisely because I was
    doing a test for a bugzilla of the upgrade procedure. When you upgrade
    there is no hardware detection, so the X system was not reconfigured. I
    have saved a snapshot, so I can go back to 11.1, and instead install
    another VM fresh as 11.3, which I intend to do, and see if NAT works there.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 11.2 x86_64 "Emerald" at Telcontar)

  10. #10
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    3,390

    Default Re: Routing from host to vmware (server) guests

    1. NetworkID is the portion of the Network Address that is masked, eg in a default Class C network when the mask is 255.255.255.0 and a Host address is 192.168.1.1, the "NetworkID" is 192.168.1.0 and the "HostID" is 1. I see later you said you seem to be applying a Default Class C network mask to your Class B address space, so your current NetworkID is 172.16.108.0
    2. I think 172.16.108.129 is incorrectly identified as a GuestGW, it's the Guest Network Address only, right? There should be only one GuestGW, 172.16.108.2 (can try the alternative address 172.16.108.1)

    The client can ping the host, using the "official" IP of the host (or
    its name), but not the IP in the 172 network (see the lone "no" in the
    guest part of the table above).
    There isn't really any IP address which is more "official" than another, but different services may be bound to specific IP addresses so will work only on those IP addresses. I think you may just be noting that 172.16.108.1 is not responding to PINGs. I doubt necessary, but if you wanted to investigate further you could probably list service sockets and bindings on the Host machine to verify why you see what you see.

    If IP and name resolution works both ways, then any inaccessible services are not network problems, troubleshooting should center on local machine configurations (firewall, whether services are running, whether services are bound to the specific NICs). There really isn't anything specific I know of and native to VMware that filters traffic (ie blocks only SSH but permits ICMP).

    I still suspect an inconsistency/failure related to the two networking layers IPv4 addressing and MAC addresses (which would be revealed by ARP inspection but likely can be addressed by simply clearing the ARP cache on both the Host and Guest machines), which could possibly be caused when migrating between networks with very similar namespaces and even same addressing schemes but the machines are actually different. It's just an uncomfortable suspicion without concrete evidence largely based on what is common to the Host and NAT networks (VMware virtual network schemes) vs the bridged network (uses actual network scheme).

    That is why based on personal experience I apply KISS, I make every network I touch as <different> as possible and journal namespaces I've used to make sure I don't re-use them, ever. The only time I've only appeared to preserve networks when migrating is when I've been able to truly transport the actual resources, so the network doesn't just appear to be the same as before, it actually is.

    So, if I were in your case to minimize potential problems moving from one VMware Server NAT network to another, I would have made sure the Host machines were named differently and the NetworkID (in your case likely 172.16.108.0) were different. In fact, even now I would suggest changing your NAT NetworkID to something else, like 172.16.224.0 after which every member in your new network would be forced to "re-register" and obsolete all old configurations.

    Re the VMware extensions, I assume you know that it's not enough to just have them available, you have to actually install them into the GuestVM by
    1. Enable the VMware Extensions in the VM properties
    2. From within the VM browse to the virtual optical media device
    3. Typically just click/run the rpm, optionally you can also build from the available source
    4. After install, shutdown and uncheck "Install VMware Extension" to remove access to the special VMware Extensions image and restore access to physical media.

    In my experience, the SuSE open source version of the VMware extensions have done a good job supporting various video resolutions up to VMware workstation 6.5, but I suppose YMMV.

    Good Luck,
    Tony

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •