[libvirt] Callback and stream questions
by arnaud.champion＠devatom.fr
Hi,
I would know if there is some callbacks for network adding/change/remove and for storage pool add/change/remove, I haven't seen these kind of callback in the API documentation.
Also, I don't understand the use of the virStream... functions (what is it used for ?)
Thanks
Arnaud Champion
14 years, 8 months
[libvirt] [PATCH 1/3] Attempt to load tun module on tap add error
by Doug Goldstein
When attempting to add a tap device, the error message is fairly cryptic
as to what really happened. If possible, try to load the tun module and
then try again to add the tap device again to improve the user
experience.
Signed-off-by: Doug Goldstein <cardoe(a)gentoo.org>
---
src/util/bridge.c | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/util/bridge.c b/src/util/bridge.c
index 7d0caae..ca4bcc9 100644
--- a/src/util/bridge.c
+++ b/src/util/bridge.c
@@ -486,12 +486,29 @@ brAddTap(brControl *ctl,
{
int fd;
struct ifreq ifr;
+ const char * const argv[] = { "modprobe", "tun", NULL };
+ int err, exitstatus = 0;
if (!ctl || !ctl->fd || !bridge || !ifname)
return EINVAL;
- if ((fd = open("/dev/net/tun", O_RDWR)) < 0)
- return errno;
+ if ((fd = open("/dev/net/tun", O_RDWR)) < 0) {
+ err = errno;
+
+ /* If the tun device was non-existent, lets try to load the module */
+ if (err == ENOENT) {
+ if (virRun(argv, &exitstatus) < 0) {
+ return ENOENT;
+ }
+
+ /* Now lets try to open the tun device again */
+ if ((fd = open("/dev/net/tun", O_RDWR)) < 0) {
+ return errno;
+ }
+ } else {
+ return err;
+ }
+ }
memset(&ifr, 0, sizeof(ifr));
--
1.7.2
14 years, 8 months
[libvirt] [PATCH 3/3] Fix return value usage
by Doug Goldstein
Fix the error checking to use the return value from brAddTap() instead
of checking the current errno value which might have been changed by
clean up calls inside of brAddTap().
Signed-off-by: Doug Goldstein <cardoe(a)gentoo.org>
---
src/qemu/qemu_conf.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index e92021a..7c0e354 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1689,7 +1689,7 @@ qemudNetworkIfaceConnect(virConnectPtr conn,
tapmac,
vnet_hdr,
&tapfd))) {
- if (errno == ENOTSUP) {
+ if (err == ENOTSUP) {
/* In this particular case, give a better diagnostic. */
qemuReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to add tap interface to bridge. "
--
1.7.2
14 years, 8 months
[libvirt] [PATCH 2/3] Add a detailed message when tap device add fails
by Doug Goldstein
Added a more detailed error message when adding a tap devices fails and
the kernel is missing tun support.
Signed-off-by: Doug Goldstein <cardoe(a)gentoo.org>
---
src/qemu/qemu_conf.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 2ca3350..e92021a 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1694,6 +1694,13 @@ qemudNetworkIfaceConnect(virConnectPtr conn,
qemuReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to add tap interface to bridge. "
"%s is not a bridge device"), brname);
+ } else if (err == ENOENT) {
+ /* When the tun drive is missing, give a better message. */
+ qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("Failed to add tap interface to bridge. "
+ "Your kernel is missing the 'tun' module or "
+ "CONFIG_TUN or you need to add the "
+ "/dev/net/tun device node."));
} else if (template_ifname) {
virReportSystemError(err,
_("Failed to add tap interface to
bridge '%s'"),
--
1.7.2
14 years, 8 months
[libvirt] [PATCH] build: rerun bootstrap if po/Makevars got nuked
by Eric Blake
There has been a frequent complaint of:
make[2]: Entering directory `/home/remote/eblake/libvirt/po'
make[2]: *** No rule to make target `/config.status', needed by `Makefile'. Stop.
It happens after nuking and regenerating the po directory,
which is a common action after running anything like
'make dist' or 'make rpm' that dirties all the .po files.
Teach autogen.sh that it must regenerate po/Makevars to avoid
the missing variable declaration, and teach cfg.mk to recognize
that a nuked po directory is cause to rerun autogen.sh.
* cfg.mk (_update_required): Check for po/Makevars.
* autogen.sh (bootstrap): Run bootstrap if it got lost.
Diagnosed by Justin Clift.
---
Tested by 'git clean -x -f po && make'. A bit drastic
(I prefer 'git checkout po' as the fastest way to undo
local changes to the po directory caused by 'make dist',
since that won't erase po/Makevars), but using that
sledgehammer to clean po/ proves that this patch works.
This should even work in a VPATH build :)
autogen.sh | 8 ++++++--
cfg.mk | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/autogen.sh b/autogen.sh
index 2f5b42d..c0a1c4a 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -74,10 +74,14 @@ bootstrap_hash()
# Ensure that whenever we pull in a gnulib update or otherwise change to a
# different version (i.e., when switching branches), we also rerun ./bootstrap.
+# Also, running 'make rpm' tends to litter the po/ directory, and some people
+# like to run 'git clean -x -f po' to fix it; but only ./bootstrap regenerates
+# the required file po/Makevars.
curr_status=.git-module-status
t=$(bootstrap_hash; git diff .gnulib)
-if test "$t" = "$(cat $curr_status 2>/dev/null)"; then
- : # good, it's up to date, all we need is autoreconf
+if test "$t" = "$(cat $curr_status 2>/dev/null)" \
+ && test -f "$THEDIR/po/Makevars"; then
+ # good, it's up to date, all we need is autoreconf
autoreconf -if
else
echo running bootstrap...
diff --git a/cfg.mk b/cfg.mk
index e12265e..7226828 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -459,6 +459,7 @@ ifeq (0,$(MAKELEVEL))
# b653eda3ac4864de205419d9f41eec267cb89eeb
_submodule_hash = sed 's/^[ +-]//;s/ .*//'
_update_required := $(shell \
+ test -f po/Makevars || { echo 1; exit; }; \
cd '$(srcdir)'; \
actual=$$(git submodule status | $(_submodule_hash); \
git hash-object bootstrap.conf; \
--
1.7.2
14 years, 8 months
[libvirt] NUMA cell?
by adrian wyssen
Hi,
I have a question regarding the documentation of libvirt. There is a
structure called 'virNodeInfo' and in the doc, you speak about NUMA cell. I
was wondering what that is. And what do you understand by 'the number of
threads per core'?
Thank you for a quick response, since I need to write an explanation in a
report until this evening.
Have a good day!
14 years, 8 months
[libvirt] Libvirt synchronous hooks
by Radek Hladik
I am trying Libvirt synchronous hooks and I would like to ask a
question. I would like to use the machine start (qemu+kvm) hook to set
up the storage for the machine. I already mentioned my setup in this
mailing list but for now it is only important that VM storage is a md
raid constructed from iSCSI disks. The VM's config is using simple file
device:
<disk type='file' device='disk'>
<driver name='qemu' type=''/>
<source
file='/dev/disk/by-id/md-uuid-e464a51e:f61e98b4:bfe78010:bc810f04'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05'
function='0x0'/>
</disk>
Stopping the array from stop hook works perfectly however it seems that
on the startup the storage is checked before the hook is executed. At
least I do get errors that the storage file
(/dev/disk/by-id/md-uuid-....) does not exist and my hook is not called.
I would say that I am hooking on wrong places that I should hook on
storage startup/shutdown but as far as I know there are no hooks for
storage drivers. Are there any plans in this area? Or is there any other
way how to do it that I do not see?
Radek
14 years, 8 months
[libvirt] [PATCH v4 0/8]: Add arbitrary qemu command-line and monitor commands
by Chris Lalancette
As we discussed previously, here is the patch series to add the ability
to specify arbitrary qemu command-line parameters and environment variables,
and also give arbitrary monitor commands to a guest. Because these
extra arguments have a good shot at confusing libvirt, the use of them
is not supported, but left available for advanced users and developers.
They are also in a separate library and have a separate on-the-wire
protocol.
There is one bug left that I have not yet been able to fix. Because of the
complicated way that virsh parses command-line arguments, it is not possible
to pass through spaces and quotes when using the qemu-monitor-command.
Unfortunately, the qemu monitor commands (and in particular when using QMP)
depend heavily on quoting and spacing, so using virsh to send through
command-lines is difficult. I'll have to think about how to better resolve
this issue, but it should not hold up the rest of the series.
I will point out one particular patch that could use some careful review,
namely PATCH 6/8. In there, I change the remote_message_hdr to use an
int proc instead of a enum remote_procedure proc. Now, as far as I can tell
the two sizes should be the same, so the wire protocol should be the same.
Indeed, testing seems to show that older virsh can talk just fine to a libvirtd
with these patches applied. However, the regenerated remote_protocol.c file for
parsing remote_message_header has some strange bits in it that I don't quite
understand. I'm hoping someone else can look at it and confirm that it is OK.
Thanks to Dan Berrange and Eric Blake for their reviews already, and to DV
for the Relax NG schema changes.
Changes since v3 are listed in the individual patches.
14 years, 8 months
[libvirt] [PATCH] Fix a memory leak in the qemudBuildCommandLine.
by Chris Lalancette
ADD_ARG_LIT should only be used for literal arguments,
since it duplicates the memory. Since virBufferContentAndReset
is already allocating memory, we should only use ADD_ARG.
Signed-off-by: Chris Lalancette <clalance(a)redhat.com>
---
src/qemu/qemu_conf.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 172986e..d0655fd 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -4110,7 +4110,7 @@ int qemudBuildCommandLine(virConnectPtr conn,
goto error;
}
- ADD_ARG_LIT(virBufferContentAndReset(&boot_buf));
+ ADD_ARG(virBufferContentAndReset(&boot_buf));
}
if (def->os.kernel) {
--
1.7.1.1
14 years, 8 months
