[libvirt] Best final spot for the in depth libvirt user docs?
by Justin Clift
Hi Richard,
Tidying things up in regards to some of the documentation, and it's probably time
to move the in depth content from the libvirt.org wiki, to it's final resting spot(s?).
Do you reckon these would be better moved to the virt-tools.org site, or the
libvirt.org site?
SSH Setup (concepts, tasks, further reading)
http://wiki.libvirt.org/page/SSHSetup
SSH Setup with PolicyKit (tasks and further reading)
http://wiki.libvirt.org/page/SSHPolicyKitSetup
TLS Setup (concepts, tasks, further reading)
http://wiki.libvirt.org/page/TLSSetup
VNC TLS Setup (tasks)
http://wiki.libvirt.org/page/VNCTLSSetup
Virtual Networking (concepts)
http://wiki.libvirt.org/page/VirtualNetworking
Possibly this one too, but it's not 100% yet, and doesn't have matching ones
for the other Virtual Networking modes (Routed and Isolated):
NAT Virtual Network setup with Virt-Manager (tasks)
http://wiki.libvirt.org/page/TaskNATSetupVirtManager
?
Regards and best wishes,
Justin Clift
13 years, 10 months
[libvirt] compressing .git/ can save 15%
by Jim Meyering
Hi DV,
I ran this on a fresh clone of libvirt:
$ du -sh .git; git gc --aggressive; du -sh .git
54M .git
...
45M .git
I propose to do the same thing on the server, libvirt.org.
It's not a big deal, but decreased bandwidth wouldn't hurt,
and the slightly smaller on-disk repository makes even local
git tools feel a little snappier. It's worth doing for all git
repositories.
As far as I know, no one stores anything useful as "unlinked" commits
on the server (they would be removed by the above), so there is no
down-side to doing this. In fact, "man git-gc" recommends to run
git gc --aggressive "every few hundred changesets or so".
Adding a cron job to do it every few weeks would be nice (e.g., Sunday
at 4am local). Let me know and I'll do it via my account.
13 years, 10 months
[libvirt] tests/daemon-conf bug
by Eric Blake
Right now, the daemon-conf test fires up an instance of libvirtd, but
that instance tries to probe the installed location of cpu_map.xml
rather than an in-tree location, which means the test is liable to fail
if run on a just built but uninstalled binary:
I/O warning : failed to load external entity
"/usr/local/share/libvirt/cpu_map.xml"
17:10:50.357: 14549: warning : qemuCapsInit:774 : Failed to get host CPU
I'm not sure how to go about isolating the test from the installation
directory, since libvirtd currently doesn't have any way (either via
command line argument or via the temp.conf file) to override the
preferred location of other files such as cpu_map.xml. Maybe a new
libvirtd.conf entry is called for, which defaults to the installation
location, but which daemon-conf munges to the in-tree location before
passing --conf-file to the libvirtd instance.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
13 years, 10 months
[libvirt] [PATCH] qemu: Reject SDL graphic if it's not supported by qemu
by Osier Yang
If the emulator doesn't support SDL graphic, we should reject
the use of SDL graphic xml with error messages, but not ignore
it silently.
* src/qemu/qemu_command.c
---
src/qemu/qemu_command.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 7dd8e03..cf4ae01 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3567,6 +3567,14 @@ qemuBuildCommandLine(virConnectPtr conn,
}
} else if ((def->ngraphics == 1) &&
def->graphics[0]->type == VIR_DOMAIN_GRAPHICS_TYPE_SDL) {
+ if (!(qemuCmdFlags & QEMUD_CMD_FLAG_SDL)) {
+ qemuReportError(VIR_ERR_INTERNAL_ERROR,
+ _("sdl not supported by '%s'"),
+ def->emulator);
+
+ goto error;
+ }
+
if (def->graphics[0]->data.sdl.xauth)
virCommandAddEnvPair(cmd, "XAUTHORITY",
def->graphics[0]->data.sdl.xauth);
@@ -3586,9 +3594,7 @@ qemuBuildCommandLine(virConnectPtr conn,
/* New QEMU has this flag to let us explicitly ask for
* SDL graphics. This is better than relying on the
* default, since the default changes :-( */
- if (qemuCmdFlags & QEMUD_CMD_FLAG_SDL)
- virCommandAddArg(cmd, "-sdl");
-
+ virCommandAddArg(cmd, "-sdl");
} else if ((def->ngraphics == 1) &&
def->graphics[0]->type == VIR_DOMAIN_GRAPHICS_TYPE_SPICE) {
virBuffer opt = VIR_BUFFER_INITIALIZER;
--
1.7.3.2
13 years, 10 months
[libvirt] [PATCH 1/2] Add a parameter to virThreadPoolSendJob() to let the caller decide whether to wait for the job to complete
by Hu Tao
---
src/qemu/qemu_driver.c | 2 +-
src/util/threadpool.c | 19 ++++++++++++++++++-
src/util/threadpool.h | 3 ++-
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 924446f..aa2e805 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -665,7 +665,7 @@ qemuHandleDomainWatchdog(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
if (VIR_ALLOC(wdEvent) == 0) {
wdEvent->action = VIR_DOMAIN_WATCHDOG_ACTION_DUMP;
wdEvent->vm = vm;
- ignore_value(virThreadPoolSendJob(driver->workerPool, wdEvent));
+ ignore_value(virThreadPoolSendJob(driver->workerPool, wdEvent, false));
} else
virReportOOMError();
}
diff --git a/src/util/threadpool.c b/src/util/threadpool.c
index 1213862..07f2fcf 100644
--- a/src/util/threadpool.c
+++ b/src/util/threadpool.c
@@ -42,6 +42,7 @@ struct _virThreadPoolJob {
virThreadPoolJobPtr next;
void *data;
+ virCondPtr complete;
};
typedef struct _virThreadPoolJobList virThreadPoolJobList;
@@ -73,6 +74,7 @@ struct _virThreadPool {
static void virThreadPoolWorker(void *opaque)
{
virThreadPoolPtr pool = opaque;
+ virCondPtr complete;
virMutexLock(&pool->mutex);
@@ -97,9 +99,12 @@ static void virThreadPoolWorker(void *opaque)
pool->jobList.tail = &pool->jobList.head;
virMutexUnlock(&pool->mutex);
+ complete = job->complete;
(pool->jobFunc)(job->data, pool->jobOpaque);
VIR_FREE(job);
virMutexLock(&pool->mutex);
+ if (complete)
+ virCondSignal(complete);
}
out:
@@ -188,9 +193,14 @@ void virThreadPoolFree(virThreadPoolPtr pool)
}
int virThreadPoolSendJob(virThreadPoolPtr pool,
- void *jobData)
+ void *jobData,
+ bool waitForCompletion)
{
virThreadPoolJobPtr job;
+ virCond complete;
+
+ if (waitForCompletion && virCondInit(&complete) < 0)
+ return -1;
virMutexLock(&pool->mutex);
if (pool->quit)
@@ -219,10 +229,17 @@ int virThreadPoolSendJob(virThreadPoolPtr pool,
job->data = jobData;
job->next = NULL;
+ job->complete = NULL;
*pool->jobList.tail = job;
pool->jobList.tail = &(*pool->jobList.tail)->next;
virCondSignal(&pool->cond);
+
+ if (waitForCompletion) {
+ job->complete = &complete;
+ virCondWait(&complete, &pool->mutex);
+ }
+
virMutexUnlock(&pool->mutex);
return 0;
diff --git a/src/util/threadpool.h b/src/util/threadpool.h
index 5714b0b..6f763dc 100644
--- a/src/util/threadpool.h
+++ b/src/util/threadpool.h
@@ -41,7 +41,8 @@ virThreadPoolPtr virThreadPoolNew(size_t minWorkers,
void virThreadPoolFree(virThreadPoolPtr pool);
int virThreadPoolSendJob(virThreadPoolPtr pool,
- void *jobdata) ATTRIBUTE_NONNULL(1)
+ void *jobdata,
+ bool waitForCompletion) ATTRIBUTE_NONNULL(1)
ATTRIBUTE_NONNULL(2)
ATTRIBUTE_RETURN_CHECK;
--
1.7.3.1
--
Thanks,
Hu Tao
13 years, 10 months
[libvirt] [PATCH] pass correct uri to source host when we do p2p migration
by Wen Congyang
When we migrate a guest from remote host to localhost by p2p, the libvirtd
on remote host will be deadlock. This patch fixes a bug and we can avoid
the deadlock with this patch.
The steps to reproduce this bug:
# virsh -c qemu+ssh://<remotehost IP>/system migrate --p2p <domain name> qemu+ssh:///system
We connect dest host(qemu+ssh:///system) on source host, and the uri we pass
to source host is qemu+ssh:///system. And then we connect a wrong dest host.
Signed-off-by: Wen Congyang <wency(a)cn.fujitsu.com>
---
src/libvirt.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index ee2495a..81a1bf8 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -3533,22 +3533,71 @@ virDomainMigratePeer2Peer (virDomainPtr domain,
const char *uri,
unsigned long bandwidth)
{
+ xmlURIPtr tempxmluri = NULL;
+ char * tempuri = NULL;
+ int ret = -1;
+ char * hostname = NULL;
+
if (!domain->conn->driver->domainMigratePerform) {
virLibConnError (domain->conn, VIR_ERR_NO_SUPPORT, __FUNCTION__);
virDispatchError(domain->conn);
return -1;
}
+ tempxmluri = xmlParseURI(uri);
+ if (!tempxmluri) {
+ virLibConnError (domain->conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
+ virDispatchError(domain->conn);
+ goto out;
+ }
+ if (tempxmluri->server) {
+ tempuri = uri;
+ } else {
+ /*
+ * The uri will be passed to source host. If user inputs qemu:///system,
+ * the dest host is localhost. But we connect the dest host on source
+ * host(a remote host). So we should pass qemu://<dest hostname>/system
+ * to the source host.
+ */
+ hostname = virGetHostname(NULL);
+ if (!hostname) {
+ virDispatchError(domain->conn);
+ goto out;
+ }
+
+ if (STRPREFIX(hostname, "localhost")) {
+ virLibConnError(domain->conn, VIR_ERR_INTERNAL_ERROR,
+ _("hostname on destination resolved to localhost, but migration requires an FQDN"));
+ virDispatchError(domain->conn);
+ goto out;
+ }
+
+ tempxmluri->server = hostname;
+ tempuri = strdup((char *)xmlSaveUri(tempxmluri));
+ if (!tempuri) {
+ virReportOOMError();
+ virDispatchError(domain->conn);
+ goto out;
+ }
+ }
+
/* Perform the migration. The driver isn't supposed to return
* until the migration is complete.
*/
- return domain->conn->driver->domainMigratePerform(domain,
+ ret = domain->conn->driver->domainMigratePerform(domain,
NULL, /* cookie */
0, /* cookielen */
- uri,
+ tempuri,
flags,
dname,
bandwidth);
+
+out:
+ VIR_FREE(hostname);
+ if (tempuri && tempuri != uri)
+ VIR_FREE(tempuri);
+
+ return ret;
}
--
1.7.1
13 years, 10 months
[libvirt] [PATCH] docs: add entry for archipel to the apps page
by Justin Clift
---
docs/apps.html.in | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/docs/apps.html.in b/docs/apps.html.in
index 792c145..d4e74bb 100644
--- a/docs/apps.html.in
+++ b/docs/apps.html.in
@@ -67,6 +67,26 @@
</dd>
</dl>
+ <h2><a name="clientserver">Client/Server applications</a></h2>
+
+ <dl>
+ <dt><a href="http://archipelproject.org">Archipel</a></dt>
+ <dd>
+ Archipel is a libvirt-based solution to manage and supervise virtual
+ machines. It uses XMPP for all communication. There is no web
+ service or custom protocol. You just need at least one XMPP server,
+ like eJabberd, to start playing with it. This allows Archipel to
+ work completely real time. You never have to refresh the user
+ interface, you'll be notified as soon as something happens. You can
+ even use your favorite chat clients to command your infrastructure.
+ </dd>
+ <dd>
+ Isn't it great to be able to open a chat conversation with your
+ virtual machine and say things like "How are you today?" or "Hey,
+ please reboot"?
+ </dd>
+ </dl>
+
<h2><a name="desktop">Desktop applications</a></h2>
<dl>
@@ -122,7 +142,7 @@
<dl>
<dt><a href="http://honk.sigxcpu.org/projects/libvirt/#munin">for munin</a></dt>
<dd>
- The plugins provided by Guido Günther allow to monitor various things
+ The plugins provided by Guido Günther allow to monitor various things
like network and block I/O with
<a href="http://munin.projects.linpro.no/">Munin</a>.
</dd>
--
1.7.3.2
13 years, 10 months
[libvirt] [PATCH] vbox: Silently ignore missing registry key on Windows
by Matthias Bolte
Don't report an error when the VirtualBox registry key is missing,
as this just indicates that VirtualBox is not installed in general.
This matches the behavior of the XPCOM glue that silently ignores
a missing VBoxXPCOMC.so.
---
src/vbox/vbox_MSCOMGlue.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/vbox/vbox_MSCOMGlue.c b/src/vbox/vbox_MSCOMGlue.c
index e6a886f..be0ec34 100644
--- a/src/vbox/vbox_MSCOMGlue.c
+++ b/src/vbox/vbox_MSCOMGlue.c
@@ -356,8 +356,6 @@ vboxLookupVersionInRegistry(void)
status = RegOpenKeyEx(HKEY_LOCAL_MACHINE, keyName, 0, KEY_READ, &key);
if (status != ERROR_SUCCESS) {
- VIR_ERROR(_("Could not open registry key '%s' nor '%s'"),
- VBOX_REGKEY_ORACLE, VBOX_REGKEY_SUN);
return -1;
}
}
--
1.7.0.4
13 years, 10 months
[libvirt] Docs team task: Update main docs.html page with index of all pages
by Justin Clift
Hi Anthony,
(Following up from previous email, but CC'ing the libvirt team this time
as some of the guys might have input/ideas/etc.)
I'm thinking the very best thing you can do is get our "Docs" landing
page under control for the main site:
http://libvirt.org/docs.html
It's very blank, relying on people to realise that everything is accessible
on the left hand menu bar instead. :(
What it should contain is an index to all of the main documentation
pieces, so people can click directly from there.
Some sort of menu structure will be needed (up to you, try things out).
The way the website works, is that it's actually part of the libvirt source
code. The "docs" directory in the source code is effectively the website.
When people update the docs directory in the git repository, there's a
cronjob on the libvirt.org server that rebuilds the live website.
So, first things first, you'll need to make sure you have the "xhtml1-dtds"
package installed. It's in the main CentOS repositories, so yum should
know it automatically.
Then you'll need to get the main libvirt source code from git:
$ git clone git://libvirt.org/libvirt.git
Cloning into libvirt...
remote: Counting objects: 50501, done.
remote: Compressing objects: 100% (8276/8276), done.
remote: Total 50501 (delta 42262), reused 50237 (delta 42087)
Receiving objects: 100% (50501/50501), 52.13 MiB | 165 KiB/s, done.
Resolving deltas: 100% (42262/42262), done.
$ ls -la
total 0
drwxr-xr-x 3 user staff 102 8 Jan 21:47 .
drwxr-xr-x@ 22 user staff 748 8 Jan 21:47 ..
drwxr-xr-x 65 user staff 2210 8 Jan 21:55 libvirt
(For me, on the opposite side of the world to the main libvirt.org server,
this takes a while. Several minutes. Subsequent operations are much
faster.)
Then change into the newly created "libvirt" subdirectory, and run the
"autogen.sh" command. This prepares the entire libvirt source code for
compiling locally, including the website docs (which you'll need).
$ ./autogen.sh
(this will configure itself if all the needed utils are installed, or it might
barf if somethings missing. It should proactively let you know if there's
else that needs installing)
Once the autogen.sh has finished, run "make". If you have a multi-core
processor, run it as a parallel make using the -j option:
$ make -j 5
Parallel makes are a *bunch* faster than just using a single core. The #
to use is the number of cores in the box, plus one. (ie use -j 3 on a dual
core, use -j 9 on a 8 core box, etc)
If you open your browser, there should be in "index.html" file in the docs
directory. Open that. Voila, it's the website. :)
So, the file you need to update is the docs/docs.html.in one. When you
make changes to it, run the "make" command again. That'll process it,
converting it from docs.html.in, to docs.html.
As you're trying things out and getting it right, feel free to copy the
generated output to some temporary spot on the web then post the URL
for comment/feedback/suggestions/etc. (I do this fairly often too)
When you reckon it's all good and ready for inclusion, I'll give you the steps
for generating a patch file and posting it. It's pretty simple. :)
How's that so far?
Regards and best wishes,
Justin Clift
13 years, 10 months
