Description of problem: Right now after I install a virtual machine. I login on it on the console and find out what its ip is then ssh to that from the host. It would be nice if I can ssh into the machine from the host using the name I gave it during set up in verirtmanager.
Trying to set the VM's name as the actual VM hostname doesn't sound like a good idea: it should really be an opt in thing. That said, we should try to find a way to expose the guest IP address in the UI if at all possible, so users can then SSH in. Not really sure what our options here are though. Moving to upstream tracker
*** Bug 781316 has been marked as a duplicate of this bug. ***
Hostname is exposed in the UI now if you have libguestfs set up. Still need IP though (although there still isn't a way to get it).
Moving to libvirt. once there is a libvirt API for this (maybe by communicating with a guest agent) it will be trivial to expose in virt-manager
Definitely a task for the guest agent, assuming that agents support it.
Also possible by snooping network traffic (and that's how nwfilter does it). qemu-ga in qemu 1.0 does not support it, so we'd need to clone this BZ to get it added in the guest agent before qemu 1.1. Both a guest agent and traffic snooping approaches can be spoofed, but this request has come up on the libvirt list before, and consensus was that it is a reasonable request. All it needs is someone to actually write a patch providing the new API, possibly with various flags bits to force which implementation(s) to try.
I think we need two different APIs: 1) give me all guest IPs from inside the guest 2) give me all guest IPs from outside because guest can create a totally different structure than what is visible from outside (bonding, virtual interfaces). Moreover, withing guest we likely want to report loopback, which is impossible from outside. On the other hand, outside guessing (what nwfilter does) is not as reliable as guest agent. Second, what should be the format of returned values? Ideally it would be pair of interface's alias/target dev (these can be seen in guest XML) and IP in string (char *). However, on the second thought, it wouldn't be possible when using guest agent as it is impossible to associate guest interface with host host interface (eth0 in the guest is vnet0 or vnet1?). Initially, MAC address can be used, but changing MAC within guest is not reflected to outside world. In addition, one interface can have multiple (or none) addresses. Therefore I prefer just to return an array of strings and let mgmt application to deal with it. I've started upstream discussion: https://www.redhat.com/archives/libvir-list/2012-February/msg00437.html
I've sent patch against qemu-ga which implements qemu part of this feature: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02328.html
*** Bug 967726 has been marked as a duplicate of this bug. ***
I proudly announce that the patches are pushed upstream for a while now: commit 2f36e6944e6eb56a00e19fcd85ec8513461597c9 Author: Nehal J Wani <nehaljw.kkd1> AuthorDate: Mon Jan 26 00:08:49 2015 +0530 Commit: Daniel P. Berrange <berrange> CommitDate: Tue Mar 17 15:15:39 2015 +0000 domifaddr: Add virsh support tools/virsh-domain-monitor.c * Introduce new command : domifaddr Usage: domifaddr <domain> [interface] [--full] [--source lease|agent] Example outputs: virsh # domifaddr f20 Name MAC address Protocol Address ------------------------------------------------------------------------------- lo 00:00:00:00:00:00 ipv4 127.0.0.1/8 - - ipv6 ::1/128 vnet0 52:54:00:2e:45:ce ipv4 10.1.33.188/24 - - ipv6 2001:db8:0:f101::2/64 - - ipv6 fe80::5054:ff:fe2e:45ce/64 vnet1 52:54:00:b1:70:19 ipv4 192.168.105.201/16 - - ipv4 192.168.201.195/16 - - ipv6 fe80::5054:ff:feb1:7019/64 vnet2 52:54:00:36:2a:e5 N/A N/A vnet3 52:54:00:20:70:3d ipv4 192.168.105.240/16 - - ipv6 fe80::5054:ff:fe20:703d/64 virsh # domifaddr f20 eth1 --source lease Name MAC address Protocol Address ------------------------------------------------------------------------------- vnet1 52:54:00:b1:70:19 ipv4 192.168.105.201/16 - - ipv4 192.168.201.195/16 - - ipv6 fe80::5054:ff:feb1:7019/64 virsh # domifaddr f20 eth0 --source agent --full Name MAC address Protocol Address ------------------------------------------------------------------------------- eth0 52:54:00:2e:45:ce ipv4 10.1.33.188/24 eth0 52:54:00:2e:45:ce ipv6 2001:db8:0:f101::2/64 eth0 52:54:00:2e:45:ce ipv6 fe80::5054:ff:fe2e:45ce/64 tools/virsh.pod * Document new command Signed-off-by: Nehal J Wani <nehaljw.kkd1> commit 0977b8aa071de550e1a013d35e2c72615e65d520 Author: Nehal J Wani <nehaljw.kkd1> AuthorDate: Mon Jan 26 00:08:48 2015 +0530 Commit: Daniel P. Berrange <berrange> CommitDate: Tue Mar 17 15:15:38 2015 +0000 domifaddr: Implement the API for qemu By querying the qemu guest agent with the QMP command "guest-network-get-interfaces" and converting the received JSON output to structured objects. Although "ifconfig" is deprecated, IP aliases created by "ifconfig" are supported by this API. The legacy syntax of an IP alias is: "<ifname>:<alias-name>". Since we want all aliases to be clubbed under parent interface, simply stripping ":<alias-name>" suffices. Note that IP aliases formed by "ip" aren't visible to "ifconfig", and aliases created by "ip" do not have any specific name. But we are lucky, as qemu guest agent detects aliases created by both. src/qemu/qemu_agent.h: * Define qemuAgentGetInterfaces src/qemu/qemu_agent.c: * Implement qemuAgentGetInterface src/qemu/qemu_driver.c: * New function qemuGetDHCPInterfaces * New function qemuDomainInterfaceAddresses src/remote_protocol-sructs: * Define new structs tests/qemuagenttest.c: * Add new test: testQemuAgentGetInterfaces Test cases for IP aliases, 0 or multiple ipv4/ipv6 address(es) Signed-off-by: Nehal J Wani <nehaljw.kkd1> commit 71546d1798fc6ae4a55acf1b63f33d37ec71ba3e Author: Nehal J Wani <nehaljw.kkd1> AuthorDate: Mon Jan 26 00:08:47 2015 +0530 Commit: Daniel P. Berrange <berrange> CommitDate: Tue Mar 17 15:15:38 2015 +0000 domifaddr: Implement the remote protocol daemon/remote.c * Define remoteSerializeDomainInterface, remoteDispatchDomainInterfaceAddresses src/remote/remote_driver.c * Define remoteDomainInterfaceAddresses src/remote/remote_protocol.x * New RPC procedure: REMOTE_PROC_DOMAIN_INTERFACE_ADDRESSES * Define structs remote_domain_ip_addr, remote_domain_interface, remote_domain_interfaces_addresse_args, remote_domain_interface_addresses_ret * Introduce upper bounds (to handle DoS attacks): REMOTE_DOMAIN_INTERFACE_MAX = 2048 REMOTE_DOMAIN_IP_ADDR_MAX = 2048 Restrictions on the maximum number of aliases per interface were removed after kernel v2.0, and theoretically, at present, there are no upper limits on number of interfaces per virtual machine and on the number of IP addresses per interface. src/remote_protocol-structs * New structs added Signed-off-by: Nehal J Wani <nehaljw.kkd1> commit 5b5242a7cba7a851c748e1c8645e5a564ad867b0 Author: Nehal J Wani <nehaljw.kkd1> AuthorDate: Mon Jan 26 00:08:46 2015 +0530 Commit: Daniel P. Berrange <berrange> CommitDate: Tue Mar 17 15:15:38 2015 +0000 domifaddr: Implement the public APIs Define helper function virDomainInterfaceFree, which allows the upper layer application to free the domain interface object conveniently. The API is going to provide multiple methods by flags, e.g. * Query guest agent * Parse DHCP lease file include/libvirt/libvirt-domain.h * Define virDomainInterfaceAddresses, virDomainInterfaceFree * Define structs virDomainInterface, virDomainIPAddress src/driver-hypervisor.h: * Define domainInterfaceAddresses src/libvirt-domain.c: * Implement virDomainInterfaceAddresses * Implement virDomainInterfaceFree src/libvirt_public.syms: * Export the new symbols Signed-off-by: Nehal J Wani <nehaljw.kkd1> $ git describe --contains 2f36e6944e6eb56a00e19fcd85ec8513461597c9 v1.2.14-rc1~118