[libvirt] Domain XML format using defined storage volume
by Stefan de Konink
I have now a 'netapp'-pool, and lun-0..4. They all have a path.
<disk type='block'>
<source dev='?path?'>
<target dev='xvda' bus='xen'/>
</disk>
Now I wonder, is it possible to have here
somethinglike storage://netapp/lun-0?
Or should I use the path that comes out of the vol-list?
>From the standpoint: we make it easy for the user I would prefer not to
provide a Linux specific path.
Stefan
16 years, 6 months
[libvirt] PATCH: Write pidfile earlier in startup
by Daniel P. Berrange
When used with the --daemon arg, libvirtd will write out a pid file to
/var/run/libvirtd.pid and exit if this file already exists. Unfortuantely
it does this quite late in its startup procedure - in particular *after*
the call to qemudInitialize(), which in turns initializes the drivers,
which in turn autostarts all the VMs and networks.
So if you start a 2nd libvirtd instance it would do autostart before it
got to checking for existing PID file. This is clearly very bad because
the same VM would be started twice resulting in data corruption. Fortunately
the Red Hat / Fedora initscript also checks the PID file before even starting
the daemon, but this can affect people starting the daemon directly.
So this patch makes the goDaemon() / pidfile creation the very first thing
the daemon does after parsing command line arguments. This also results in
greatly increased startup time for OS, since the initscript doesn't have
to wait for it to auto-start all the VMs & networks before it daemonizes.
It also initializes the signal handlers before calling qemudInitialize()
since these really need to be setup before we start any VMs / child procs.
Dan.
Index: qemud/qemud.c
===================================================================
RCS file: /data/cvs/libvirt/qemud/qemud.c,v
retrieving revision 1.100
diff -u -p -r1.100 qemud.c
--- qemud/qemud.c 15 May 2008 06:12:32 -0000 1.100
+++ qemud/qemud.c 16 May 2008 15:58:43 -0000
@@ -2143,6 +2143,24 @@ int main(int argc, char **argv) {
}
}
+ if (godaemon) {
+ openlog("libvirtd", 0, 0);
+ if (qemudGoDaemon() < 0) {
+ qemudLog(QEMUD_ERR, _("Failed to fork as daemon: %s"),
+ strerror(errno));
+ goto error1;
+ }
+
+ /* Choose the name of the PID file. */
+ if (!pid_file) {
+ if (REMOTE_PID_FILE[0] != '\0')
+ pid_file = REMOTE_PID_FILE;
+ }
+
+ if (pid_file && qemudWritePidFile (pid_file) < 0)
+ goto error1;
+ }
+
if (pipe(sigpipe) < 0 ||
qemudSetNonBlock(sigpipe[0]) < 0 ||
qemudSetNonBlock(sigpipe[1]) < 0 ||
@@ -2154,6 +2172,19 @@ int main(int argc, char **argv) {
}
sigwrite = sigpipe[1];
+ sig_action.sa_sigaction = sig_handler;
+ sig_action.sa_flags = SA_SIGINFO;
+ sigemptyset(&sig_action.sa_mask);
+
+ sigaction(SIGHUP, &sig_action, NULL);
+ sigaction(SIGINT, &sig_action, NULL);
+ sigaction(SIGQUIT, &sig_action, NULL);
+ sigaction(SIGTERM, &sig_action, NULL);
+ sigaction(SIGCHLD, &sig_action, NULL);
+
+ sig_action.sa_handler = SIG_IGN;
+ sigaction(SIGPIPE, &sig_action, NULL);
+
if (!(server = qemudInitialize(sigpipe[0]))) {
ret = 2;
goto error1;
@@ -2175,37 +2206,6 @@ int main(int argc, char **argv) {
sockdirname);
}
- if (godaemon) {
- openlog("libvirtd", 0, 0);
- if (qemudGoDaemon() < 0) {
- qemudLog(QEMUD_ERR, _("Failed to fork as daemon: %s"),
- strerror(errno));
- goto error1;
- }
-
- /* Choose the name of the PID file. */
- if (!pid_file) {
- if (REMOTE_PID_FILE[0] != '\0')
- pid_file = REMOTE_PID_FILE;
- }
-
- if (pid_file && qemudWritePidFile (pid_file) < 0)
- goto error1;
- }
-
- sig_action.sa_sigaction = sig_handler;
- sig_action.sa_flags = SA_SIGINFO;
- sigemptyset(&sig_action.sa_mask);
-
- sigaction(SIGHUP, &sig_action, NULL);
- sigaction(SIGINT, &sig_action, NULL);
- sigaction(SIGQUIT, &sig_action, NULL);
- sigaction(SIGTERM, &sig_action, NULL);
- sigaction(SIGCHLD, &sig_action, NULL);
-
- sig_action.sa_handler = SIG_IGN;
- sigaction(SIGPIPE, &sig_action, NULL);
-
if (virEventAddHandleImpl(sigpipe[0],
POLLIN,
qemudDispatchSignalEvent,
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
16 years, 6 months
[libvirt] PATCH: Don't rely on host binaries in QEMU tests
by Daniel P. Berrange
The QEMU test suites rely on the QEMU/KVM/Xenner binaries being present
in /usr/bin. This has obvious problems and is unneccessary. The solution
is to not use the qemudCapsInit() function which initializes capabilities
based on binaries present. Instead I add a custom impl just for the test
cases which adds a pre-defined stable set of capabilities. I also had to
move a stat() check out of qemudBuildCommandLine() and into its caller.
It probably should have been there in the first place anyway
src/qemu_conf.c | 13 --------
src/qemu_driver.c | 14 +++++++++
tests/Makefile.am | 4 +-
tests/qemuxml2argvtest.c | 4 +-
tests/qemuxml2xmltest.c | 3 +
tests/testutilsqemu.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++
tests/testutilsqemu.h | 5 +++
7 files changed, 97 insertions(+), 17 deletions(-)
Dan.
Index: src/qemu_conf.c
===================================================================
RCS file: /data/cvs/libvirt/src/qemu_conf.c,v
retrieving revision 1.66
diff -u -p -u -p -r1.66 qemu_conf.c
--- src/qemu_conf.c 16 May 2008 09:37:44 -0000 1.66
+++ src/qemu_conf.c 16 May 2008 15:15:05 -0000
@@ -2326,7 +2326,6 @@ int qemudBuildCommandLine(virConnectPtr
char memory[50];
char vcpus[50];
char boot[QEMUD_MAX_BOOT_DEVS+1];
- struct stat sb;
struct qemud_vm_disk_def *disk = vm->def->disks;
struct qemud_vm_net_def *net = vm->def->nets;
struct qemud_vm_input_def *input = vm->def->inputs;
@@ -2336,18 +2335,6 @@ int qemudBuildCommandLine(virConnectPtr
struct utsname ut;
int disableKQEMU = 0;
- /* Make sure the binary we are about to try exec'ing exists.
- * Technically we could catch the exec() failure, but that's
- * in a sub-process so its hard to feed back a useful error
- */
- if (stat(vm->def->os.binary, &sb) < 0) {
- qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
- _("Cannot find QEMU binary %s: %s"),
- vm->def->os.binary,
- strerror(errno));
- return -1;
- }
-
if (vm->qemuVersion == 0) {
if (qemudExtractVersionInfo(vm->def->os.binary,
&(vm->qemuVersion),
Index: src/qemu_driver.c
===================================================================
RCS file: /data/cvs/libvirt/src/qemu_driver.c,v
retrieving revision 1.75
diff -u -p -u -p -r1.75 qemu_driver.c
--- src/qemu_driver.c 16 May 2008 09:37:44 -0000 1.75
+++ src/qemu_driver.c 16 May 2008 15:15:05 -0000
@@ -646,6 +646,7 @@ static int qemudStartVMDaemon(virConnect
char **argv = NULL, **tmp;
int i, ret;
char logfile[PATH_MAX];
+ struct stat sb;
if (qemudIsActiveVM(vm)) {
qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
@@ -702,6 +703,19 @@ static int qemudStartVMDaemon(virConnect
return -1;
}
+ /* Make sure the binary we are about to try exec'ing exists.
+ * Technically we could catch the exec() failure, but that's
+ * in a sub-process so its hard to feed back a useful error
+ */
+ if (stat(vm->def->os.binary, &sb) < 0) {
+ qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
+ _("Cannot find QEMU binary %s: %s"),
+ vm->def->os.binary,
+ strerror(errno));
+ return -1;
+ }
+
+
if (qemudBuildCommandLine(conn, driver, vm, &argv) < 0) {
close(vm->logfile);
vm->logfile = -1;
Index: tests/Makefile.am
===================================================================
RCS file: /data/cvs/libvirt/tests/Makefile.am,v
retrieving revision 1.42
diff -u -p -u -p -r1.42 Makefile.am
--- tests/Makefile.am 28 Apr 2008 13:36:48 -0000 1.42
+++ tests/Makefile.am 16 May 2008 15:15:05 -0000
@@ -100,12 +100,12 @@ xmconfigtest_SOURCES = \
xmconfigtest_LDADD = $(LDADDS)
qemuxml2argvtest_SOURCES = \
- qemuxml2argvtest.c \
+ qemuxml2argvtest.c testutilsqemu.c testutilsqemu.h \
testutils.c testutils.h
qemuxml2argvtest_LDADD = $(LDADDS)
qemuxml2xmltest_SOURCES = \
- qemuxml2xmltest.c \
+ qemuxml2xmltest.c testutilsqemu.c testutilsqemu.h \
testutils.c testutils.h
qemuxml2xmltest_LDADD = $(LDADDS)
Index: tests/qemuxml2argvtest.c
===================================================================
RCS file: /data/cvs/libvirt/tests/qemuxml2argvtest.c,v
retrieving revision 1.22
diff -u -p -u -p -r1.22 qemuxml2argvtest.c
--- tests/qemuxml2argvtest.c 15 May 2008 16:21:11 -0000 1.22
+++ tests/qemuxml2argvtest.c 16 May 2008 15:15:05 -0000
@@ -14,6 +14,8 @@
#include "testutils.h"
#include "qemu_conf.h"
+#include "testutilsqemu.h"
+
static char *progname;
static char *abs_srcdir;
static struct qemud_driver driver;
@@ -130,7 +132,7 @@ main(int argc, char **argv)
if (!abs_srcdir)
abs_srcdir = getcwd(cwd, sizeof(cwd));
- driver.caps = qemudCapsInit();
+ driver.caps = testQemuCapsInit();
#define DO_TEST(name, extraFlags) \
do { \
Index: tests/qemuxml2xmltest.c
===================================================================
RCS file: /data/cvs/libvirt/tests/qemuxml2xmltest.c,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 qemuxml2xmltest.c
--- tests/qemuxml2xmltest.c 15 May 2008 16:21:11 -0000 1.17
+++ tests/qemuxml2xmltest.c 16 May 2008 15:15:05 -0000
@@ -13,6 +13,7 @@
#include "internal.h"
#include "testutils.h"
#include "qemu_conf.h"
+#include "testutilsqemu.h"
static char *progname;
static char *abs_srcdir;
@@ -86,7 +87,7 @@ main(int argc, char **argv)
if (!abs_srcdir)
abs_srcdir = getcwd(cwd, sizeof(cwd));
- driver.caps = qemudCapsInit();
+ driver.caps = testQemuCapsInit();
#define DO_TEST(name) \
if (virtTestRun("QEMU XML-2-XML " name, \
Index: tests/testutilsqemu.c
===================================================================
RCS file: tests/testutilsqemu.c
diff -N tests/testutilsqemu.c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ tests/testutilsqemu.c 16 May 2008 15:15:05 -0000
@@ -0,0 +1,71 @@
+
+#include <sys/utsname.h>
+#include <stdlib.h>
+
+#include "testutilsqemu.h"
+
+virCapsPtr testQemuCapsInit(void) {
+ struct utsname utsname;
+ virCapsPtr caps;
+ virCapsGuestPtr guest;
+ static const char *const x86_machines[] = {
+ "pc", "isapc"
+ };
+ static const char *const xen_machines[] = {
+ "xenner"
+ };
+
+ uname (&utsname);
+ if ((caps = virCapabilitiesNew(utsname.machine,
+ 0, 0)) == NULL)
+ return NULL;
+
+ if ((guest = virCapabilitiesAddGuest(caps, "hvm", "i686", 32,
+ "/usr/bin/qemu", NULL,
+ 2, x86_machines)) == NULL)
+ goto cleanup;
+ if (virCapabilitiesAddGuestDomain(guest,
+ "qemu",
+ NULL,
+ NULL,
+ 0,
+ NULL) == NULL)
+ goto cleanup;
+
+ if ((guest = virCapabilitiesAddGuest(caps, "hvm", "x86_64", 64,
+ "/usr/bin/qemu-system-x86_64", NULL,
+ 2, x86_machines)) == NULL)
+ goto cleanup;
+ if (virCapabilitiesAddGuestDomain(guest,
+ "qemu",
+ NULL,
+ NULL,
+ 0,
+ NULL) == NULL)
+ goto cleanup;
+ if (virCapabilitiesAddGuestDomain(guest,
+ "kvm",
+ "/usr/bin/kvm",
+ NULL,
+ 0,
+ NULL) == NULL)
+ goto cleanup;
+
+ if ((guest = virCapabilitiesAddGuest(caps, "xen", "x86_64", 64,
+ "/usr/bin/xenner", NULL,
+ 1, xen_machines)) == NULL)
+ goto cleanup;
+ if (virCapabilitiesAddGuestDomain(guest,
+ "kvm",
+ "/usr/bin/kvm",
+ NULL,
+ 0,
+ NULL) == NULL)
+ goto cleanup;
+
+ return caps;
+
+cleanup:
+ virCapabilitiesFree(caps);
+ return NULL;
+}
Index: tests/testutilsqemu.h
===================================================================
RCS file: tests/testutilsqemu.h
diff -N tests/testutilsqemu.h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ tests/testutilsqemu.h 16 May 2008 15:15:05 -0000
@@ -0,0 +1,5 @@
+
+#include "capabilities.h"
+
+virCapsPtr testQemuCapsInit(void);
+
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
16 years, 6 months
[libvirt] listen_tls not enabling libvirtd to listen for tls
by Kenneth Nagin
libvirtd is not listening for TLS connection by default.
Setting 'listen_tls = 1' in /etc/libvirt/libvirtd.conf does not help
either.
However, starting 'libvirtd --listen' does work.
I'm running Fedora 8. I prefer to use the configuration file since
it is automatically started when the system reboots. Does anyone
know how to configure libvirtd to listen for tls?
Kenneth Nagin
16 years, 6 months
[libvirt] autostarting xend domains
by Wolfgang Rosenauer
Hi,
I found that support for setting autostart parameters for xend managed
guests has been added to libvirt
(https://www.redhat.com/archives/libvir-list/2008-May/msg00060.html)
So I tried that but failed with virsh's autostart command (and also
virt-manager) like this:
virsh # autostart saruman
libvir: Xen Daemon error : POST operation failed: (xend.err "Error
creating domain: VM name 'saruman' already exists as domain 32")
libvir: Xen Daemon error : failed Xen syscall Failed to redefine sexpr
6508560
error: Failed to mark domain saruman as autostarted
So yes, the domain is indeed running but I understood it should be
changeable during a domain's lifetime.
Any ideas?
That is a libvirt CVS snapshot from yesterday and a Xen 3.1 installation.
Thanks,
Wolfgang
16 years, 6 months
[libvirt] VMware ESX
by drew einhorn
Hi,
I have some code that can probably be hacked into a libvirt driver for
VMware ESX.
Is there a template with stubs for all the necessary routines for the API
that I can use
as a starting point?
--
Drew Einhorn
16 years, 6 months
[libvirt] [RFC] Comfortable lookup functions interface/block stats
by Stefan de Konink
Hi,
Wouldn't it be much nicer for Joe Programmer if the API facilitated the
functions:
char ** virDomainInterfacePaths(virDomainPtr dom);
char ** virDomainBlockPaths(virDomainPtr dom);
I really don't get why XML parsing should be done for something that is
almost too trivial to export. Any reasons why not to do implement this?
Stefan
16 years, 6 months
[Libvir] KVM migration
by Richard W.M. Jones
It turns out that the general migration strategy I defined[1] in
reference to Xen, ie. the 3 steps of Prepare/Perform/Finish, isn't
sufficient to support KVM migration.
The problem is that the destination needs to start qemu-kvm with
pretty much the exact same configuration / command line parameters as
were used at the source[2]. eg. If the source qemu-kvm has 512 MB of
RAM, then the destination had better have exactly 512 MB of RAM also.
(This is not the same as Xen where the migration protocol itself
carries this information between the two xend daemons).
We can modify the Prepare step to pass this information -- I'm
suggesting that we just pass the domain XML of the source domain.
Thus the Prepare step would change from:
static int
qemudDomainMigratePrepare (virConnectPtr dconn,
char **cookie,
int *cookielen,
const char *uri_in,
char **uri_out,
unsigned long flags,
const char *dname,
unsigned long resource)
to:
static int
qemudDomainMigratePreparev2 (virConnectPtr dconn,
char **cookie,
int *cookielen,
const char *uri_in,
char **uri_out,
+ const char *dom_xml,
unsigned long flags,
const char *dname,
unsigned long resource)
As hinted there, we also need a new version of the migration protocol,
and a new remote call (Preparev2).
So questions:
(a) Does anyone have any objections?
(b) Does anyone see a simpler way to do this?
(c) Since we're adding a second version of the protocol, does anyone
want anything else added?
(d) Will the domain XML alone be sufficient to recreate the exact
qemu command line? (Seems to be the case, and in fact KVM suspend/
restore support seems to implicitly rely on this too).
Rich.
Notes:
[1] https://www.redhat.com/archives/libvir-list/2007-July/msg00357.html
and https://www.redhat.com/archives/libvir-list/2007-July/msg00304.html
[2] http://kvm.qumranet.com/kvmwiki/Migration#head-71900dbcf45d8ac81649fe4f03...
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
16 years, 6 months
[libvirt] Serial console on a qemu image through virt-manager
by ClaesBas
I give up!
How should the xml-file look?
In http://libvirt.org/formatdomain.html#elementsConsole it says
something like:
</devices>
<console type='pty'>
<source path='/dev/pts/4'/>
<target port='0'/>
</console>
</devices>
But in Xen example (http://libvirt.org/drvxen.html) it looks like:
<devices>
<console tty='/dev/pts/5'/>
</devices>
I have latest versions from source on both libvirt (Mercurial) and
virt-manager (CVS).
Before I updated virt-manager (from Ubuntus Hardy-version) I had a
choice for serial
console which opened a console window which was all "Black" inside.
After upgrade of
virt-manager I got no contact with any serial console at all.
My guest is a qemu image of OpenBSD with console configured to first
serial port.
I could see that the image is ok, if I reconfig the xml-file to use vnc
instead.
Then I see that OpenBSD is trying to use serial port as console.
Output from /var/log/libvirt/qemu/obsd64.log:
/usr/bin/kvm -M pc -m 512 -smp 1 -name obsd64 -nographic -monitor pty
-no-acpi -boot c -drive
file=/home/cs/kvm/OpenBSD/obsd64.hda,if=ide,index=0,boot=on -net
nic,macaddr=00:16:3e:17:9d:f7,vlan=0 -net user,vlan=0 -serial pty
-parallel none -usb
char device redirected to /dev/pts/1
char device redirected to /dev/pts/2
When I have the following xml-fil (/etc/libvirt/qemu/obsd64.xml):
<domain type='qemu'>
<name>obsd64</name>
<uuid>5b315a1a-530a-1f13-fcb7-54098c9968a7</uuid>
<memory>524288</memory>
<currentMemory>524288</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='pc'>hvm</type>
<boot dev='hd'/>
</os>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<source file='/home/cs/kvm/OpenBSD/obsd64.hda'/>
<target dev='hda' bus='ide'/>
</disk>
<interface type='user'>
<mac address='00:16:3e:17:9d:f7'/>
</interface>
<console tty='/dev/pts/1'/>
</devices>
</domain>
And the log from virt-manager says:
[Mon, 19 May 2008 13:11:32 virt-manager 3973] DEBUG (manager:413) VM
obsd64 started
[Mon, 19 May 2008 13:11:36 virt-manager 3973] DEBUG (details:1010)
Trying console login
[Mon, 19 May 2008 13:11:36 virt-manager 3973] DEBUG (details:1015) No
graphics configured in guest
[Mon, 19 May 2008 13:11:36 virt-manager 3973] DEBUG (details:528) In
hw_selected with null tree iter
[Mon, 19 May 2008 13:11:36 virt-manager 3973] DEBUG (details:528) In
hw_selected with null tree iter
[Mon, 19 May 2008 13:11:36 virt-manager 3973] DEBUG (details:1010)
Trying console login
[Mon, 19 May 2008 13:11:37 virt-manager 3973] DEBUG (details:1015) No
graphics configured in guest
Is this working/tested?
Regards
Claes
PS
I have tried many many variants on <console>.......
16 years, 6 months
