Re: [libvirt] Exposing some unique features?
On Thu, Aug 28, 2008 at 2:52 PM, Atsushi SAKAI [EMAIL PROTECTED] wrote: Hi, Quynh Did you see the libvirt access control feature? http://libvirt.org/auth.html You mean current access control feature is not enough for your use. But that access control is about authenticating/authorizing, and that has nothing to do with the idea of exposing unique features. Thanks, Q Nguyen Anh Quynh [EMAIL PROTECTED] wrote: Hi, Though libvirt tries very hard to hide the difference between hypervisors behind an abstraction layer, there are still differences that we might want to expose to the users. For example, QEMU has the monitor interface, which provides some unique functions. Users might want to have access to the monitor interface and send command to it (like gdbserver command?). So how can we expose such information? We can have a new driver function, which return an opaque structure. The content of the structure is of course depends on the hypervisor type. One problem is that this might be dangerous if users relies on the QEMU monitor to execute some functions that should be done under control. Idea? Thanks, Quynh -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Exposing some unique features?
Hi, Quynh Thank you for your comment. I am clearified your question. But I have no good idea to solve. Someone may have a good idea. Thanks Atsushi SAKAI Nguyen Anh Quynh [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 2:52 PM, Atsushi SAKAI [EMAIL PROTECTED] wrote: Hi, Quynh Did you see the libvirt access control feature? http://libvirt.org/auth.html You mean current access control feature is not enough for your use. But that access control is about authenticating/authorizing, and that has nothing to do with the idea of exposing unique features. Thanks, Q Nguyen Anh Quynh [EMAIL PROTECTED] wrote: Hi, Though libvirt tries very hard to hide the difference between hypervisors behind an abstraction layer, there are still differences that we might want to expose to the users. For example, QEMU has the monitor interface, which provides some unique functions. Users might want to have access to the monitor interface and send command to it (like gdbserver command?). So how can we expose such information? We can have a new driver function, which return an opaque structure. The content of the structure is of course depends on the hypervisor type. One problem is that this might be dangerous if users relies on the QEMU monitor to execute some functions that should be done under control. Idea? Thanks, Quynh -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [augeas-devel] PATCH: Add a augeas lens for libvirtd.conf
On Wed, Aug 27, 2008 at 09:20:18PM +, David Lutterkort wrote: On Wed, 2008-08-27 at 12:03 +0100, Richard W.M. Jones wrote: Out of interest, do you ever hit the 16 bit limit in the size of compiled regexps? The bytecode used to represent compiled GNU regexps has (or perhaps had) a 16 bit limit in the jump offsets, which I hit a few years back. Had to switch to using a flex-compiled pattern matcher in the end. No, I haven't run into that. Was that with the 'old' GNU regex implementation (before ~ 2002) or with the current one ? Yes, looking at glibc it seems the 2^16 limit has been removed. There is still an error for it: regex.h: REG_ESIZE, /* Compiled pattern bigger than 2^16 bytes. */ but nothing in the code appears to generate this error. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Switch openvz driver to domain APIs
On Thu, Aug 28, 2008 at 12:06:08PM +0400, Evgeniy Sokolov wrote:
The biggest flaw I see currently is that the
openvz driver doesn't load the existing device config for networks or
filesystems of existing VMs, so you can't see that info in the XML dump
Yes. Good note. I will implement it.
-/*get VCPU*/
-ret = openvzReadConfigParam(veid, CPUS, temp, sizeof(temp));
-if (ret 0) {
- openvzError(conn, VIR_ERR_INTERNAL_ERROR,
-_(Cound not read config for container %d),
veid);
- goto error;
-} else if (ret 0) {
- vmdef-vcpus = strtoI(temp);
-}
Why did you remove loading VCPUs and always set = 1 ?
Stupid mistake during a manual merge. Here's an updated patch which
fixes that mistake
Daniel
diff -r e270be59a80f src/openvz_conf.c
--- a/src/openvz_conf.c Wed Aug 27 17:03:25 2008 +0100
+++ b/src/openvz_conf.c Thu Aug 28 09:49:14 2008 +0100
@@ -40,39 +40,29 @@
#include limits.h
#include errno.h
#include string.h
-
-#include libxml/parser.h
-#include libxml/tree.h
-#include libxml/xpath.h
-#include libxml/uri.h
-
-#include internal.h
-
-#include openvz_driver.h
+#include sys/utsname.h
+
#include openvz_conf.h
#include uuid.h
#include buf.h
#include memory.h
#include util.h
-#include xml.h
-#include domain_conf.h
static char *openvzLocateConfDir(void);
-static struct openvz_vm_def *openvzParseXML(virConnectPtr conn, xmlDocPtr xml);
static int openvzGetVPSUUID(int vpsid, char *uuidstr);
-static int openvzSetUUID(int vpsid);
static int openvzLocateConfFile(int vpsid, char *conffile, int maxlen);
+static int openvzAssignUUIDs(void);
void
openvzError (virConnectPtr conn, virErrorNumber code, const char *fmt, ...)
{
va_list args;
-char errorMessage[OPENVZ_MAX_ERROR_LEN];
+char errorMessage[1024];
const char *errmsg;
if (fmt) {
va_start(args, fmt);
-vsnprintf(errorMessage, OPENVZ_MAX_ERROR_LEN-1, fmt, args);
+vsnprintf(errorMessage, sizeof(errorMessage)-1, fmt, args);
va_end(args);
} else {
errorMessage[0] = '\0';
@@ -84,46 +74,6 @@ openvzError (virConnectPtr conn, virErro
errmsg, errorMessage);
}
-struct openvz_vm
-*openvzFindVMByID(const struct openvz_driver *driver, int id) {
-struct openvz_vm *vm = driver-vms;
-
-while (vm) {
-if (vm-vpsid == id)
-return vm;
-vm = vm-next;
-}
-
-return NULL;
-}
-
-struct openvz_vm
-*openvzFindVMByUUID(const struct openvz_driver *driver,
- const unsigned char *uuid) {
-struct openvz_vm *vm = driver-vms;
-
-while (vm) {
-if (!memcmp(vm-vmdef-uuid, uuid, VIR_UUID_BUFLEN))
-return vm;
-vm = vm-next;
-}
-
-return NULL;
-}
-
-struct openvz_vm
-*openvzFindVMByName(const struct openvz_driver *driver,
- const char *name) {
-struct openvz_vm *vm = driver-vms;
-
-while (vm) {
-if (STREQ(vm-vmdef-name, name))
-return vm;
-vm = vm-next;
-}
-
-return NULL;
-}
int
strtoI(const char *str)
@@ -135,6 +85,43 @@ strtoI(const char *str)
return val;
}
+
+virCapsPtr openvzCapsInit(void)
+{
+struct utsname utsname;
+virCapsPtr caps;
+virCapsGuestPtr guest;
+
+uname(utsname);
+
+if ((caps = virCapabilitiesNew(utsname.machine,
+ 0, 0)) == NULL)
+goto no_memory;
+
+if ((guest = virCapabilitiesAddGuest(caps,
+ exe,
+ utsname.machine,
+ sizeof(int) == 4 ? 32 : 8,
+ NULL,
+ NULL,
+ 0,
+ NULL)) == NULL)
+goto no_memory;
+
+if (virCapabilitiesAddGuestDomain(guest,
+ openvz,
+ NULL,
+ NULL,
+ 0,
+ NULL) == NULL)
+goto no_memory;
+return caps;
+
+no_memory:
+virCapabilitiesFree(caps);
+return NULL;
+}
+
/* function checks MAC address is empty
return 0 - empty
@@ -164,438 +151,117 @@ char *openvzMacToString(const unsigned c
return strdup(str);
}
-void
-openvzRemoveInactiveVM(struct openvz_driver *driver, struct openvz_vm *vm)
-{
-driver-num_inactive--;
-openvzFreeVM(driver, vm, 1);
-}
-
-/* Free all memory associated with a openvz_vm_def structure */
-void
-openvzFreeVMDef(struct openvz_vm_def *def)
-{
-if (def) {
-virDomainNetDefFree(def-net);
-}
-}
-
-/* Free all memory associated with a openvz_vm structure
- * @checkCallee == 0 then openvzFreeDriver() is callee else some other
Re: [libvirt] [PATCH] enable parallel builds
Jim Meyering [EMAIL PROTECTED] wrote: James Morris [EMAIL PROTECTED] wrote: I'm not sure if this is the best way to do this, but it seems to work. Enable parallel compilation of the repository when running the autobuild script and/or via rpmbuild. ... diff --git a/autobuild.sh b/autobuild.sh ... Good idea. I'll be happy to commit it with something like the following in place of the above: # If the MAKEFLAGS envvar does not yet include a -j option, # add -jN where N depends on the number of processors. case $MAKEFLAGS in *-j*) ;; *) n=$(getconf _NPROCESSORS_ONLN 2 /dev/null) test $n -gt 0 || n=1 n=`expr $n + 1` MAKEFLAGS=$MAKEFLAGS -j$n export MAKEFLAGS ;; esac Then you don't have to change the make invocation below, and it won't interfere if someone has already set MAKEFLAGS. Also, not using an absolute path to getconf lets that program work even also when it's installed in a different location. Finally, I prefer to use N_CPUS+1 as the -j option, here. (personally, I use 2*$N_CPUS+1, but that's probably too aggressive) Ok? I'm interpreting non-response as agreement, so have just committed my proposed change: http://article.gmane.org/gmane.comp.emulators.libvirt/8215 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix ejecting cdroms with latest qemu syntax
On Wed, Aug 27, 2008 at 05:32:21PM -0400, Cole Robinson wrote:
Daniel P. Berrange wrote:
I think this block could be re-factored a little into one or more helper
methods, because I think we'll need to re-use this for hot-unplug of
disks. I'd suggest a helper to turn the plain integer index into the
(bus,device) index pair
virDiskNameToBusDeviceIndex(virDomainDiskDefPtr disk,
int *busIdx,
int *devIdx);
And then a QEMU specific function
char *virQEMUDeviceName(virDomainDiskDefPtr disk);
and have this call virDiskNameToBusDeviceIndex() and return the 'ide1-2'
type string.
Okay, second cut attached. I followed your recommendations:
virDiskNameToBusDeviceIndex added to domain_conf.c
qemudDiskDeviceName added to qemu_driver.c
I also hopefully solved the back compatibility issue. Seems
-drive was added to qemu in Dec 07 (qemu commit 3759) and the
device naming scheme was updated at the end of that month (qemu
commit 3846), so checking for -drive should be a sufficient
indicator that we need to use the new device name format. So
if drive was detected (using the already present qemu_conf
flag), we revert to the old style cdrom/fda naming style.
Excellant - that intermediate month can be argued as a bug
because people could add multiple CDROMs and the monitor
provided no way to select between them. So this check for
-drive is sufficient.
+/* Translates a device name of the form (regex) [fhv]d[a-z]+ into
+ * the corresponding bus,index combination (e.g. sda = (0,0), sdi (1,1),
+ * hdd = (1,1), vdaa =
(0,27))
+ * @param disk The disk device
+ * @param busIdx parsed bus number
+ * @param devIdx parsed device number
+ * @return 0 on success, -1 on failure
+ */
+int virDiskNameToBusDeviceIndex(virDomainDiskDefPtr disk,
+int *busIdx,
+int *devIdx) {
+
+int idx = virDiskNameToIndex(disk-dst);
Minor bug here
if (idx 0)
return -1;
+
+switch (disk-bus) {
+case VIR_DOMAIN_DISK_BUS_IDE:
+*busIdx = ((idx - (idx % 2)) / 2);
+*devIdx = (idx % 2);
+break;
+case VIR_DOMAIN_DISK_BUS_SCSI:
+*busIdx = ((idx - (idx % 7)) / 7);
+*devIdx = (idx % 7);
+break;
+case VIR_DOMAIN_DISK_BUS_FDC:
+case VIR_DOMAIN_DISK_BUS_VIRTIO:
Could also add
case VIR_DOMAIN_DISK_BUS_USB:
case VIR_DOMAIN_DISK_BUS_XEN:
+default:
+*busIdx = 0;
+*devIdx = idx;
+break;
+}
+
+return 0;
+}
+/* Return the disks name for use in monitor commands */
+static char *qemudDiskDeviceName(virDomainPtr dom,
+ virDomainDiskDefPtr disk) {
+
+int busid, devid;
+int ret;
+char *devname;
+
+virDiskNameToBusDeviceIndex(disk, busid, devid);
if (virDiskNameToBusDeviceIndex(disk, busid, devid) 0)
qemudReportError(dom-conn, dom, NULL, VIR_ERR_INTERNAL_ERROR,
_(cannot convertor disk name to bus/device
index));
return NULL;
}
+
+switch (disk-bus) {
+case VIR_DOMAIN_DISK_BUS_IDE:
+ret = asprintf(devname, ide%d-cd%d, busid, devid);
+break;
+case VIR_DOMAIN_DISK_BUS_SCSI:
+ret = asprintf(devname, scsi%d-cd%d, busid, devid);
+break;
+case VIR_DOMAIN_DISK_BUS_FDC:
+ret = asprintf(devname, floppy%d, devid);
+break;
+case VIR_DOMAIN_DISK_BUS_VIRTIO:
+ret = asprintf(devname, virtio%d, devid);
+break;
+default:
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_NO_SUPPORT,
+ _(Unknown disk name mapping for bus '%s'),
+ virDomainDiskBusTypeToString(disk-bus));
s/Unknown/Unsupported/ because we know about Xen / USB, merely don't
support them.
+return NULL;
+}
+
+if (ret == -1) {
+qemudReportError(dom-conn, NULL, NULL, VIR_ERR_NO_MEMORY, NULL);
+return NULL;
+}
+
+return devname;
+}
+
+static int qemudDomainChangeEjectableMedia(virDomainPtr dom,
+ virDomainDeviceDefPtr dev)
+{
struct qemud_driver *driver = (struct qemud_driver
*)dom-conn-privateData;
+virDomainObjPtr vm = virDomainFindByUUID(driver-domains, dom-uuid);
+virDomainDiskDefPtr origdisk, newdisk;
char *cmd, *reply, *safe_path;
+char *devname = NULL;
+int qemuCmdFlags;
+
+if (!vm) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_INVALID_DOMAIN,
+ %s, _(no domain with matching uuid));
+return -1;
+}
+
+newdisk = dev-data.disk;
+
Re: [libvirt] [PATCH] xen: fix domain lookup after define
On Wed, Aug 27, 2008 at 08:57:24PM -0400, Cole Robinson wrote: Defining a xen domain will succeed, but report error because we weren't properly passing the domain's name to the post-define lookup. ACK, this was a mistake during the conversion to new APIs Attached patch fixes this, and also adds a debug statement to show the sexpr we create from the passed xml. Good idea - there's been a number of BZ tickets where it would have been useful to ask the user to get this with LIBVIRT_DEBUG=1 Daniel -- |: Red Hat, Engineering, London -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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] enable parallel builds
On Thu, Aug 28, 2008 at 11:13:03AM +0200, Jim Meyering wrote: Jim Meyering [EMAIL PROTECTED] wrote: James Morris [EMAIL PROTECTED] wrote: I'm not sure if this is the best way to do this, but it seems to work. Enable parallel compilation of the repository when running the autobuild script and/or via rpmbuild. ... diff --git a/autobuild.sh b/autobuild.sh ... Good idea. I'll be happy to commit it with something like the following in place of the above: # If the MAKEFLAGS envvar does not yet include a -j option, # add -jN where N depends on the number of processors. case $MAKEFLAGS in *-j*) ;; *) n=$(getconf _NPROCESSORS_ONLN 2 /dev/null) test $n -gt 0 || n=1 n=`expr $n + 1` MAKEFLAGS=$MAKEFLAGS -j$n export MAKEFLAGS ;; esac Then you don't have to change the make invocation below, and it won't interfere if someone has already set MAKEFLAGS. Also, not using an absolute path to getconf lets that program work even also when it's installed in a different location. Finally, I prefer to use N_CPUS+1 as the -j option, here. (personally, I use 2*$N_CPUS+1, but that's probably too aggressive) Ok? I'm interpreting non-response as agreement, Sorry, thought I had replied to your mail already, but obviously forgot. It was fine by me. Daniel -- |: Red Hat, Engineering, London -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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 4/4: Add pivot_root support to container
On Wed, Aug 27, 2008 at 09:58:58PM +0100, Daniel P. Berrange wrote:
On Wed, Aug 27, 2008 at 01:32:13PM -0700, Dan Smith wrote:
DB +static int lxcContainerMountNewFS(virDomainDefPtr vmDef)
DB +{
DB +virDomainFSDefPtr tmp;
DB +return -1;
Shouldn't this be return 0? AFAICT, this means this function will
always fail and thus any domain with a root target will fail to start.
If I change this to return 0 I'm able to start such guests, with
properly pivoted roots.
Yes, it clearly should be return 0.
On a more general note, it seems like there are a lot of places where
failures trigger a return -1 that rolls completely up the stack with
no error information getting logged. Since you have the excellent
per-container logging functionality, can we increase the verbosity a
little so that there is some way to diagnose where things are failing?
Thus far, I've just started sprinkling fprintf()'s into the code until I
start to narrow things down. I'd be glad to help with that after this
goes in.
The newly improved virExec() API which LXC now uses ensures that libvirt's
error callback is reset to the default in child processes. This means that
any call to virRaiseError in the child is turned into a fprintf(stderr...).
We also wire the container stdout/err to /var/log/libvirt/lxc/NAME.log
So if everything is operating as I expect, all the lxcError() calls in
this code should result in log messages being written out to /var/log.
Of course in this particular scenario you would never have had a log
message because this should never have been a 'return -1'. I found a
couple of other places with missing lxcError() calls. So here's an
updated patch
diff -r 4d49719aa768 src/lxc_container.c
--- a/src/lxc_container.c Wed Aug 27 22:19:33 2008 +0100
+++ b/src/lxc_container.c Wed Aug 27 22:21:15 2008 +0100
@@ -1,10 +1,12 @@
/*
* Copyright IBM Corp. 2008
+ * Copyright Red Hat 2008
*
* lxc_container.c: file description
*
* Authors:
* David L. Leskovec dlesko at linux.vnet.ibm.com
+ * Daniel P. Berrange [EMAIL PROTECTED]
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -26,10 +28,18 @@
#include fcntl.h
#include limits.h
#include stdlib.h
+#include stdio.h
#include sys/ioctl.h
#include sys/mount.h
#include sys/wait.h
#include unistd.h
+#include mntent.h
+
+/* Yes, we want linux private one, for _syscall2() macro */
+#include linux/unistd.h
+
+/* For MS_MOVE */
+#include linux/fs.h
#include lxc_container.h
#include util.h
@@ -103,23 +113,15 @@
*
* Returns 0 on success or -1 in case of error
*/
-static int lxcContainerSetStdio(int control, const char *ttyPath)
+static int lxcContainerSetStdio(int control, int ttyfd)
{
int rc = -1;
-int ttyfd;
int open_max, i;
if (setsid() 0) {
lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
_(setsid failed: %s), strerror(errno));
-goto error_out;
-}
-
-ttyfd = open(ttyPath, O_RDWR|O_NOCTTY);
-if (ttyfd 0) {
-lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
- _(open(%s) failed: %s), ttyPath, strerror(errno));
-goto error_out;
+goto cleanup;
}
if (ioctl(ttyfd, TIOCSCTTY, NULL) 0) {
@@ -156,9 +158,6 @@
rc = 0;
cleanup:
-close(ttyfd);
-
-error_out:
return rc;
}
@@ -221,6 +220,7 @@
return 0;
}
+
/**
* lxcEnableInterfaces:
* @vm: Pointer to vm structure
@@ -251,6 +251,285 @@
return rc;
}
+
+//_syscall2(int, pivot_root, char *, newroot, const char *, oldroot)
+extern int pivot_root(const char * new_root,const char * put_old);
+
+static int lxcContainerChildMountSort(const void *a, const void *b)
+{
+ const char **sa = (const char**)a;
+ const char **sb = (const char**)b;
+
+ /* Delibrately reversed args - we need to unmount deepest
+ children first */
+ return strcmp(*sb, *sa);
+}
+
+static int lxcContainerPivotRoot(virDomainFSDefPtr root)
+{
+char *oldroot;
+
+/* First step is to ensure the new root itself is
+ a mount point */
+if (mount(root-src, root-src, NULL, MS_BIND, NULL) 0) {
+lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
+ _(failed to bind new root %s: %s),
+ root-src, strerror(errno));
+return -1;
+}
+
+if (asprintf(oldroot, %s/.oldroot, root-src) 0) {
+oldroot = NULL;
+lxcError(NULL, NULL, VIR_ERR_NO_MEMORY, NULL);
+return -1;
+}
+
+if (virFileMakePath(oldroot) 0) {
+VIR_FREE(oldroot);
+lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
+ _(failed to create %s: %s),
+ oldroot, strerror(errno));
+return -1;
+}
+
+/* The old root directory will live at /.oldroot after
+ * this and will soon be unmounted completely */
+if (pivot_root(root-src, oldroot) 0) {
+
Re: [libvirt] [PATCH] Don't list capabilities entries if emulators can't be accessed
On Mon, Aug 25, 2008 at 01:16:39PM -0400, Cole Robinson wrote: Daniel P. Berrange wrote: On Wed, Aug 20, 2008 at 12:51:05PM -0400, Cole Robinson wrote: diff --git a/src/qemu_conf.c b/src/qemu_conf.c index dc9e42a..0328cc1 100644 --- a/src/qemu_conf.c +++ b/src/qemu_conf.c @@ -230,6 +230,10 @@ qemudCapsInitGuest(virCapsPtr caps, virCapsGuestPtr guest; int i; +/* Check for existance of base emulator */ +if (access(info-binary, X_OK) == -1) +return 0; + This isn't right - this means that if KVM is installed, but QEMU is not installed you won't get any capabilities. Basically we need todo all the access() checks for QEMU, KVM, /dev/kvm up-front. And then generated the capabilites if either QEMU or KVM is available. Okay, I think this patch solves the issues. We check upfront for the base emulator and potential kvm emulators (qemu-kvm, and /usr/bin/kvm for ubuntu/upstream .spec). If nothing is found, just return. If only the base emulator is found, skip kvm even if /dev/kvm exists. If only kvm bin is found, add the base emulator capabilities only if emulator and host arch matches. ACK, this looks good now. Daniel -- |: Red Hat, Engineering, London -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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH]: Allow libvirt to manage bridges plugged into physical devices
All,
For ovirt, we need the ability to have a bridge configured that is plugged
in to an external interface; that is, the physical interface is one of the
interfaces on the bridge. This allows us to manage physical hardware outside
this box, since the ovirt WUI appliance will be hooked to this same bridge and
will send/receive traffic to these external machines. Currently we are doing
this by hand with scripts, which is clearly sub-optimal.
This relatively simple patch adds a new forward type called bridge
(yes, it's a bad name; I'm open to suggestions). Basically, when you have a
bridge with this forward type, we take the dev that is specified (say, eth1),
plug it into the bridge, and add the appropriate iptables rule to bridge
traffic.
With this in place, we can get rid of our hacky scripts and let libvirt do
the dirty work for us. I also imagine this could be useful to support
xen-style bridges, without necessarily using the Xen networking scripts.
Comments?
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
Index: src/iptables.c
===
RCS file: /data/cvs/libvirt/src/iptables.c,v
retrieving revision 1.30
diff -u -r1.30 iptables.c
--- a/src/iptables.c 8 Aug 2008 15:43:38 - 1.30
+++ b/src/iptables.c 28 Aug 2008 11:59:53 -
@@ -706,6 +706,26 @@
}
+static int iptablesAllowBridge(iptablesContext *ctx, int action)
+{
+return iptablesAddRemoveRule(ctx-forward_filter, action,
+ --match, physdev,
+ !, --physdev-is-bridged,
+ --jump, REJECT,
+ --reject-with, icmp-host-prohibited,
+ NULL);
+}
+
+int iptablesAddAllowBridge(iptablesContext *ctx)
+{
+return iptablesAllowBridge(ctx, ADD);
+}
+
+int iptablesRemoveAllowBridge(iptablesContext *ctx)
+{
+return iptablesAllowBridge(ctx, REMOVE);
+}
+
/* Allow all traffic coming from the bridge, with a valid network address
* to proceed to WAN
*/
Index: src/iptables.h
===
RCS file: /data/cvs/libvirt/src/iptables.h,v
retrieving revision 1.5
diff -u -r1.5 iptables.h
--- a/src/iptables.h 10 Apr 2008 16:53:29 - 1.5
+++ b/src/iptables.h 28 Aug 2008 11:59:53 -
@@ -46,6 +46,8 @@
const char *iface,
int port);
+int iptablesAddAllowBridge (iptablesContext *ctx);
+int iptablesRemoveAllowBridge (iptablesContext *ctx);
int iptablesAddForwardAllowOut (iptablesContext *ctx,
const char *network,
const char *iface,
Index: src/network_conf.c
===
RCS file: /data/cvs/libvirt/src/network_conf.c,v
retrieving revision 1.7
diff -u -r1.7 network_conf.c
--- a/src/network_conf.c 20 Aug 2008 12:50:29 - 1.7
+++ b/src/network_conf.c 28 Aug 2008 11:59:53 -
@@ -46,7 +46,7 @@
VIR_ENUM_IMPL(virNetworkForward,
VIR_NETWORK_FORWARD_LAST,
- none, nat, route )
+ none, nat, route, bridge )
static void virNetworkReportError(virConnectPtr conn,
int code, const char *fmt, ...)
Index: src/network_conf.h
===
RCS file: /data/cvs/libvirt/src/network_conf.h,v
retrieving revision 1.2
diff -u -r1.2 network_conf.h
--- a/src/network_conf.h 20 Aug 2008 12:50:29 - 1.2
+++ b/src/network_conf.h 28 Aug 2008 11:59:53 -
@@ -31,6 +31,7 @@
VIR_NETWORK_FORWARD_NONE = 0,
VIR_NETWORK_FORWARD_NAT,
VIR_NETWORK_FORWARD_ROUTE,
+VIR_NETWORK_FORWARD_BRIDGE,
VIR_NETWORK_FORWARD_LAST,
};
Index: src/qemu_driver.c
===
RCS file: /data/cvs/libvirt/src/qemu_driver.c,v
retrieving revision 1.112
diff -u -r1.112 qemu_driver.c
--- a/src/qemu_driver.c 27 Aug 2008 11:42:52 - 1.112
+++ b/src/qemu_driver.c 28 Aug 2008 11:59:54 -
@@ -1332,6 +1332,7 @@
struct qemud_driver *driver,
virNetworkObjPtr network) {
int err;
+brControl *brctl = NULL;
if (!driver-iptables !(driver-iptables = iptablesContextNew())) {
qemudReportError(conn, NULL, NULL, VIR_ERR_NO_MEMORY,
@@ -1404,7 +1405,36 @@
else if (network-def-forwardType == VIR_NETWORK_FORWARD_ROUTE
!qemudAddRoutingIptablesRules(conn, driver, network))
goto err8;
+else if (network-def-forwardType == VIR_NETWORK_FORWARD_BRIDGE) {
+if (brInit(brctl) != 0) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
+ _(failed to initialize bridge
[libvirt] [PATCH] use poweroff not halt for virsh shutdown
halt means just that, and we want to poweroff. Linux doesn't care, but Solaris differentiates between the two. Signed-off-by: John Levon [EMAIL PROTECTED] Index: src/xend_internal.c === RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.211 diff -u -r1.211 xend_internal.c --- src/xend_internal.c 28 Aug 2008 11:59:07 - 1.211 +++ src/xend_internal.c 28 Aug 2008 14:04:21 - @@ -2884,7 +2884,7 @@ } if (domain-id 0) return(-1); -return xend_op(domain-conn, domain-name, op, shutdown, reason, halt, NULL); +return xend_op(domain-conn, domain-name, op, shutdown, reason, poweroff, NULL); } /** Index: src/xs_internal.c === RCS file: /data/cvs/libvirt/src/xs_internal.c,v retrieving revision 1.68 diff -u -r1.68 xs_internal.c --- src/xs_internal.c 20 Aug 2008 20:48:36 - 1.68 +++ src/xs_internal.c 28 Aug 2008 14:04:22 - @@ -654,7 +654,7 @@ * this is very hackish, the domU kernel probes for a special * node in the xenstore and launch the shutdown command if found. */ -return(virDomainDoStoreWrite(domain, control/shutdown, halt)); +return(virDomainDoStoreWrite(domain, control/shutdown, poweroff)); } /** -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] virsh dump should not be live
Live dumps are much less likely to produce usable cores. They also trigger a Xen bug that crashes xend. Signed-off-by: John Levon [EMAIL PROTECTED] Index: src/xend_internal.c === RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.211 diff -u -r1.211 xend_internal.c --- src/xend_internal.c 28 Aug 2008 11:59:07 - 1.211 +++ src/xend_internal.c 28 Aug 2008 14:10:45 - @@ -3037,7 +3037,7 @@ if (domain-id 0) return(-1); return xend_op(domain-conn, domain-name, op, dump, file, filename, - live, 1, crash, 0, NULL); + live, 0, crash, 0, NULL); } /** -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh dump should not be live
On Thu, Aug 28, 2008 at 03:12:06PM +0100, John Levon wrote: Live dumps are much less likely to produce usable cores. They also trigger a Xen bug that crashes xend. Better still, we should make use of the '@flags: extra flags, currently unused' parameter to virDomainDumpCore() to allow requesting of live vs offline dumps, since both have valid use cases. Daniel -- |: Red Hat, Engineering, London -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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh dump should not be live
On Thu, Aug 28, 2008 at 03:17:06PM +0100, Daniel P. Berrange wrote: On Thu, Aug 28, 2008 at 03:12:06PM +0100, John Levon wrote: Live dumps are much less likely to produce usable cores. They also trigger a Xen bug that crashes xend. Better still, we should make use of the '@flags: extra flags, currently unused' parameter to virDomainDumpCore() to allow requesting of live vs offline dumps, since both have valid use cases. Well that would be nice, I agree, but I'm fixing a bug here not adding features. I really don't have time to go off and implement extra stuff right now. regards john -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] A laundry list of TODO items for libvirt
A bunch of us at Red Hat had a bit of a brainstorming session to make a list of things we'd like to see added to libvirt going forward, to better support our needs for virtualization in Fedora / oVirt. We've put details of everything up on the libvirt wiki: http://wiki.libvirt.org/page/Todo This list isn't a firm commitment to actually implement these features. We may later decide that some of them don't belong in libvirt (eg, the question of allowing multiu-thread access to virConnectPtr is open to debate). Nor have we got people actually working on these items - unless explicitly noted against a todo item. If anyone is looking to do work on libvirt and isn't sure of what to work on, this list may be of interest. Also, this is a wiki, so feel free to add more ideas - or add expanded details to existing ideas. Or reply to this mail, and one of us will add new ideas to the wiki for you The only request is that you don't actually start implementing things from the list without first discussing proposals on this list, because most of these ideas need more design / analysis before its reasonable to write code Regards, Daniel -- |: Red Hat, Engineering, London -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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] use poweroff not halt for virsh shutdown
On Thu, Aug 28, 2008 at 03:05:32PM +0100, John Levon wrote:
halt means just that, and we want to poweroff. Linux doesn't care,
but Solaris differentiates between the two.
ACK, confirmed Linux treats them identically
drivers/xen/core/reboot.c
THe control/shutdown xenstore watch fires shutdown_handler(), which
sets up a job for __shutdown_handler(), which runs shutdown_process()
which does
if ((shutting_down == SHUTDOWN_POWEROFF) ||
(shutting_down == SHUTDOWN_HALT)) {
if (call_usermodehelper(/sbin/poweroff, poweroff_argv,
envp, 0) 0) {
Semantically 'poweroff' is what we're wanting for virDomainShutdown().
Daniel
--
|: Red Hat, Engineering, London -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 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh dump should not be live
On Thu, Aug 28, 2008 at 03:12:06PM +0100, John Levon wrote: Live dumps are much less likely to produce usable cores. They also trigger a Xen bug that crashes xend. +1. As John says, fixes the immediate bug. We can add features later. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] PATCH: Fix fetch of NUMA info when building Xen capabilities
Currently if you use libvirt CVS HEAD on Xen = 3.2 hypervisor it will fail
to open a connection. This is because I mistakenly removed the passing of
the virConnectPtr object when querying NUMA capabilities from XenD. This
patch fixes that regression
Daniel
Index: src/xen_internal.c
===
RCS file: /data/cvs/libvirt/src/xen_internal.c,v
retrieving revision 1.124
diff -u -p -r1.124 xen_internal.c
--- src/xen_internal.c 20 Aug 2008 20:48:36 - 1.124
+++ src/xen_internal.c 28 Aug 2008 15:38:05 -
@@ -2159,7 +2159,8 @@ struct guest_arch {
static virCapsPtr
-xenHypervisorBuildCapabilities(const char *hostmachine,
+xenHypervisorBuildCapabilities(virConnectPtr conn,
+ const char *hostmachine,
int host_pae,
char *hvm_type,
struct guest_arch *guest_archs,
@@ -2185,7 +2186,7 @@ xenHypervisorBuildCapabilities(const cha
if (sys_interface_version = 4) {
-if (xenDaemonNodeGetTopology(NULL, caps) != 0) {
+if (xenDaemonNodeGetTopology(conn, caps) != 0) {
virCapabilitiesFree(caps);
return NULL;
}
@@ -2271,7 +2272,8 @@ xenHypervisorBuildCapabilities(const cha
* Return the capabilities of this hypervisor.
*/
virCapsPtr
-xenHypervisorMakeCapabilitiesInternal(const char *hostmachine,
+xenHypervisorMakeCapabilitiesInternal(virConnectPtr conn,
+ const char *hostmachine,
FILE *cpuinfo, FILE *capabilities)
{
char line[1024], *str, *token;
@@ -2404,7 +2406,8 @@ xenHypervisorMakeCapabilitiesInternal(co
}
}
-if ((caps = xenHypervisorBuildCapabilities(hostmachine,
+if ((caps = xenHypervisorBuildCapabilities(conn,
+ hostmachine,
host_pae,
hvm_type,
guest_archs,
@@ -2425,7 +2428,7 @@ xenHypervisorMakeCapabilitiesInternal(co
* Return the capabilities of this hypervisor.
*/
virCapsPtr
-xenHypervisorMakeCapabilities(void)
+xenHypervisorMakeCapabilities(virConnectPtr conn)
{
virCapsPtr caps;
FILE *cpuinfo, *capabilities;
@@ -2451,7 +2454,10 @@ xenHypervisorMakeCapabilities(void)
}
}
-caps = xenHypervisorMakeCapabilitiesInternal(utsname.machine, cpuinfo,
capabilities);
+caps = xenHypervisorMakeCapabilitiesInternal(conn,
+ utsname.machine,
+ cpuinfo,
+ capabilities);
if (cpuinfo)
fclose(cpuinfo);
Index: src/xen_internal.h
===
RCS file: /data/cvs/libvirt/src/xen_internal.h,v
retrieving revision 1.29
diff -u -p -r1.29 xen_internal.h
--- src/xen_internal.h 20 Aug 2008 20:48:36 - 1.29
+++ src/xen_internal.h 28 Aug 2008 15:38:05 -
@@ -17,7 +17,7 @@
extern struct xenUnifiedDriver xenHypervisorDriver;
intxenHypervisorInit (void);
-virCapsPtr xenHypervisorMakeCapabilities (void);
+virCapsPtr xenHypervisorMakeCapabilities (virConnectPtr conn);
/* The following calls are made directly by the Xen proxy: */
@@ -38,7 +38,8 @@ int xenHypervisorClose (virConnectPtr c
intxenHypervisorGetVersion (virConnectPtr conn,
unsigned long *hvVer);
virCapsPtr
-xenHypervisorMakeCapabilitiesInternal(const char *hostmachine,
+xenHypervisorMakeCapabilitiesInternal(virConnectPtr conn,
+ const char *hostmachine,
FILE *cpuinfo,
FILE *capabilities);
char *
Index: src/xen_unified.c
===
RCS file: /data/cvs/libvirt/src/xen_unified.c,v
retrieving revision 1.53
diff -u -p -r1.53 xen_unified.c
--- src/xen_unified.c 20 Aug 2008 20:48:36 - 1.53
+++ src/xen_unified.c 28 Aug 2008 15:38:05 -
@@ -333,7 +333,7 @@ xenUnifiedOpen (virConnectPtr conn, xmlU
}
}
-if (!(priv-caps = xenHypervisorMakeCapabilities())) {
+if (!(priv-caps = xenHypervisorMakeCapabilities(conn))) {
DEBUG0(Failed to make capabilities);
goto fail;
}
Index: tests/xencapstest.c
===
RCS file: /data/cvs/libvirt/tests/xencapstest.c,v
retrieving revision 1.14
diff -u -p -r1.14 xencapstest.c
--- tests/xencapstest.c 25 Jul 2008 13:17:27 - 1.14
+++ tests/xencapstest.c 28 Aug 2008 15:38:05 -
@@ -49,7 +49,7 @@ static int testCompareFiles(const char
Re: [libvirt] A laundry list of TODO items for libvirt
On Thu, Aug 28, 2008 at 04:30:55PM +0100, Richard W.M. Jones wrote: On Thu, Aug 28, 2008 at 10:58:34AM -0400, Cole Robinson wrote: Last month you had brought up the idea of a unified api call to lookup all domains, with a flag option to filter the lookup by domain state: https://www.redhat.com/archives/libvir-list/2008-July/msg00215.html It's worth making clear that the key issue isn't the filtering, but the fact that the virConnectListDomains virDomainLookupByID calls would be combined. This is a big saving in the remote case too because it turns 1+N round-trips into 1 round-trip. Virt-manager and virt-top both make these 1+N calls frequently (as in, once a second, and once every 3 seconds respectively). Yes, this is a huge performance win when talking to XenD since each XenD RPC call to list domains is ~ 0.5-1 second or worse. Also, if we use the __virDrvSupportsFeature call then we can actually emulate it in src/libvirt.c for drivers / libvirtd instances which don't understand the new call. This means that applications can use the new call immediately, with confidence that it will work for all cases. Good idea - that hadn't occurred to me - it'll be useful for talking to old libvirtd instances at the very least - implementing the new style for built-in drivers should be trivial already. Daniel -- |: Red Hat, Engineering, London -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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvir: Xen error
Thank you Richard. On 8/27/08, Richard W.M. Jones [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 02:30:37PM -0500, mantra UNIX wrote: Hello everyone, I get the following error when i try to redtart a domain; # virsh list libvir: Xen error : Domain not found: xenUnifiedDomainLookupByID I am using RHEL5.2 on i386, I have searched for the error on web and on RedHat but could not find any. The bug report is a bit unclear. How did you restart the domain? (eg. from inside the guest? using a virsh command?) Did you wait after restarting the domain? Can you also post the output of: xm list --long Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Regards, mantra - Instrument of Thought -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] A laundry list of TODO items for libvirt
Does host power support belong on the TODO?
(i.e. virConnect{Poweroff,Suspend,Hibernate,Reboot})
If libvirt is going to be the only external interface used to manage a
virtualized host, it must be able to poweroff, suspend, (hibernate?),
and reboot the host. (For hosts that support IPMI/iLO or other power
control interfaces, this isn't necessary, but there are plenty of hosts
that don't support any of this.)
Dave
On Thu, 2008-08-28 at 15:45 +0100, Daniel P. Berrange wrote:
A bunch of us at Red Hat had a bit of a brainstorming session to make a
list of things we'd like to see added to libvirt going forward, to better
support our needs for virtualization in Fedora / oVirt. We've put details
of everything up on the libvirt wiki:
http://wiki.libvirt.org/page/Todo
This list isn't a firm commitment to actually implement these features.
We may later decide that some of them don't belong in libvirt (eg, the
question of allowing multiu-thread access to virConnectPtr is open to
debate). Nor have we got people actually working on these items - unless
explicitly noted against a todo item. If anyone is looking to do work
on libvirt and isn't sure of what to work on, this list may be of interest.
Also, this is a wiki, so feel free to add more ideas - or add expanded
details to existing ideas. Or reply to this mail, and one of us will
add new ideas to the wiki for you
The only request is that you don't actually start implementing things from
the list without first discussing proposals on this list, because most of
these ideas need more design / analysis before its reasonable to write
code
Regards,
Daniel
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] A laundry list of TODO items for libvirt
On Thu, Aug 28, 2008 at 05:02:29PM -0400, David Lively wrote:
Does host power support belong on the TODO?
(i.e. ??virConnect{Poweroff,Suspend,Hibernate,Reboot})
???If libvirt is going to be the only external interface used to manage a
virtualized host, it must be able to poweroff, suspend, (hibernate?),
and reboot the host. (For hosts that support IPMI/iLO or other power
control interfaces, this isn't necessary, but there are plenty of hosts
that don't support any of this.)
This is an interesting question - I honestly can't say whether this should
be within our scope or not. With things like poweroff, the application
requesting the poweroff may well want some form of confirmation or
guarentee. This takes you into the realm of fencing / clustering software
which can provide these kind of capabilities.
Daniel
--
|: Red Hat, Engineering, London -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 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 4/4: Add pivot_root support to container
On Thu, Aug 28, 2008 at 06:31:31AM -0700, Dan Smith wrote: DB I found a couple of other places with missing lxcError() calls. So DB here's an updated patch Looks good to me. Thanks! Ok, I've finally committed this Daniel -- |: Red Hat, Engineering, London -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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH]Fix minor issues in logical storage backend
Hi All!
I came across some problems trying to create a new LVM-based storage
pool using this config
pool type=logical
nametest_vg/name
source
device path=/dev/sdb1/
/source
target
path/dev/test_vg/path
/target
/pool
Volume group did not previously exist so I did
virsh pool-define above.xml
virsh pool-build test_vg
pool-build failed since the backend logical storage driver does not have
VIR_STORAGE_BACKEND_POOL_SOURCE_DEVICE set in flags. Without this flag
set, the device element is never parsed in virStoragePoolDefParseDoc()
(storage_conf.c), causing pvcreate to fail since no physical volume is
specified.
After this problem was memory corruption cause by miscalculating the
size of vgcreate command line :-).
This patch fixes both issues.
Regards,
Jim
Index: src/storage_backend_logical.c
===
RCS file: /data/cvs/libvirt/src/storage_backend_logical.c,v
retrieving revision 1.11
diff -u -r1.11 storage_backend_logical.c
--- src/storage_backend_logical.c 27 Aug 2008 20:05:59 - 1.11
+++ src/storage_backend_logical.c 28 Aug 2008 23:58:54 -
@@ -351,7 +351,7 @@
memset(zeros, 0, sizeof(zeros));
/* XXX multiple pvs */
-if (VIR_ALLOC_N(vgargv, 1) 0) {
+if (VIR_ALLOC_N(vgargv, 3 + pool-def-source.ndevice) 0) {
virStorageReportError(conn, VIR_ERR_NO_MEMORY, %s, _(command line));
return -1;
}
@@ -618,6 +618,7 @@
.deleteVol = virStorageBackendLogicalDeleteVol,
.poolOptions = {
+.flags = (VIR_STORAGE_BACKEND_POOL_SOURCE_DEVICE),
.formatFromString = virStorageBackendLogicalPoolFormatFromString,
.formatToString = virStorageBackendLogicalPoolFormatToString,
},
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Problems using libvirt (linking errors)
Johannes Formann [EMAIL PROTECTED] wrote: Atsushi SAKAI [EMAIL PROTECTED] wrote: Hi, I guess You are missing linking libvirt. What do you mean, would it be autmoticaly linked like other librarys in /usr/lib? (sorry, I'm not a c/c++ expert) Thanks for the hint, after a bit googeling setting LDFLAGS and runnig the ./configure script solved the problem. regards Johannes -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
