VERDE VDI Network Troubleshooting - Navigate via Table of Contents.

VERDE VDI Network Troubleshooting - Navigate via Table of Contents.

Product Line:  VERDE


Introduction:

The information contained within this document refers to the networking aspects of the VERDE VDI software solution being installed via a set of RPMs (program modules) on top of CentOS7. 

The following networking information is made up of basic CentOS7 (Linux networking) and additions/extensions added from the VERDE VDI installation and configuration.


[ VERDE VDI solution Overview]

 

The VERDE VDI (virtual desktop infrastructure) solution was designed from the ground-up to be used for virtualizing desktop PCs. VERDE VDI is installed on-top of a Linux OS (recommend CentOS). It uses the built-in KVM hypervisor that is part of CentOS (Linux) and offers a less complex design, allowing customers to quickly implement VDI in their environment within hours, not days or weeks. VERDE is also one of the most cost-effective solutions available, with a very low requirement for ongoing support and maintenance.  All that is required to setup a quick ‘test’ environment is a single server with 16 Gig RAM and 250 Gig diskspace.

 

Some of VERDE VDI added benefits include: 

·        Scalable design from a single server to multiple server nodes hosting 1000’s of VMs

·        High-availability with automatic failover with a VERDE Cluster – two or more servers

·        Built-in Load-balancing - function of the Connection Broker

·        OpenLDAP server and Microsoft Active Directory integration

·        Web-based Management Console – where most VERDE configuration is performed

·        VERDE is based on Gold Master images with full life-cycle management

·        Virtual desktops consist of a System Layer (OS, applications) and a persistent User Layer

·        VERDE supports both Windows and Linux virtual desktops (Guest sessions)

·        VERDE provides high-performing Guest sessions with User-customizable desktops

·        Multiple ways to connect to a Guest session:  VERDE software Client (for Windows, MAC, Linux), HTML-5 Web browser, NComputing Thin-client devices, LEAFOS (VERDE software-based Thin-client app)

 

VERDE VDI can be implemented with a single server using Local Storage, for the purpose of setting-up a quick POC (Proof of Concept).  And easily scaled by adding one or more additional server nodes along with Shared Storage to host the central Database, for increased Workloads.  VERDE VDI can scale to 100’s of server nodes, all managed by a central Management Console.


 

[ Implementing VERDE VDI with Advanced Network Configuration]

 

VERDE VDI can start out as a single server, using a basic Network configuration, and scale to two or three additional server nodes for a small to mid-size Company without requiring a Linux skillset, all managed by the VERDE central Management Console.

 

When implementing VERDE VDI in a much larger environment with a more advance network configuration, i.e. multiple NICs, Network Bonding, Network Teaming or VLANs, then a Linux skillset if required to configure the Linux network interfaces.  Most/all of the network configuration is done at the Linux command prompt (not within the VERDE VDI system) and VERDE VDI will integrate with the network layer below.  As the Linux networking gets more complex, issues can arise requiring the need for some Linux networking Tools to help resolve the issues.

 

I will include a list of some of the most useful Linux Tools and:

·        Explain some typical issues within the VERDE environment

·        Introduce a Linux tool that can be used

·        Explain how the Tool helped to resolve the issue


[ Network Tools for Access and Troubleshooting]

 

Client-side applications:

There are a few tools available from an endpoint (example Windows PC) on the VERDE network that can be used to troubleshoot various connection issues. The following are some typical issues that can happen within the VERDE network.

 

EXAMPLE: Endpoint can’t connect to VERDE server

 

DOS PING Command:  This is one of the first tests that can be performed from a Windows/MAC/Linux workstation to ensure that the VERDE server is visible on the Company network.  With the many layers of security via Firewalls, Routers, network Switches, Packet shapers, Load-balancers, VLANs, etc, that are put in place to protect Company assets, it is easy to inadvertently BLOCK the VERDE server from the Company network.  A simple PING command from an endpoint, to the Hostname or IP address of the VERDE server will suffice.



 

Secured Shell:       This tool is used by VERDE administrators, from endpoints on the network and allows a secured connection to the VERDE VDI server, prompting you to login to the Linux OS.  Once you are logged-in to the VERDE server, you can enter several commands to manage the server and network.

               

                              Example of Windows based clients:   Putty, WinSCP

 


1.     For example, you can display the Linux network interfaces:  # ]  ifconfig

 

The following is a display of the (4) network interfaces installed in my VERDE server.

This displays a lot of details about each interface including IP address information.

 

em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.1.50  netmask 255.255.255.0  broadcast 192.168.1.255

        ether 00:21:9b:9a:fd:f5  txqueuelen 1000  (Ethernet)

        RX packets 2739209  bytes 3769660575 (3.5 GiB)

        RX errors 0  dropped 175  overruns 0  frame 0

        TX packets 1818433  bytes 146208928 (139.4 MiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

em2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        ether 00:21:9b:9a:fd:f7  txqueuelen 1000  (Ethernet)

        RX packets 117818  bytes 18170684 (17.3 MiB)

        RX errors 0  dropped 175  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

em3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        ether 00:21:9b:9a:fd:f9  txqueuelen 1000  (Ethernet)

        RX packets 117818  bytes 18170684 (17.3 MiB)

        RX errors 0  dropped 175  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

em4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        ether 00:21:9b:9a:fd:fb  txqueuelen 1000  (Ethernet)

        RX packets 117817  bytes 18170590 (17.3 MiB)

        RX errors 0  dropped 175  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

       

        OTHER THINGS YOU CAN DO with SSH

2.     Configure the Linux network interfaces

3.     Review VERDE server logs

4.     Start/stop VERDE services

5.     Restart the CentOS network

6.     Reboot the VERDE VDI server

 

Secured--FTP:        Allows a secured FTP connection from another endpoint over the network,

                              to the VERDE VDI server.

 

            Example of Windows based clients:   FileZilla, WinSCP

 

HOW to Use: This workstation application provides a secured-FTP connection from an endpoint, to login to the VERDE VDI server. You can peruse the Directory structure of the VERDE VDI system and transfer files to/from the VERDE server (such as Log files). 



Windows Telnet Client:  Provides a simple way to test if specific TCP Ports that are required by the VERDE VDI system, are available from an endpoint on the network.

 

This client-side tool may need to be installed from the Windows ‘Programs and Features’ – ‘Turn Windows features on or off’

 

NOTE:  You may be required to work with your IT Support Desk

In order to add this application.



Once the Windows Telnet client is available, you can use it to troubleshoot connection issues from a PC workstation on the network.

 

EXAMPLE: Can’t Login to VERDE server with VERDE Client 

Say that you tried to launch the VERDE client from your Windows PC by correctly entering the Hostname or IP address of the VERDE server and your valid Credentials, but you are not able to connect to the VERDE server.



A simple first Step is to use the Windows Telnet client to test that the two required TCP Ports are available on the VERDE server from your PC workstation.

 

These TCP Ports are:  8443 and 48622

 

TCP Port:  8443 is required by the VERDE client to successfully Login to the VERDE Server.

 

After a successful Login, then TCP Port:  48622 is required to access the Virtual desktop (Guest session). 

 

Both of these TCP Ports need to be ‘open’ to your PC workstation.




FOLLOW-UP ACTION:  At this point, you would need to contact your internal

IT Support Desk and provide the above Feedback.

 

NOTE:  If you are able to successfully Login with the VERDE client, but are not able to access your virtual Desktop, this means that the 2nd required TCP Port 48622 may NOT be responding from your PC workstation.  You can use the same action as above from the DOS Command prompt to test TCP PORT: 48622


FOLLOW-UP ACTION:  At this point, you would need to contact your internal IT Support Desk and provide the above Feedback.

 

CentOS 7 Server-side tools:

Sometimes after the VERDE server has been configured and setup on the Company network, specific connectivity issues may appear that need server-side troubleshooting tools.  I will list some of the more general issues that you may encounter and the Tool that you can use to resolve these issues.

 

NetCat:          This is a very useful tool that is executed from the CentOS command prompt.  It allows the VERDE admins to test connectivity for various TCP and UDP Ports.

 

If this tool isn’t already installed in your VERDE server, you can quickly install it from the CentOS command prompt.

 

Command prompt: # ]  yum -y install nc

 

EXAMPLE: Internal DNS Server Issue

Say that you want to verify that your internal DNS server is providing Name Resolution of Hostnames from your VERDE server.  You can use the NetCat Tool and test for the DNS Port to be ‘open’ from the VERDE server.  Domain Name Services uses a UDP Port:  53.

 

HOW to Use:  Issue a NetCat command from the VERDE server to test if UDP Port 53 (DNS) is open to the VERDE Server. For UDP Ports, you need to add the ‘-u’ parameter to the command line.

 

Command prompt: # ]  nc -vz ad_domain_server -u 53  <--- Test if DNS is open




EXAMPLE: Can’t connect to NComputing License Server

Say that you are having issues activating the VERDE Server License from the VERDE Management Console.  The first thing you can do is verify that the required TCP Port is ‘open’ for the VERDE server to reach the NComputing Web Portal.  This Website only requires an SSL connection across the Internet from the VERDE server.

 

HOW to Use:  You can use the NetCat tool from the VERDE server to test if TCP Port 443 (SSL) is open to the Server.

 

Command prompt: # ]  nc -vz ncomputing.com 443   <--- Testing if SSL is open


 

The above screen shows that SSL is ‘open’ to the VERDE server from the NComputing Web Portal across the Internet.  If you continue to have a VERDE Licensing issue, since the VERDE server can connect to the NComputing Web Portal, you may need to contact NComputing Support to resolve your Licensing issue.

 

EXAMPLE: Can’t connect to the Internet from VERDE server

Say you are getting an UNSUCCESSFUL connection across the Internet, trying to PING the Google Public DNS Server.


Here is something to check, to see if the VERDE server is allowed access to the Internet.  This issue ‘Network is unreachable’ might mean that either the ‘GATEWAY’parameter is missing in the network interface configuration file (located in Path: /etc/sysconfig/network-scripts/), or there is a Security policy in-place within the Network that is BLOCKING the VERDE VDI server from reaching the Internet.

 

See a display (below) of the network configuration file that is being used for my primary network interface from the path:

/etc/sysconfig/network-scripts/ifcfg-em1.


FOLLOW-UP ACTION:  The VERDE Admin would need to remove the ‘#’ character that is commenting out the Default ‘GATEWAY=’ parameter or enter the correct parameter.  This change could resolve the issue, since the VERDE server has no Default Gateway configured.

 

EXAMPLE: No Public DNS Resolution

The next screen is another common issue that can be identified using the NetCat tool.  This shows that the Fully Qualified Domain Name cannot be resolved internally via a DNS server, for the NComputing Web Portal at:  ncomputing.com



EXAMPLE: Test if LDAP Port is Open on LDAP server

Say that you are configuring the VERDE server to integrate with an OpenLDAP server or with a Microsoft Active Directory Domain server that is providing LDAP Authentication services.  LDAP authentication requires TCP Port: 389 (clear text)  -or -  TCP Port: 636 (Secured LDAP) to be ‘open’ to the VERDE server.

 

You can quickly test for this by using the NetCat tool.

 

HOW to Use: You can use the NetCat tool from the VERDE server to test if TCP Port 389 (LDAP) is open to the VERDE Server.

 

Command prompt: # ]  nc -vz ad_domain_server 389  <--- Test if LDAP is open

                                (See screen below)

 

EXAMPLE: No DHCP on Bridged interface on Guest Sessions

Say that you have configured a Bridge interface on your VERDE server and want your internal DHCP server to issue TCP IP addresses to each of your Guest sessions.

 

However, when viewing ‘Live Sessions’ from the VERDE Management Console, you are not seeing IP addresses being assigned on the Bridged interface within the Company Subnet that has a DHCP server.

 

            DHCP requests require a UDP Port: 67 to respond from your DHCP server.

 

You can use the NetCat tool to confirm that your VERDE server is receiving DHCP traffic across the network.

 

HOW to Use:  Issue a NetCat command from the VERDE server to test if UDP Port 67 (DHCP) is open to the VERDE Server. For UDP Ports, you need to add the ‘-u’ parameter to the command line.

 

Command prompt: # ]  nc -vz my_dhcp_server -u 67  <--- Test if DHCP is open

Network Issue with NAT Interface from VERDE Management Console:

VERDE VDI automatically implements NAT networking during the initial configuration, that is private and non-routable.  It uses the network interface called:  vbinat0

 

NAT networking provides a very quick way of readying the network layer for deploying Guest sessions, once a Gold image has been created and Published.  No additional Steps are needed for NAT networking to launch virtual desktops.


During the initial VERDE configuration, this interface will be created and default to IP Subnet:  192.168.84.0/24 with a Host IP address:   192.168.84.254.  You can change this Subnet during the initial configuration.  This interface will also automatically be configured with DHCP services to assign dynamic IP addresses to non-bridged Guest sessions (virtual machines) within the IP Range:  192.168.84.1 .. 192.168.84.253

 

It is important to note that each VERDE server that hosts Guest sessions will use the exact NAT interface configuration, with the same IP Subnet that was assigned during the initial VERDE configuration.  This means that each Guest session on each VERDE server will use the

same Private Subnet and dynamically assign IP addresses using the range:   a.b.c.1 .. a.b.c.253. 

 

Example:   If the default setting was used for the NAT interface during the initial VERDE configuration, the dynamic IP range would be:   192.168.84.1  ..  192.168.84.253

 

NOTE:   This exact same Subnet will be implemented for each of the NAT interfaces on EACH VERDE server that hosts Guest sessions.  And VERDE will dynamically assign the same Range of IP addresses on each server. 

 

This is NOT a Problem, since each set of IP addresses is specific to each VERDE server and may look like duplicate IP addresses from the unified VERDE Management Console ‘Live Sessions’ screen, since VERDE will display ALL Guest sessions across all of your VERDE servers and within each VERDE server, you will see the same IP address range being assigned to each of its Guest sessions.




Remember, the vbinat0 interface is Private to each VERDE server and the IP addresses that are assigned are NOT Routable, so there is NO IP address conflict across your Network, since all IP traffic from the NAT interface on EACH VERDE SERVER is translated from the Private IP address to the VERDE server IP address (Network Address Translation).   VERDE maintains all the IP session information by creating an internal Table that maps the Private IP address of the NAT interface to the VERDE server IP address and maintains all the details of each IP connection, so it can return the corresponding IP packets back to the originating Guest session.

 

DID YOU KNOW:  The IP Subnet that is used on each VERDE server CAN BE DIFFERENT.  During the initial VERDE configuration, when you assign the NAT Subnet, VERDE saves this information into the file path:  /var/lib/verde/settings.node     

 

See the exact command that assigns the NAT Subnet (highlighted below).



This same file exists on each VERDE server and can be MODIFIED, to change the NAT IP Subnet to something different, to distinguish its IP range from other VERDE servers using NAT networking.

 

For example:    You could leave the ../settings.node file with the default value in the first VERDE server.  Then you could edit this file on your 2nd, 3rd, etc servers with a slight variation, as follows:

 

VERDE Server1:        192.168.84                  IP Range:   192.168.84.1 .. 192.168.84.253

VERDE Server2:        192.168.85                  IP Range:   192.168.85.1 .. 192.168.85.253

VERDE Server3:        192.168.86                  IP Range:   192.168.86.1 .. 192.168.86.253

 

After making these changes, you will have to ‘restart’ the VERDE service.  (see below).

BEFORE ‘restarting’ VERDE services, you should ‘shutdown’ all active sessions and Check-in any Gold images that are being modified.



After VERDE restarts, any new Guest sessions starting-up on each of the VERDE servers will now show a slightly different IP address for all NAT network sessions.  You can see this from the VERDE Management Console under:  ‘Reporting’ - ‘Users’ - ‘Live Sessions’

 

Network Issues within VERDE Guest sessions (VMs):

Sometimes after the VERDE server has been setup and Gold images have been created and provisioned, network issues can appear from within a Guest session or virtual machine (VM). Below are some examples if issues and how to troubleshoot them, using a Windows 10 virtual desktop.

 After successful login to a virtual Windows 10 desktop, it appears that the Guest session is NOT able to access the Internet.  This might happen, whether the Guest session is configured for NAT network (Private VERDE DHCP Subnet) or Bridged network (part of the Company IP subnet).  The most common problem is an ‘incorrect’ or ‘missing’ DNS server configuration within the Guest session.

 

DOS Command:  nslookup

 From the Windows 10 DOS Command prompt, you can use a built-in command ‘nslookup’ to request Name Resolution for a common URL.


EXAMPLE: No DNS Name Resolution for VERDE Guests

 

Example:   C>  nslookup www.google.com


You can see from the above screen that the IP address of the server providing

DNS Name Resolution is:  192.168.1.50.  In my case, this happens to be my VERDE server.

 

After examining the Linux file that is used to define the ‘nameservers’ located at the Path:  /etc/resolv.conf   I can see that the only entry points to the VERDE server itself, that is normally used for resolving ‘internal’ Hosts and is NOT configured to resolve Hostnames and URLs for the Internet.



From the above screen, you can see that the Guest session is now able to receive Name Resolution and should no longer have issues accessing the Internet.

 

EXAMPLE: Can’t connect with RDP to VERDE Guest

Say that a virtual Windows desktop has been provisioned for you and you have successfully logged into the Guest session.  And later, you want to use Remote Desktop Connection from another endpoint within your Company network, to access your VERDE Guest Windows session, but you can’t connect to it.  The most common reason for this is that your Windows Guest session was provisioned with the ‘Networking Type’ parameter of:  NAT   instead of Bridged. 

 

Setting this to ‘NAT’ will join your Guest session to the non-routable Private IP Subnet that is managed by the VERDE server. 

This Subnet is defined during the initial VERDE server configuration.

 

This default Subnet is:  192.168.84.0/24  and is hidden within the VERDE network layer, restricting any incoming traffic, thus BLOCKING your Remote Desktop Connection over RDP.

 


Now your Guest session can be re-launched and it will automatically receive a dynamic IP address from within your Company network DHCP server, allowing you to connect to your Guest session from another endpoint, using the Remote Desktop Connection application.

 

NOTE:  You will have to obtain the IP address that was dynamically assigned to

your VERDE Guest session, in order to connect to the Guest session from another endpoint within your network.









    • Related Articles

    • VERDE VDI Network Terms - Networking with Dual-NICs

      Product Line:  VERDE Preface:      The information contained within this document refers to the networking aspects of the VERDE VDI software solution being installed via a set of RPMs (program modules) on top of CentOS7.  The following networking ...

    • Verde VDI Network Terms and Descriptions - Basic Networking - NAT and Bridge

      Product Line:  VERDE Introduction: The information contained within this Knowledge Base Article refers to the networking aspects of the Verde VDI User application being installed via a set of RPMs (program modules) on top of CentOS7. The following ...

    • VERDE VDI Optimization for Windows 10

      Product Line:  VERDE   Introduction   A basic Windows 10 ISO is not configured by default for VDI implementation.  If not configured correctly, a Windows 10 guest will consume a a large amount of CPU, Memory and network resources per desktop. The ...

    • Discussion About VERDE VDI and Required Network Bandwidth

      Product Line:  VERDE Before we build VERDE VDI at a customer site, we generally consider the environment for the network.  · It is necessary to predict how much bandwidth will be used and needed between the VM and the user device or end-to-end in ...

    • Verde VDI Network Terms and Descriptions - VLANs

      Product Line:  VERDE Introduction:      The information contained within this document refers to the networking aspects of the VERDE VDI software solution being installed via a set of RPMs (program modules) on top of CentOS7.  The following ...