[libvirt] [PATCH] Add V6LOCAL parameter to nwfilter rules.
by Brian Rak
Currently, adding any sort of IPv6 nwfilter rules is rather difficult. There are no standard rules,
and you end up doing a lot of things by hand. This patch makes the $V6LOCAL variable available within
rules. This is the generated from the interface's mac address using the modified EUI-64 format, which
matches what the guest should be using.
This is part of what information is needed to correctly filter guest IPv6 traffic. Since this changes
with the MAC address, it is significantly easier if libvirt populates it (rather then requring the
user to enter it)
---
docs/formatnwfilter.html.in | 9 ++++++---
src/conf/nwfilter_params.h | 1 +
src/nwfilter/nwfilter_gentech_driver.c | 23 +++++++++++++++++++++++
3 files changed, 30 insertions(+), 3 deletions(-)
mode change 100644 => 100755 src/nwfilter/nwfilter_gentech_driver.c
diff --git a/docs/formatnwfilter.html.in b/docs/formatnwfilter.html.in
index 45b97f7..aa1ff9f 100644
--- a/docs/formatnwfilter.html.in
+++ b/docs/formatnwfilter.html.in
@@ -239,9 +239,9 @@
<h3><a name="nwfconceptsvars">Usage of variables in filters</a></h3>
<p>
- Two variables names have so far been reserved for usage by the
- network traffic filtering subsystem: <code>MAC</code> and
- <code>IP</code>.
+ Three variables names have so far been reserved for usage by the
+ network traffic filtering subsystem: <code>MAC</code>,
+ <code>IP</code>, and <code>V6LOCAL</code>
<br/><br/>
<code>MAC</code> is the MAC address of the
network interface. A filtering rule that references this variable
@@ -251,6 +251,9 @@
parameter similar to the IP parameter above, it is discouraged
since libvirt knows what MAC address an interface will be using.
<br/><br/>
+ <code>V6LOCAL</code> is the computed IPv6 link-local address.
+ This is based on the MAC variable
+ <br/><br/>
The parameter <code>IP</code> represents the IP address
that the operating system inside the virtual machine is expected
to use on the given interface. The <code>IP</code> parameter
diff --git a/src/conf/nwfilter_params.h b/src/conf/nwfilter_params.h
index 5e9777b..f61250f 100644
--- a/src/conf/nwfilter_params.h
+++ b/src/conf/nwfilter_params.h
@@ -98,6 +98,7 @@ bool virNWFilterHashTableEqual(virNWFilterHashTablePtr a,
# define NWFILTER_VARNAME_IP "IP"
# define NWFILTER_VARNAME_MAC "MAC"
+# define NWFILTER_VARNAME_V6LOCAL "V6LOCAL"
# define NWFILTER_VARNAME_CTRL_IP_LEARNING "CTRL_IP_LEARNING"
# define NWFILTER_VARNAME_DHCPSERVER "DHCPSERVER"
diff --git a/src/nwfilter/nwfilter_gentech_driver.c b/src/nwfilter/nwfilter_gentech_driver.c
old mode 100644
new mode 100755
index 1ce5e70..a86dae8
--- a/src/nwfilter/nwfilter_gentech_driver.c
+++ b/src/nwfilter/nwfilter_gentech_driver.c
@@ -45,6 +45,7 @@ VIR_LOG_INIT("nwfilter.nwfilter_gentech_driver");
#define NWFILTER_STD_VAR_MAC NWFILTER_VARNAME_MAC
#define NWFILTER_STD_VAR_IP NWFILTER_VARNAME_IP
+#define NWFILTER_STD_VAR_V6LOCAL NWFILTER_VARNAME_V6LOCAL
#define NWFILTER_DFLT_LEARN "any"
@@ -163,6 +164,28 @@ virNWFilterVarHashmapAddStdValues(virNWFilterHashTablePtr table,
"%s", _("Could not add variable 'MAC' to hashmap"));
return -1;
}
+
+ virMacAddr parsedMac;
+ if (virMacAddrParse(macaddr, &parsedMac) == 0)
+ {
+ parsedMac.addr[0] ^= 2;
+
+ char euiMacAddr[26];
+ snprintf(euiMacAddr, sizeof(euiMacAddr), "fe80::%x%x:%xff:fe%x:%x%x", parsedMac.addr[0], parsedMac.addr[1], parsedMac.addr[2],
+ parsedMac.addr[3], parsedMac.addr[4], parsedMac.addr[5]);
+
+ val = virNWFilterVarValueCreateSimpleCopyValue(euiMacAddr);
+ if (!val)
+ return -1;
+
+ if (virHashAddEntry(table->hashTable,
+ NWFILTER_STD_VAR_V6LOCAL,
+ val) < 0) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ "%s", _("Could not add variable 'V6LOCAL' to hashmap"));
+ return -1;
+ }
+ }
}
if (ipaddr) {
--
1.7.1
10 years, 7 months
[libvirt] Enhancing clean-traffic to work with IPv6
by Brian Rak
I'm looking into adding IPv6 support to the nwfilter clean-traffic
rules, but I'm unsure of the best approach to this. I'm planning on
sending patches once I get this correct, so I'm trying to figure out
what way fits in best.
There's a couple different ways I can think of:
1) Explicitly add v6 rules to the existing clean-traffic rules. This
would enable IPv6 for guests whenever libvirt was upgraded, which may be
a problem.
2) Add another filter chain (clean-ipv6-traffic) that would do the same
thing as clean-traffic, just for IPv6
3) Add another filter chain (clean-ipv6-ipv4-traffic), that would clean
IPv6 traffic, and include the clean-traffic filter set
The limitation here is that IP learning will not work for IPv6, so
actually using IPv6 is going to require passing in parameters to filter
specifying what ranges the guest should be allowed to use. I think this
rules out #1.
Any suggestions?
10 years, 7 months
[libvirt] libxl fixes/improvements for libvirt
by Stefan Bader
Here several changes which improve the handling of Xen for me:
* 0001-libxl-Use-id-from-virDomainObj-inside-the-driver.patch
This is a re-send as I initially submitted that as a reply to some
discussion. Starting from the visibly broken libxlDomainGetInfo when
creating or rebooting a guest with virt-manager, I replaced all usage
of dom->id with the more stable vm->def->id.
* 0002-libxl-Set-disk-format-for-empty-cdrom-device.patch
Fixes start of a guest after ejecting the iso image from a virtual
CDROM drive (again using virt-manager).
* 0003-libxl-Implement-basic-video-device-selection.patch
Should fix the occasional disagreement about the used VNC port and
adds the ability to select the standard VGA graphics from Xen.
VRAM size seemed to work with that. Only for Cirrus, while the qemu
command-line looks good, ones seems to end up with 32M.
Note to people on the Xen list: I wonder whether libxenlight internally
should somehow should fix up the situation where a caller sets up the
video devices in the vfbs list but does not sync that with the information
in the build info. Question probably is what the semantics should be.
-Stefan
10 years, 7 months
[libvirt] [PATCH 0/7] Some vshCommandOpt rework
by Michal Privoznik
*** BLURB HERE ***
Michal Privoznik (7):
virsh: Make vshCommandOpt* report error
virsh-domain: Adapt to new error reporting
virsh-domain-monitor: Adapt to new error reporting
virsh-host: Adapt to new error reporting
virsh-interface: Adapt to new error reporting
virsh-network: Adapt to new error reporting
virsh-volume: Adapt to new error reporting
tests/vcpupin | 2 +-
tools/virsh-domain-monitor.c | 5 +--
tools/virsh-domain.c | 75 ++++++++++++++------------------------------
tools/virsh-host.c | 19 +++--------
tools/virsh-interface.c | 4 +--
tools/virsh-network.c | 4 +--
tools/virsh-volume.c | 16 +++-------
tools/virsh.c | 72 +++++++++++++++++++++++++++++++++++++-----
tools/virsh.h | 2 +-
9 files changed, 102 insertions(+), 97 deletions(-)
--
1.9.0
10 years, 7 months
[libvirt] [PATCH v2] Add V6LOCAL nwfilter parameter.
by Brian Rak
Currently, adding any sort of IPv6 nwfilter rules is rather difficult.
There are no standard rules, and you end up doing a lot of things by
hand. This patch makes the $V6LOCAL variable available within nwfilter
nules. This is the generated from the interface's mac address using
the modified EUI-64 format, which matches what the guest should be
using.
This is part of what information is needed to correctly filter guest
IPv6 traffic. Since this changes with the MAC address, it is
significantly easier if libvirt populates it (rather then requiring the
user to enter it).
As an example, an interface with a MAC address of "12:34:45:46:23:41"
would have a V6LOCAL value of "fe80::1034:45ff:fe46:2341"
---
docs/formatnwfilter.html.in | 11 ++++++++---
src/conf/nwfilter_params.h | 1 +
src/nwfilter/nwfilter_gentech_driver.c | 25 +++++++++++++++++++++++++
3 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/docs/formatnwfilter.html.in b/docs/formatnwfilter.html.in
index 45b97f7..4f10884 100644
--- a/docs/formatnwfilter.html.in
+++ b/docs/formatnwfilter.html.in
@@ -239,9 +239,9 @@
<h3><a name="nwfconceptsvars">Usage of variables in filters</a></h3>
<p>
- Two variables names have so far been reserved for usage by the
- network traffic filtering subsystem: <code>MAC</code> and
- <code>IP</code>.
+ Three variables names have so far been reserved for usage by the
+ network traffic filtering subsystem: <code>MAC</code>,
+ <code>IP</code>, and <code>V6LOCAL</code> (since 1.2.4).
<br/><br/>
<code>MAC</code> is the MAC address of the
network interface. A filtering rule that references this variable
@@ -251,6 +251,11 @@
parameter similar to the IP parameter above, it is discouraged
since libvirt knows what MAC address an interface will be using.
<br/><br/>
+ <code>V6LOCAL</code> is the computed IPv6 link-local address.
+ This is based on the MAC address of the interface. As an example,
+ a MAC address of <code>12:34:45:46:23:41</code> would result in a
+ link local address of <code>fe80::1034:45ff:fe46:2341</code>.
+ <br/><br/>
The parameter <code>IP</code> represents the IP address
that the operating system inside the virtual machine is expected
to use on the given interface. The <code>IP</code> parameter
diff --git a/src/conf/nwfilter_params.h b/src/conf/nwfilter_params.h
index 5e9777b..f61250f 100644
--- a/src/conf/nwfilter_params.h
+++ b/src/conf/nwfilter_params.h
@@ -98,6 +98,7 @@ bool virNWFilterHashTableEqual(virNWFilterHashTablePtr a,
# define NWFILTER_VARNAME_IP "IP"
# define NWFILTER_VARNAME_MAC "MAC"
+# define NWFILTER_VARNAME_V6LOCAL "V6LOCAL"
# define NWFILTER_VARNAME_CTRL_IP_LEARNING "CTRL_IP_LEARNING"
# define NWFILTER_VARNAME_DHCPSERVER "DHCPSERVER"
diff --git a/src/nwfilter/nwfilter_gentech_driver.c b/src/nwfilter/nwfilter_gentech_driver.c
index 1ce5e70..c58df1c 100644
--- a/src/nwfilter/nwfilter_gentech_driver.c
+++ b/src/nwfilter/nwfilter_gentech_driver.c
@@ -45,6 +45,7 @@ VIR_LOG_INIT("nwfilter.nwfilter_gentech_driver");
#define NWFILTER_STD_VAR_MAC NWFILTER_VARNAME_MAC
#define NWFILTER_STD_VAR_IP NWFILTER_VARNAME_IP
+#define NWFILTER_STD_VAR_V6LOCAL NWFILTER_VARNAME_V6LOCAL
#define NWFILTER_DFLT_LEARN "any"
@@ -163,6 +164,30 @@ virNWFilterVarHashmapAddStdValues(virNWFilterHashTablePtr table,
"%s", _("Could not add variable 'MAC' to hashmap"));
return -1;
}
+
+ virMacAddr parsedMac;
+ if (virMacAddrParse(macaddr, &parsedMac) == 0) {
+ parsedMac.addr[0] ^= 2;
+
+ char euiMacAddr[26];
+ snprintf(euiMacAddr, sizeof(euiMacAddr),
+ "fe80::%02x%02x:%02xff:fe%02x:%02x%02x", parsedMac.addr[0],
+ parsedMac.addr[1], parsedMac.addr[2], parsedMac.addr[3],
+ parsedMac.addr[4], parsedMac.addr[5]);
+
+ val = virNWFilterVarValueCreateSimpleCopyValue(euiMacAddr);
+ if (!val)
+ return -1;
+
+ if (virHashAddEntry(table->hashTable,
+ NWFILTER_STD_VAR_V6LOCAL,
+ val) < 0) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ "%s", _("Could not add variable 'V6LOCAL' "
+ "to hashmap"));
+ return -1;
+ }
+ }
}
if (ipaddr) {
--
1.7.1
10 years, 7 months
[libvirt] [PATCH] Define CPUINFO_FILE_LEN and fix maxlen of cpuinfo file for powerpc
by Olivia Yin
This patch define CPUINFO_FILE_LEN as 2KB which is enough for most architectures.
For the 24 cores PowerPC machines, the file of /proc/cpuinfo will be larger than 2KB.
It will fail to start libvirtd with the error message as below:
virFileReadAll: Failed to read file '/proc/cpuinfo': Value too large for defined data type
virSysinfoRead: internal error Failed to open /proc/cpuinfo
So this patch increases the maxlen of cpuinfo for PowerPC architecture.
Signed-off-by: Olivia Yin <Hong-Hua.Yin(a)freescale.com>
---
src/util/virsysinfo.c | 6 +++---
src/util/virsysinfo.h | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c
index 7b16157..33c4bc6 100644
--- a/src/util/virsysinfo.c
+++ b/src/util/virsysinfo.c
@@ -223,7 +223,7 @@ virSysinfoRead(void)
if (VIR_ALLOC(ret) < 0)
goto no_memory;
- if (virFileReadAll(CPUINFO, 2048, &outbuf) < 0) {
+ if (virFileReadAll(CPUINFO, 2 * CPUINFO_FILE_LEN, &outbuf) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to open %s"), CPUINFO);
return NULL;
@@ -341,7 +341,7 @@ virSysinfoRead(void)
if (VIR_ALLOC(ret) < 0)
goto no_memory;
- if (virFileReadAll(CPUINFO, 2048, &outbuf) < 0) {
+ if (virFileReadAll(CPUINFO, CPUINFO_FILE_LEN, &outbuf) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to open %s"), CPUINFO);
return NULL;
@@ -470,7 +470,7 @@ virSysinfoRead(void)
goto no_memory;
/* Gather info from /proc/cpuinfo */
- if (virFileReadAll(CPUINFO, 8192, &outbuf) < 0) {
+ if (virFileReadAll(CPUINFO, 4 * CPUINFO_FILE_LEN, &outbuf) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to open %s"), CPUINFO);
return NULL;
diff --git a/src/util/virsysinfo.h b/src/util/virsysinfo.h
index fbb505b..630b9ce 100644
--- a/src/util/virsysinfo.h
+++ b/src/util/virsysinfo.h
@@ -102,4 +102,6 @@ bool virSysinfoIsEqual(virSysinfoDefPtr src,
VIR_ENUM_DECL(virSysinfo)
+#define CPUINFO_FILE_LEN 2048 /*2KB limit for normal cpuinfo file*/
+
#endif /* __VIR_SYSINFOS_H__ */
--
1.8.5
10 years, 7 months
[libvirt] [PATCH] virsh: Fix help info of net-event and event command
by liyang
From: Li Yang <liyang.fnst(a)cn.fujitsu.com>
For now the help informatin of net-event and event like this:
[root@localhost qemu]# virsh help net-event
NAME
net-event - (null)
...
[root@localhost qemu]# virsh help event
NAME
event - (null)
...
Now fixed them, make them show correct information
instead of 'null'.
Signed-off-by: Li Yang <liyang.fnst(a)cn.fujitsu.com>
---
tools/virsh-domain.c | 2 +-
tools/virsh-network.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index f2856a5..310b5dc 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -11030,7 +11030,7 @@ static vshEventCallback vshEventCallbacks[] = {
verify(VIR_DOMAIN_EVENT_ID_LAST == ARRAY_CARDINALITY(vshEventCallbacks));
static const vshCmdInfo info_event[] = {
- {.name = "event",
+ {.name = "help",
.data = N_("Domain Events")
},
{.name = "desc",
diff --git a/tools/virsh-network.c b/tools/virsh-network.c
index 22d21e7..338db28 100644
--- a/tools/virsh-network.c
+++ b/tools/virsh-network.c
@@ -1180,7 +1180,7 @@ vshEventLifecyclePrint(virConnectPtr conn ATTRIBUTE_UNUSED,
}
static const vshCmdInfo info_network_event[] = {
- {.name = "net-event",
+ {.name = "help",
.data = N_("Network Events")
},
{.name = "desc",
--
1.7.1
10 years, 7 months
[libvirt] [PATCH] Fix Memory Leak in daemon/libvirtd.c
by Nehal J Wani
Fixes leak introduced by e562e82f
==4937== 64 bytes in 1 blocks are definitely lost in loss record 270 of 405
==4937== at 0x4A06BE0: realloc (vg_replace_malloc.c:662)
==4937== by 0x6FA41C4: __vasprintf_chk (vasprintf_chk.c:90)
==4937== by 0x50C8D29: virVasprintfInternal (stdio2.h:199)
==4937== by 0x50C8E3A: virAsprintfInternal (virstring.c:362)
==4937== by 0x11D01A: main (libvirtd.c:1170)
---
daemon/libvirtd.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index e247259..bb84c90 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -1132,6 +1132,7 @@ int main(int argc, char **argv) {
bool privileged = geteuid() == 0 ? true : false;
bool implicit_conf = false;
char *run_dir = NULL;
+ char *cpumap = NULL;
mode_t old_umask;
struct option opts[] = {
@@ -1159,7 +1160,6 @@ int main(int argc, char **argv) {
if (strstr(argv[0], "lt-libvirtd") ||
strstr(argv[0], "/daemon/.libs/libvirtd")) {
char *tmp = strrchr(argv[0], '/');
- char *cpumap;
if (!tmp) {
fprintf(stderr, _("%s: cannot identify driver directory\n"), argv[0]);
exit(EXIT_FAILURE);
@@ -1182,6 +1182,7 @@ int main(int argc, char **argv) {
virDriverModuleInitialize(driverdir);
#endif
cpuMapOverride(cpumap);
+ VIR_FREE(cpumap);
*tmp = '/';
/* Must not free 'driverdir' - it is still used */
}
--
1.7.1
10 years, 7 months
[libvirt] [PATCH v2] Define CPUINFO_FILE_LEN and fix maxlen of cpuinfo file for all uses
by Olivia Yin
For example, the file /proc/cpuinfo for 24 cores PowerPC platform is larger than
the previous maximum size 2KB.
It will fail to start libvirtd with the error message as below:
virFileReadAll: Failed to read file '/proc/cpuinfo': Value too large for defined
data type
virSysinfoRead: internal error Failed to open /proc/cpuinfo
This patch defines CPUINFO_FILE_LEN as 10KB which is enough for most architectures.
Signed-off-by: Olivia Yin <Hong-Hua.Yin(a)freescale.com>
---
src/util/virsysinfo.c | 6 +++---
src/util/virsysinfo.h | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c
index 7b16157..873872c 100644
--- a/src/util/virsysinfo.c
+++ b/src/util/virsysinfo.c
@@ -223,7 +223,7 @@ virSysinfoRead(void)
if (VIR_ALLOC(ret) < 0)
goto no_memory;
- if (virFileReadAll(CPUINFO, 2048, &outbuf) < 0) {
+ if (virFileReadAll(CPUINFO, CPUINFO_FILE_LEN, &outbuf) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to open %s"), CPUINFO);
return NULL;
@@ -341,7 +341,7 @@ virSysinfoRead(void)
if (VIR_ALLOC(ret) < 0)
goto no_memory;
- if (virFileReadAll(CPUINFO, 2048, &outbuf) < 0) {
+ if (virFileReadAll(CPUINFO, CPUINFO_FILE_LEN, &outbuf) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to open %s"), CPUINFO);
return NULL;
@@ -470,7 +470,7 @@ virSysinfoRead(void)
goto no_memory;
/* Gather info from /proc/cpuinfo */
- if (virFileReadAll(CPUINFO, 8192, &outbuf) < 0) {
+ if (virFileReadAll(CPUINFO, CPUINFO_FILE_LEN, &outbuf) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to open %s"), CPUINFO);
return NULL;
diff --git a/src/util/virsysinfo.h b/src/util/virsysinfo.h
index fbb505b..b5336e2 100644
--- a/src/util/virsysinfo.h
+++ b/src/util/virsysinfo.h
@@ -102,4 +102,6 @@ bool virSysinfoIsEqual(virSysinfoDefPtr src,
VIR_ENUM_DECL(virSysinfo)
+#define CPUINFO_FILE_LEN (10*1024) /*10KB limit for /proc/cpuinfo file*/
+
#endif /* __VIR_SYSINFOS_H__ */
--
1.8.5
10 years, 7 months
[libvirt] libxl: Issues with virt-manager when used to manager Xen domains
by Stefan Bader
This started off with some regression testing after going forward to Xen-4.4. We
currently would pair that with a libvirt version 1.2.2 and right now operations
through virsh seem to be working (mostly) well. But when using virt-manager (not
the most up-to-date versions but some combinations that quite likely will occur
(0.9.1 and 0.9.5)) there are some issues.
Two symptoms seem to be caused by the same underlying problem which is caused by
the way virt-manager interacts with libvirt. That seems to be that virt-manager
acquires a reference to virDomainPtr only once and then uses that for subsequent
call. This is a problem because both virDomainPtr object and virDomainObjPtr
objects contains a domid but only the latter gets updated.
So both, creating a new guest (which must be a define step and then use the
handle to start the guest) as well as rebooting a guest cause problems for
virt-manager. Mainly because of libxlDomainGetInfo() which retrieves the
virDomainObjPtr for a given virDommainPtr. Then checks the domain object to be
active or not but uses the domid from the domain to call into libxl:
if (!(vm = libxlDomObjFromDomain(dom)))
goto cleanup;
...
if (!virDomainObjIsActive(vm)) {
info->cpuTime = 0;
info->memory = vm->def->mem.cur_balloon;
info->maxMem = vm->def->mem.max_balloon;
} else {
if (libxl_domain_info(priv->ctx, &d_info, dom->id) != 0) {
This fails either with dom->id being -1 (still) or using the old id from before
the reboot. A dirty hack seems to avoid this:
static virDomainObjPtr
libxlDomObjFromDomain(virDomainPtr dom)
{
virDomainObjPtr vm;
libxlDriverPrivatePtr driver = dom->conn->privateData;
char uuidstr[VIR_UUID_STRING_BUFLEN];
vm = virDomainObjListFindByUUID(driver->domains, dom->uuid);
if (!vm) {
virUUIDFormat(dom->uuid, uuidstr);
virReportError(VIR_ERR_NO_DOMAIN,
_("no domain with matching uuid '%s' (%s)"),
uuidstr, dom->name);
return NULL;
- }
+ } else {
+ if (dom->id != vm->def->id) {
+ VIR_WARN("libxlDomObjFromDomain: domid changed (%d->%d)",
+ dom->id, vm->def->id);
+ dom->id = vm->def->id;
+ }
+ }
return vm;
}
Not really sure this is the right way to go. Also because that warning above
happens a lot more (repeatedly) than I would have expected. This may or may not
be related to the next question.
Not a problem but more a confusion on my side: virGetDomain() has commentary
that says it will return either a pointer to an existing object or one to a new
one. Its just, I cannot see that done in the code. Is that a future plan or was
that way but was removed?
I must admit I have not looked deeper into that but one explanation of the
repeated domid mismatch would be if the virDomainPtr that virt-manager uses to
communicate with libvirt would be cloned before doing things inside libvirt. And
holding that handle for so long and not obtaining a fresh one through the
various lookup interfaces each time could be a mistake of virt-manager.
Unfortunately one that needs to be handled in some way.
-Stefan
10 years, 7 months
