The ideal answer (from a VM management perspective) to this is that you shouldn't be able to tell anything about the physical host unless that information has explicitly been made available to you. In practice VM installations tend to leak some information about the host, mostly because customized ( and often paravirtualized) drivers are installed that provide better VM performance. The default setup of VM environments will usually provide some basic information in various places (like the Hyper-V data you list).
While there are some scenarios where I can see legitimate reasons for wanting to do this (e.g. a VM in a cluster checking to see if the host its running on is actually delivering all the physical resources the VM believes it has before kicking off a high load but low priority task) almost all cases where a VM "wants" to figure out more about its host are malicious. If there is a valid reason for a process running in a VM to know this type of info then its a trivial task to set up a legitimate mechanism to provide that information to it - for the most part as a VM admin I don't want the VM's to be able to tell any of this.
This post from the Sourcefire VRT outlines some of the mechanisms that are used by Malware to detect whether they are running in a VM and the mitigation actions that can be taken to counter them - for the most part a VM can pretty much always tell that it is running in a VM and can usually tell the Hypervisor Vendor, probably identify the Hypervisor type and possibly make a good guess as to the specific version. Some additional info can usually be gathered from the network but that would almost certainly be the sort of activity that should be classified as malicious. If you read that post you will see that it is possible to configure a VM so that it is very hard for anything running in the VM to figure out anything other than the basic fact that it is a VM so relying on these mechanisms is a bad idea.
On your specific question about the "ip-address" of the Hypervisor the general answer would be that Hypervisors can have many ip-addresses - the Management console, iSCSI ports, Live Motion\Fault Tolerance ports and many ports that don't have explicit ip-addresses (VM ports) and other variations. Finding the management console ip-address(es) may be trivial - as per your Hyper-V example - but doing anything with it should be hard, in a well designed VM infrastructure the VM's shouldn't be able to route to the Management console address.