5:44 a.m.
Lin Ma (2):
qemu: Remove network type limitation for qemuARPGetInterfaces
virarptable: Return a virArpTablePtr when the nlmsghdr for loop is
over
src/qemu/qemu_driver.c | 3 ---
src/util/virarptable.c | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
--
2.16.2
5:44 a.m.
New subject: [libvirt] [PATCH 1/2] qemu: Remove network type limitation for qemuARPGetInterfaces
When we call qemuARPGetInterfaces to get IP from host's arp table, The
iface's type has nothing to do with it, We should allow all of type.
Signed-off-by: Lin Ma <lma(a)suse.com>
---
src/qemu/qemu_driver.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 2f8d6915e1..c2abecf81d 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -20940,9 +20940,6 @@ qemuARPGetInterfaces(virDomainObjPtr vm,
goto cleanup;
for (i = 0; i < vm->def->nnets; i++) {
- if (vm->def->nets[i]->type != VIR_DOMAIN_NET_TYPE_NETWORK)
- continue;
-
virMacAddrFormat(&(vm->def->nets[i]->mac), macaddr);
for (j = 0; j < table->n; j++) {
virArpTableEntry entry = table->t[j];
--
2.16.2
2:55 p.m.
New subject: [libvirt] [PATCH 1/2] qemu: Remove network type limitation for qemuARPGetInterfaces
At 2018-09-07 18:44:53, "Lin Ma" <lma(a)suse.com> wrote:
When we call qemuARPGetInterfaces to get IP from host's arp table,
The
iface's type has nothing to do with it, We should allow all of type.
Signed-off-by: Lin Ma <lma(a)suse.com>
Hi,
with my limited tests,
we can't get useful info by arp query from other kind of interface types.
Regards,
- Chen
12:51 a.m.
New subject: [libvirt] [PATCH 1/2] qemu: Remove network type limitation for qemuARPGetInterfaces
On 09/10/2018 02:55 PM, Chen Hanxiao wrote:
At 2018-09-07 18:44:53, "Lin Ma" <lma(a)suse.com>
wrote:
>When we call qemuARPGetInterfaces to get IP from host's arp table, The
>iface's type has nothing to do with it, We should allow all of type.
>
>Signed-off-by: Lin Ma <lma(a)suse.com>
Hi,
with my limited tests,
we can't get useful info by arp query from other kind of interface types.
IMO, As long as the host interface and the guest interface communicated
through osi layer3 or above, Host kernel will maintaince the corresponding
ip <-> macentry in arp able.
What you mentioned above remind me one thing: I forgot to mention that
if the switch doesn't support hairpin mode, thenthe virtual interfaces
which backend is mactap can't communicate withhost, that means the host
arp table won't include the ip <-> mac information of suchvirtual
interfaces.
Inthis case, the qemuARPGetInterfaces can't get IP.
So I'd like to change the code to only ignore VIR_DOMAIN_NET_TYPE_DIRECT
in patch V2, For anyelsenet types, the code will iterate the arp table for
loopto try to search if there is a matched entry.
what do you think?
Thanks,
Lin
11:55 p.m.
New subject: [libvirt] [PATCH 1/2] qemu: Remove network type limitation for qemuARPGetInterfaces
At 2018-09-11 13:51:43, "Lin Ma" <lma(a)suse.com> wrote:
On 09/10/2018 02:55 PM, Chen Hanxiao wrote:
At 2018-09-07 18:44:53, "Lin Ma" <lma(a)suse.com> wrote:
>When we call qemuARPGetInterfaces to get IP from host's arp table, The
>iface's type has nothing to do with it, We should allow all of type.
>
>Signed-off-by: Lin Ma <lma(a)suse.com>
Hi,
with my limited tests,
we can't get useful info by arp query from other kind of interface types.
IMO, As long as the host interface and the guest interface
communicated
through osi layer3 or above, Host kernel will maintaince
the corresponding
ip <-> mac entry in arp able.
A lot of network backend, such as vrouter, dpdk, the package from guest os
did not come back to the host's protocol stack.
We can't see them in host's arp table.
What you mentioned above remind me one thing: I forgot to
mention that
if the switch doesn't support hairpin mode, then the
virtual interfaces
which backend is mactap can't communicate with host,
that means the host
arp table won't include the ip <-> mac information
of such virtual interfaces.
In this case, the qemuARPGetInterfaces
can't get IP.
So I'd like to change the code to only ignore
VIR_DOMAIN_NET_TYPE_DIRECT
Maybe adding VIR_DOMAIN_NET_TYPE_ETHERNET and VIR_DOMAIN_NET_TYPE_VHOSTUSER?
Regards,
- Chen
in patch V2, For anyelse net types, the
code will iterate the arp table for
loop to try to search if there is a
matched entry.
what do you think?
Thanks,
Lin
5:44 a.m.
New subject: [libvirt] [PATCH 2/2] virarptable: Return a virArpTablePtr when the nlmsghdr for loop is over
commit b00c9c39 removed the label end_of_netlink_messages and 'return
table' statement, It causes the function virArpTableGet doesn't return
a proper virArpTable pointer.
How to reproduce:
# virsh domiflist sles12sp3
Interface Type Source Model MAC
-------------------------------------------------------
vnet0 network default virtio 52:54:00:cd:02:e6
# virsh domifaddr sles12sp3 --source arp
error: Failed to query for interfaces addresses
error: An error occurred, but the cause is unknown
It seems that the "if (nh->nlmsg_type == NLMSG_DONE)" statement won't be
meted. So this patch adds 'return table' when the iterations of nlmsghdr
for loop is over.
Signed-off-by: Lin Ma <lma(a)suse.com>
---
src/util/virarptable.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/util/virarptable.c b/src/util/virarptable.c
index 04a6f35571..217a960d5a 100644
--- a/src/util/virarptable.c
+++ b/src/util/virarptable.c
@@ -152,6 +152,8 @@ virArpTableGet(void)
}
}
+ return table;
+
cleanup:
virArpTableFree(table);
return NULL;
--
2.16.2
2:26 p.m.
New subject: [libvirt] [PATCH 2/2] virarptable: Return a virArpTablePtr when the nlmsghdr for loop is over
At 2018-09-07 18:44:54, "Lin Ma" <lma(a)suse.com> wrote:
commit b00c9c39 removed the label end_of_netlink_messages and
'return
table' statement, It causes the function virArpTableGet doesn't return
a proper virArpTable pointer.
How to reproduce:
# virsh domiflist sles12sp3
Interface Type Source Model MAC
-------------------------------------------------------
vnet0 network default virtio 52:54:00:cd:02:e6
# virsh domifaddr sles12sp3 --source arp
error: Failed to query for interfaces addresses
error: An error occurred, but the cause is unknown
It seems that the "if (nh->nlmsg_type == NLMSG_DONE)" statement won't be
meted. So this patch adds 'return table' when the iterations of nlmsghdr
for loop is over.
Signed-off-by: Lin Ma <lma(a)suse.com>
---
It seemed that the cleanup series delete our return value.
Reviewed-by: Chen Hanxiao <chenhanxiao(a)gmail.com>
Regards,
- Chen
2300
days inactive
2305
days old
6 comments
2 participants
participants (2)
-
Chen Hanxiao -
Lin Ma