Description of problem: Via Webadmin I can see the ovirt-guest-agent data. e.g.: logged in user, IPv4 and IPv6 addresses etc. It would be cool if this could be accessed via REST-API too. Currently you can just access other events like disk hotplug vm start and shutdown etc. Version-Release number of selected component (if applicable): I and Itamar found no way to access this via API / SDK How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: you can't access ovirt-guest-agent data via API /SDK Expected results: get the same data you get via webadmin Additional info:
there is <xs:complexType name="GuestInfo"> <xs:sequence> <xs:element ref="ips" minOccurs="0" maxOccurs="1"/> <xs:element name="fqdn" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> missing logged-in user relevant thread: http://lists.ovirt.org/pipermail/users/2014-January/019827.html
Hi, I can not find this information in the rsdl.xml from ovirt 3.3.2. To which version do you refer? Is this 3.4. stuff? If this part is implemented already it should be relatively easy to provide the missing information. But again, I can not see it in 3.3.2. (grepped for GuestInfo" and "fqdn" both zero hits).
The RSDL document doesn't describe the content of the resources, only the parameters of the actions. For the content of the resources it only contains references to the types defined in the XML schema. For example, for a VM you will get the following description of the GET: <link href="/api/vms/{vm:id}" rel="get"> ... <response> <type>VM</type> </response> </link> This is telling you that the response is defined by the "VM" type defined in the XML schema. The description that Michal is including is coming from that XML schema. You can get it from https://whatever/api?shema . This is an example, from my environment: <guest_info> <ips> <ip address="192.168.122.30"/> </ips> <fqdn>whatever.example.com</fqdn> </guest_info> Additional information provided by the guest agent is available in the "applications" /vms/{vm:id}/applications collection, for example: <applications> <application href="..." id="..."> <name>rhevm-guest-agent-common-1.0.8-6.el6ev</name> <vm href="..." id="..."/> </application> <application href="..." id="..."> <name>kernel-2.6.32-358.el6</name> <vm href="..." id="..."/> </application> </applications> The logged in user isn't yet available.
We have a bug 894027 open for adding the logged in user. Can we close this bug as duplicate?
(In reply to Juan Hernández from comment #4) oh, totally missed that. I believe so. We should give it a priority as this is taking way too long
well okay, that bug tracks the logged in user stuff. but what about the ip address information? we have vms with multiple configured IPv6 addresses and Ipv4 addresses in BZ894027 I just see <client_ip>ip</client_ip> which seems to just report a single IP instead of all IPs? I suggest than to track the inclusion of logged in users in BZ894027 and use this BZ1055556 to track integration of all IPv4 and IPv6 addresses via API. Thank you!
The IP addresses are already supported, even multiple ones, see this example from my environment: <guest_info> <ips> <ip address="192.168.122.30"/> </ips> <fqdn>whatever.example.com</fqdn> </guest_info> This works for IPv4, not sure about IPv6. From the backend and RESTAPI point of view the IPs are just strings, so it shouldn't be a problem. Michal, can you comment on that?
I'm sorry, but I don't find where I can get this part of the API response: This is an example, from my environment: <guest_info> <ips> <ip address="192.168.122.30"/> </ips> <fqdn>whatever.example.com</fqdn> </guest_info> I don't have it under any sub relations under https://myhost/api/vms/{:id}/ ? Are you sure this is in 3.3.2? If so, please point me in the right direction. I'm able to find the guestinfo stuff in the xml schema, but not the actual data in the api. I must be looking in the wrong direction. Thanks!
are you running the ovirt-guest-agent inside that VM? it does report multiple IPs, but it depends if the guest agent sees them correctly (on my env it does indeed works and I see more than 1). It should include ipv6 as well
It is embedded in the VM resource: <vm href="..." id="..."> ... <name>whatever</name> ... <guest_info> <ips> <ip address="192.168.122.30"/> </ips> <fqdn>whatever.example.com</fqdn> </guest_info> </vm> This information is only available if the VM is up, and if the guest agent is installed and running.
Sven, did you manage to find the IP information in the RESTAPI? Can we close this bug?
Sorry for the late reply. I can confirm that I see the IPv4 address, but none of the multiple configured IPv6 addresses. So this works just partly: The IPv6 addresses are missing, this would be a great enhancement!
Additional info: the multiple IPv6 addresses do show up in webadmin, so it should be relatively easy to provide this information also via api.
Ravi, can you please check why IPv6 addresses aren't included in the guest agent information provided by the API?
/api/vms/<vm-id>/nics should list the ipv6 address under reported devices, please let me know if this is sufficient <nics> <nic> ............. <reported_devices> <reported_device href="/api/vms/d026de8d-7aeb-410c-a299-801f882c1a71/reporteddevices/65746830-3030-3a31-613a-34613a62353a" id="65746830-3030-3a31-613a-34613a62353a"> <name>eth0</name> <description>guest reported data</description> <type>network</type> <mac address="00:1a:4a:b5:4c:94"/> <ips> <ip address="192.168.1.115" version="v4"/> <ip address="fe80::21a:4aff:feb5:4c94" version="v6"/> <ip address="::1:21a:4aff:feb5:4c94" version="v6"/> </ips> <vm href="/api/vms/d026de8d-7aeb-410c-a299-801f882c1a71" id="d026de8d-7aeb-410c-a299-801f882c1a71"/> </reported_device> </reported_devices> ......... </nic> </nics>
I can report that the needed info (all IPv4 and IPv6 addresses) is listed under the /api/vms/{vmid}/nics location. But to say the least, this is pretty cluttered, why is the guest_info under /api/vms/{vmid}/ just mentioning IPv4? At least this is inconsistent, /api/vms/{vmid}/ should provide one of the following: a) list all IPs (IPv4 & IPv6) b) list no IPs at all, because they are listed under /api/vms/{vmid}/nics I'm fine with each of the above, but not with the current implementation.
An additional idea that just came to my mind: it would be a cool feature if this information could be extended to include the default gateway and the subnetmask to. This would enable an easy way of monitoring the correct network configuration of vms.
(In reply to Sven Kieske from comment #16) > I can report that the needed info (all IPv4 and IPv6 addresses) > is listed under the /api/vms/{vmid}/nics location. > > But to say the least, this is pretty cluttered, why is the guest_info under > /api/vms/{vmid}/ just mentioning IPv4? > > At least this is inconsistent, /api/vms/{vmid}/ should provide one of the > following: > > a) list all IPs (IPv4 & IPv6) > > b) list no IPs at all, because they are listed under /api/vms/{vmid}/nics > > I'm fine with each of the above, but not with the current implementation. The reason for the differences relies in the order of extending the vm's reported data: At first, only the ipv4 on vm level was reported. IIRC, on ovirt-engine-32 the reported vm nic information feature was added [1]. The source of the ip on vm level is taken from the nic level if reported, however, for the sake of backward compatibility this field cannot be removed right away. I'm in favor of your second proposal to omit the ip field completely from the vm level, since they are reported from 2 levels: 1. /api/vms/{vm:id}/nics 2. /api/vms/{vm:id}/reporteddevices [1] http://www.ovirt.org/Feature/ReportingVnicInformation
(In reply to Sven Kieske from comment #17) > An additional idea that just came to my mind: > > it would be a cool feature if this information could be extended > to include the default gateway and the subnetmask to. > > This would enable an easy way of monitoring the correct network configuration > of vms. This information should be collected and propagated through the entire stack: guest-agent --> vdsm --> engine since currently (per ovirt-engine-3.4) it isn't reported in any level.
Removing the redundant information is something we should do, but due to backwards compatibility we can remove anything in 3.x. I have opened a bug 1060791 to track that removal in version 4.0. Adding the gateway and the netmask is probably something that can be considered for 3.5, I opened bug 1060793 for that. As this bug was about providing IPv6 addresses and that is already available I'm closing it.