I stated in a previous post you didn't have to care for virtual networks, here's a more detailed explanation.
1/ What happens when you don't use virtual networks
Your machines get a random private IP address. Each machine in a given service (I should maybe say deployment, but there's a cloud service underneath your virtual machine, and it forms the network boundary) can see other machines in the same service. The default DNS gets you name resolution inside a service.
2/ What happens when you use a virtual network
To make that happen, you must declare an affinity group (an alias for a region), and use it to create a storage account and the VMs you want in that virtual network.
You then define a virtual network and a subnet. Once this is done, you can create virtual machines in that virtual network (more accurately, in a subnet of that virtual network). Now, you get inter-services network connectivity, as long as you're in the same virtual network, and even across subnets. What you don't get, though, is name resolution (you still get intra-service name resolution if you have VMs in the same service).
3/ An illustration
Suppose I have defined a virtual network (mynicevnet) and a subnet (mynicesubnet). now, let me create those machines :
machine1 (servicename : service1, subnet : mynicesubnet)
machine3 (servicename : service2, subnet : mynicesubnet)
machine2 (servicename : service1, subnet : mynicesubnet)
Note that I created the machines in the order above, and my subnet is 10.0.0.0/23
Now, let's SSH into machine1 :
As you can see, machine1 and machine2 have IPs 10.0.0.4 and 10.0.0.6, and machine1 resolves machine2
Now, let's ping 10.0.0.5 :
It works. Let's check the IP on machine3 :
If you only need a few machines, your best bet is to connect directly them in the same service (using the -c switch in the azure vm create command). You'll get name resolution and network visibility in a snap.
If you need more machines, or a more resilient setup, you can create several services in the same virtual network, and you'll have an expanded network visibility. Note that you'll get visibility across subnets as well. Machines living in the same service will also have name resolution inside the service.
If you want name resolution across services, you'll have to provide your own DNS. That could be an on-premise DNS if you use your Virtual Network with a VPN, or a remote DNS, or a cloud-hosted DNS. I won't elaborate on how to set up a DNS in detail, but know that in Azure it's a pain to reconfigure the DNS address in a virtual network once you have machines deployed, which causes a chicken-and-egg problem if you want to provision the DNS in the virtual network... I hope we'll soon have a better way to do this, but I have seen in my tests that the IPs are allocated sequentially when you provision machines, starting at 4. (in other words : if you create a subnet 10.0.0.0/23, the first machine you create in there will have the IP 10.0.0.4). So, just declare your DNS as 10.0.0.4 and make sure this is the first VM you provision.