Unable to find the server

[djs-vm]

When attempting to run converter on a DMZ server I receive the error message "Unable to find the server". I have the necessary ports opened and verified that nothing is being blocked. I have attached the errors reported in the log files from the computer running converter and the source computer being converted.

[rushto_jp]

Hi, check whether ports 902 and 443 are opened..Also check ip address resolution works properly..DNS/ FQDN however its configured..

[djs-vm]

Yes, both ports are opened. I am under the impression that DNS is not required to work with the latest version of Converter. We are not resolving names to IP between the firewall and internal servers. I am running version 3.03 build 89816.

[vmspain]

You can use the file host instead of DNS to use VMware converter to solve the host names. It is a momentary solution to solve this problem.

[Jasemccarty]

Welcome to the forums.

I had an issue like this once. And without wanting to go through all the rigamarole of the network team, I made a folder on another box in the DMZ (a test box BTW), and simply had Converter P2V to a Workstation/Sever type VM, rather than trying to import into vCenter or ESX directly.

I then moved the VM files into the regular network, and used Converter again to import it into vCenter.

I like to think I used the "reverse impact method. Don't force it, use a hammer."

There is more than 1 way to skin a cat.

Jase McCarty

http://www.jasemccarty.com

Co-Author of VMware ESX Essentials in the Virtual Data Center

(ISBN:1420070274) from Auerbach

_{Please consider awarding points if this post was helpful or correct}

[IamTHEvilONE]

if you are using converter stand-alone to do the conversion, in step 2 specify the ESX host by IP Address. This should force converter to use IPs instead of host names.

Host names sometimes enter into the equation when you use VirtualCenter as the target, and it relays the host names back. If you are using the plugin version of converter, connect to vCenter using the IP Address instead of host name.

Regards,

EvilOne

NOTE: If your problem or questions has been resolved, please mark this thread as answered and award points accordingly.

[djs-vm]

I did enter the ip address and names in the host files; however, this did not resolve the issue.

[juchestyle]

Can you ping by name or IP from your converter box to the server you want to suck up?

Kaizen!

[djs-vm]

ICMP is blocked.

[djs-vm]

jasemccarty, If I cannot get it to work through the firewall I may use this method; however, I would like to avoid the additional steps as I have many servers to convert.

[Jasemccarty]

I would agree.

Sometimes you have to do what you have to do.

As an old Chief of mine said... "Borrow, steal, kill. Do what it takes to accomplish the mission"

Jase McCarty

http://www.jasemccarty.com

Co-Author of VMware ESX Essentials in the Virtual Data Center

(ISBN:1420070274) from Auerbach

_{Please consider awarding points if this post was helpful or correct}

[IamTHEvilONE]

here is a kitchen sink of a checklist:

Converter Diagnostic Check List

>Source: http://www.vmware.com/pdf/VMware_Converter_manual303.pdf

This is a generic guide and all may not apply - for instance if you are not using VirtualCenter, there is no need to test the connection between ESX and VC.

Check basic network

• ping from source system to VC host

• ping from VC to ESX target system

• ping from source system to ESX target system

• ping from ESX target system to VC host

• ping from ESX target to source system

Check the port usage (use telnet to verify)

• VMWARE Converter System to Physical Machine Ports 139, 445 using TCP Incoming.

• VMWARE Converter System to VirtualCenter/ESX Ports 443 Using TCP Outgoing

• Physical Machine to ESX Host Port 443, 902 using TCP Outgoing

• Physical Machine to VirtualCenter Port 443 using TCP Outgoing

• If you are using Converter 3.0.x, make sure you do not have a web server using port 443 while running Converter

Check Name Resolution

• Please ensure that all systems involved can resolve each others host name and FQDN

• Update DNS or Hosts file appropriately

Check credentials and privileges

• Ensure that each username can login to all systems (you may want to create one admin account on all systems to simply the testing)

• Ensure the user has permission to create a VM on the target system

• Ensure the user has access to LUNs on the target system

• Ensure the user has write privilege on target system storage devices

• Verify that the user can create a new VM on each target system from VirtualCenter

Your Virtual Center user (if applicable) needs the following privileges:

• Allow Read-Only

• Disk Access

• Allow Virtual

• Machine Files

• Download

• Inventory of VMs

Verify space requirements

• Check available file space on all systems (Depending on your method you will either need space equal to the selected drive or to the space used on the source drive.)

• Verify that the Target VM name does not exist on target system

• Optionally, turn firewall off on 3.0.x ESX servers

[juchestyle]

Hey DJS,

I am trying to do the same thing you are right now, and I am having the same problem. BUT, I think I have solved the issue as I can now suck this physical up!

How did I do it? Let me share, I had the network people open the ports, but only to the Vcenter server: 139,445,902, and 443. But it still failed...when I was using the client to log intoo Vcenter from my laptop! So I had this ephiphany, I logged into the VCenter server via RDP. I opened up the client inside the RDP session, typed in localhost, and logged in with my admin credentials. Launched the converter, and BAM! It worked like well disciplined step child!

Let me know if this works for you with correct points!

Respectfully,

Matthew

Kaizen!

[djs-vm]

I believe that my issue is that all of the ports are not open through the firewall even though the company that manages my firewall stated that all ports that I requested are open. When trying to telnet to the ESX server using port 902 it errored out; however, when performing the same task at my local computer it worked, proving that not all the necessary ports are open. I finally convinced the company that the problem is in the firewall and they are looking into it. Thanks for your input!

[juchestyle]

Hey are there any VMware employees out there that can explain why this is (see my post two up)?

VCenter is setup with open ports to the dmz, but when I connect to VCenter through my client on my laptop the connection to the server in the dmz fails. When I connect to the client from within VCenter the connection to the server succeeds? Shouldn't the communication either way be initiated from VCenter? Clearly the failure from my laptop suggests this is not the case.

Any help or suggestions would be appreciated!

Respectfully,

Matthew

Kaizen!

[djs-vm]

Did you have UDP ports 137 and 138 open? From what I understand these ports only need to be opened if you run the VC client from a third machine.

[juchestyle]

Hey man, great question! When I was looking through the documentation I didn't see anything like that, so no, I didn't ask the network team to open them. If that were to fix the issue, I think the documentation should be updated to include that section closer to the other section. Do you have a page number for that info?

Kaizen!

[IamTHEvilONE]

http://www.vmware.com/pdf/vi3_vec_10u2_admin_guide.pdf

Page 23 - Table 2-4

Ports required for Conversion:

Converter Enterprise server to remote physical machine TCP– 445, 139 + UDP– 137, 138

Converter Enterprise server to VirtualCenter Server 443

Converter Enterprise client to Converter Enterprise server 443

Physical machine to VirtualCenter Server 443

Physical Machine to ESX Server 902

[Texiwill]

Hello,

Check out http://itknowledgeexchange.techtarget.com/virtualization-pro/secure-method-to-p2v-across-security-zo... for a way to P2V across security zones.

Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
Blue Gears and SearchVMware Pro Blogs -- Top Virtualization Security Links -- Virtualization Security Round Table Podcast

[djs-vm]

After thorough troubleshooting we discovered that our WEB content filter wasn't allowing TCP port 902 to flow through. We have a Fortigate that sits between our network and the firewall. We could see the SND packet go thourgh; however when the SND ACK packet came back we saw it come in on the inside port of the WEB content filter but didn't leave. There may be a bug with the OS on the Fortinet or it doesn't like the packet structure coming back from the ESX server. We're still researching why the Foritnet is dropping this packet. You never get bored in this field!