[libvirt] Problem with fullyvirtualized guest direct kernel boot
by Max Martynov
Hi All,
I am trying to use fullyvirtualized guest direct kernel boot, but all I see
is the following error:
libvir: Xen Daemon error : POST operation failed: (xend.err 'Error creating
domain: (2, \'Invalid kernel\', "elf_xen_note_check: ERROR: Not a Xen-ELF
image: No ELF notes or \'__xen_guest\' section found.\\n")')
Kernel, initrd and root file system are extracted from working Fedora 9 disk
image without any additional tinkering. Guest Fedora is clean and was
installed from scratch. When I use this whole disk image with
fullyvirtualized guest BIOS boot with, everything works fine. I also tried
paravirtualized guest bootloader with another linux kernel and it also works
fine. Xen version is 3.2.1-rc1-pre. Host OS is Ubuntu Hardy.
Here is the libvirt config for direct kernel boot:
<domain type='xen' id='18'>
<name>test1</name>
<uuid>4dea22b31d52d8f32516782e98ab3fa0</uuid>
<os>
<type>linux</type>
<loader>/usr/lib/xen/boot/hvmloader</loader>
<kernel>/tmp/vmlinuz-2.6.25-14.fc9.i686</kernel>
<initrd>/tmp/initrd-2.6.25-14.fc9.i686.img</initrd>
<root>/dev/sda1</root>
<cmdline>ro</cmdline>
</os>
<memory>524288</memory>
<vcpu>1</vcpu>
<devices>
<emulator>/usr/lib/xen/bin/qemu-dm</emulator>
<disk type='file'>
<driver name="tap" type="aio"/>
<source file='/tmp/f9_disassembled/root.img'/>
<target dev='sda1'/>
</disk>
<disk type='file'>
<driver name="tap" type="aio"/>
<source file='/tmp/swap'/>
<target dev='sda3'/>
</disk>
<interface type='bridge'>
<source bridge='eth0'/>
<mac address='00:16:3e:5d:c7:9e'/>
<script path='/etc/xen/scripts/vif-bridge'/>
</interface>
<graphics type='vnc' port='5904'/>
</devices>
</domain>
What do you think can be the cause of this issue?
--
Thanks, Max
<libvir-list(a)redhat.com>
15 years, 6 months
[libvirt] [PATCH] cleanup of loging definitions
by Daniel Veillard
Currently the debugFlag switch, the VIR_DEBUG, DEBUG and DEBUG0
macros were scattered in various places, duplicated once (or twice)
per generated binaries. This patch moves everything in one virtlog.h
header, one virtlog.c file and set up the makefiles so that the
various binaries refers to the same bits.
That's a cleanup with no functional change to prepare the real
loging APIs, patch and the 2 new files attached,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
15 years, 6 months
[libvirt] Openvz bridge support
by Anton Protopopov
Hi,
2008/10/14 Daniel P. Berrange <berrange(a)redhat.com>
> This patch series is derived from Anton Protopopov /Evgeniy Sokolov
> bridge device patches. It first does some generic refactoring of MAC
> address handler in all drivers, then adds code to extract openvz version
> number, then does network config, and finally does filesystem config.
Are these patches will be commited some day?
Or they are still work-in-progress?
Or they are just forgotten? :)
15 years, 6 months
[libvirt] Libvirt CVS fails to build on PPC
by Chris Lalancette
Actually, the subject isn't strictly true. Libvirt CVS currently fails to build
when using this configuration on any platform:
./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu
--target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --without-xen --without-qemu
--with-init-script=redhat --with-qemud-pid-file=/var/run/libvirt_qemud.pid
--with-remote-file=/var/run/libvirtd.pid
(the important part is the --without-xen --without-qemu in there). This just
happens to be the configuration that koji uses when it is building the ppc
libvirt package. There are a lot of build errors, but they start with:
network_driver.c:64: error: expected specifier-qualifier-list before
'iptablesContext'
network_driver.c: In function 'networkStartup':
network_driver.c:124: error: 'struct network_driver' has no member named 'logDir'
This seems to stem from the new module refactoring. I'm not entirely sure
what's the correct way to fix it, however; I *think* we always want to build the
network_driver at this point, but if that's the case, then we need to make sure
we have the header files for iptablesContext and friends included. Dan, any ideas?
--
Chris Lalancette
15 years, 6 months
[libvirt] [PATCH] dynamic debug patch
by Daniel Veillard
First version of a small patch allowing to gather debug informations
from a running libvirt daemon. Basically one can send signal USR2
to the daemon, the daemon will from that point dump its current internal
state and all verbose debug output to a file /tmp/libvirt_debug_xxxx.
When sending back signal USR2 the file is closed and can be looked at
for analysis, this allow to save extensive debug informations from a
running daemon.
The patch is rather minimal right now, it just applies to
qemud/qemud.c, modifies it to have global variables for error and
information output FILE, an init routing setting them up and hooking
a handler for USR2, the handler, a very minimal state dump. But it
works as is.
Now I would like to extend that debugging to the library itself, so
any app linking to libvirt can be debugged in the same way. I would
also like to add debugging routines for most internal data structures.
I'm still wondering about the best form for those, should they use
a FILE * argument, an fd argument or a virBufferPtr for genericity
(probably the later would make most sense).
#ifdef ENABLE_DEBUG
void virConnectDebug(virBufferPtr buf, virConnectPtr conn);
#endif
and similar for main internal data structures and drivers
The patch is just a work in progress but trying to get early feedback.
Maybe this could be used to get remote introspection capabilities too
but ATM I'm more looking at providing an easy way to get debug
informations on a libvirt program.
Also I'm unclear, do we really want to have all the debug strings
internationalized with _() , that's more work for localization team
and it's unclear this would benefit 'end users'.
Patch and an example of log attached,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
15 years, 6 months
[libvirt] [PATCH] plug two leaks and fix a diagnostic
by Jim Meyering
Without this patch, running make check would trigger this minor leak:
10 bytes in 1 blocks are definitely lost in loss record 1 of 20
at 0x4A0739E: malloc (vg_replace_malloc.c:207)
by 0x3F872808A1: strdup (strdup.c:43)
by 0x4CA2503: qemudLoadDriverConfig (qemu_conf.c:70)
by 0x4CA7EA7: qemudStartup (qemu_driver.c:216)
by 0x4C3AEBC: __virStateInitialize (libvirt.c:592)
by 0x4096B6: qemudInitialize (qemud.c:738)
by 0x40CCCF: main (qemud.c:2216)
Looking into it, I found there were actually two separate leaks
and an erroneous diagnostic. This fixes them:
>From b1f17b05e59cf12aa3f73fde1be713dbadf02f76 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering(a)redhat.com>
Date: Wed, 5 Nov 2008 14:50:24 +0100
Subject: [PATCH] plug two leaks and fix a diagnostic
* src/qemu_conf.c (qemudLoadDriverConfig): Don't leak ->vncListen.
Fix an erroneous copy-and-pasted diagnostic.
* src/qemu_driver.c (qemudShutdown): Don't leak another ->vncListen.
---
src/qemu_conf.c | 3 ++-
src/qemu_driver.c | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index 54ac23d..0e3b959 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -118,9 +118,10 @@ int qemudLoadDriverConfig(struct qemud_driver *driver,
p = virConfGetValue (conf, "vnc_listen");
CHECK_TYPE ("vnc_listen", VIR_CONF_STRING);
if (p && p->str) {
+ VIR_FREE(driver->vncListen);
if (!(driver->vncListen = strdup(p->str))) {
qemudReportError(NULL, NULL, NULL, VIR_ERR_NO_MEMORY,
- "%s", _("failed to allocate vncTLSx509certdir"));
+ "%s", _("failed to allocate vnc_listen"));
virConfFree(conf);
return -1;
}
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 4adeb73..5d108ed 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -314,6 +314,7 @@ qemudShutdown(void) {
VIR_FREE(qemu_driver->configDir);
VIR_FREE(qemu_driver->autostartDir);
VIR_FREE(qemu_driver->vncTLSx509certdir);
+ VIR_FREE(qemu_driver->vncListen);
/* Free domain callback list */
virDomainEventCallbackListFree(qemu_driver->domainEventCallbacks);
--
1.6.0.3.756.gb776d
15 years, 6 months
[libvirt] [PATCH]: vgscan before doing logical pool discovery
by Chris Lalancette
Assume that you have an iSCSI target available, and on that iSCSI target 1 LUN
is exported. On that 1 LUN, you have an LVM volume group (say, myvg), with 2
logical volumes (say, lv1 and lv2). Now you execute the following sequence of
commands:
1) virsh define iscsi_pool.xml
2) virsh start iscsi_pool
3) virsh find-storage-pool-sources-as logical
With that sequence, you would expect step 3) to return XML similar to:
<sources><source><name>myvg</name><device path='/dev/sdb'/></source></sources>
However, what you instead get is: <sources/>. That's because if you just try to
do storage pool discovery on a logical pool without ever touching the logical
pool in any fashion, pvs (what we use to do discovery) doesn't return anything.
If you touch the logical volume group at all (say, with vgscan), they then
suddenly appear. To make sure we see all of the potential volume groups when
doing pool discovery, make sure to run vgscan before we run pvs. With this
patch in place, logical discovery just does the right thing.
Signed-off-by: Chris Lalancette <clalance(a)redhat.com>
15 years, 6 months
[libvirt] New Libvirt Implementation - OpenNebula
by Ruben S. Montero
Dear all,
You may find of interest a new implementation of the libvirt
virtualization API. This new implementation adds support to OpenNebula, a
distributed VM manager system. The implementation of libvirt on top of a
distributed VM manager, like OpenNebula, provides an abstraction of a whole
cluster of resources (each one with its hypervisor). In this way, you can use
any libvirt tool (e.g. virsh, virt-manager) and XML domain descriptions at a
distributed level.
For example, you may create a new domain with 'virsh create', then OpenNebula
will look for a suitable resource, transfer the VM images and boot your VM
using any of the supported hypervisors. The distributed management is
completely transparent to the libvirt application. This is, a whole cluster
can be managed as any other libvirt node.
The current implementation is targeted for libvirt 0.4.4, and includes a patch
to the libvirt source tree (mainly to modify the autotools files), and a
libvirt driver.
More information and download instructions can be found at:
* http://trac.opennebula.org/wiki/LibvirtOpenNebula
* http://www.opennebula.org
Cheers
Ruben
--
+---------------------------------------------------------------+
Dr. Ruben Santiago Montero
Associate Professor
Distributed System Architecture Group (http://dsa-research.org)
URL: http://dsa-research.org/doku.php?id=people:ruben
Weblog: http://blog.dsa-research.org/?author=7
GridWay, http://www.gridway.org
OpenNEbula, http://www.opennebula.org
+---------------------------------------------------------------+
15 years, 6 months
