Re: [Libvir] [PATCH] lxc: start domain
On Thu, Mar 27, 2008 at 02:50:20PM -0700, Dave Leskovec wrote:
> Daniel Veillard wrote:
> >> +int execStringLen = strlen(vmDef->init) + 1 + 5;
> >> +strcpy(execString, "exec ");
> >> +strcat(execString, vmDef->init);
> >
> > Hum, it seems there is an off by one allocation error, you don't allocate
> > the space for the terminating 0
>
> A comment probably would have helped here :-) the + 1 up there in setting the
> execStringLen is for the NULL.
Oops, for some reason I counted 5 for 'exec', ahum :-)
[...]
> >> +vm->def->id = vm->pid;
> >> +lxcSaveConfig(NULL, driver, vm, vm->def);
> >
> > We should make sure at some point taht there is some kind of locking
> > mechanism when creating those config files, no ?
>
> Good question. Right now libvirtd should be the only process accessing the
> file. Is it multi-threaded that would cause collisions? The other
> possibility
> is if we found we needed to save the config file from within the container.
> That's not currently the case and I'd stay away from that if at all possible.
Okay, then that's not needed, fine by me :-)
> > [...]
> >
> > Hum, now that config names are saved based on domain names, wouldn't
> > it be better to use a name based lookup ? Less precise but more direct
>
> Not sure what you're referring to here. name based lookup for what?
Hum, wrong part quoted, it's about lxcDomainStart() just below:
:+static int lxcDomainStart(virDomainPtr dom)
:+{
:+int rc = -1;
:+virConnectPtr conn = dom->conn;
:+lxc_driver_t *driver = (lxc_driver_t *)(conn->privateData);
:+lxc_vm_t *vm = lxcFindVMByUUID(driver, dom->uuid);
:+
> > Looks fine overall. I wonder if 1 fork/clone per container can't be
> > reduced to a single process doing the fd processing for all the containers
> > running. But that's probably harder, more fragile and for little gain.
>
> Yes, that's been tossed around. I'm holding off pursuing that for now until
> devpts namespace and it's impacts are known.
Okay, just wondering :-)
thanks !
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] PHP bindings for libvirt API?
On Thu, Mar 27, 2008 at 02:23:28PM +0100, BrunoM wrote: > Does anyone have information about a mean to plug libvirt into PHP? Maybe > we could just issue shell commands to "virsh", but it would be preferable > to have direct access to the API. It's been asked before and I guess it is the next major language to support from libvirt. However unless someone starts a project to write these bindings it won't happen. Rich. -- 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 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 2/9] xenXMError: mark for translation string args to this function
+1 -- 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: [Libvir] [PATCH 3/9] ReportError: mark for translation string args to this function
Simple enough, +1 -- 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: [Libvir] [PATCH 5/9] Convert diagnostics like "VAR > MAX_VAR" to translatable messages.
+1. I think this nicely solves the problem of those messages which I thought were untranslatable before. Rich. -- 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 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 6/9] error: mark most string arguments for translation
+1 -- 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: [Libvir] [PATCH 7/9] openvzLog: mark its string arguments for translation
+1 -- 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 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 8/9] testError: mark most string arguments for translation
On Wed, Mar 26, 2008 at 08:57:56PM +0100, Jim Meyering wrote: > -# Uncomment this after adjusting remaining diagnostics to be translatable. > +# Uncomment the following and run "make syntax-check" to see diagnostics > +# that are not yet marked for translation, but that need to be rewritten > +# so that they are translatable. > # msg_gen_function += error Any reason why we don't want these uncommented all the time? +1, simple enough change. Rich. -- 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 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 9/9] lxcError: mark a string and add to the list of nearly-checked functions
+1, simple. 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: [Libvir] [PATCH 4/9] qemudReportError: mark for translation string args to this function
On Wed, Mar 26, 2008 at 08:55:53PM +0100, Jim Meyering wrote:
> qemudReportError(NULL, NULL, NULL, VIR_ERR_NO_MEMORY,
> - "vncTLSx509certdir");
> + "%s", _("failed to allocate
> vncTLSx509certdir"));
versus:
> qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
> - "Cannot find QEMU binary %s: %s", binary,
> + _("Cannot find QEMU binary %s: %s"), binary,
> strerror(errno));
I assume that the problem with the first one is that gettext might
erroneously return a string containing % sequences, resulting in a
runtime failure or even exploit. But that could also be a problem
with the second one too, surely? (ie. gettext might return three or
more % sequences).
OCaml gettext offers two forms of the gettext function, one for plain
strings and one for format strings[1]. The format string version
checks that any % sequences in the translated string are compatible
with those in the original string. (If not then the original string
is returned to avoid any exploit). Sounds as if we need a similar
feature in C gettext. A cursory check of the info file didn't show
anything like this.
Rich.
[1] and of course the powerful type system ensures that you always use
the correct form, ho hum ...
--
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
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 1/9] Mark many more strings for translation.
+1 -- 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: [Libvir] [PATCH 8/9] testError: mark most string arguments for translation
"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote: > On Wed, Mar 26, 2008 at 08:57:56PM +0100, Jim Meyering wrote: >> -# Uncomment this after adjusting remaining diagnostics to be translatable. >> +# Uncomment the following and run "make syntax-check" to see diagnostics >> +# that are not yet marked for translation, but that need to be rewritten >> +# so that they are translatable. >> # msg_gen_function += error > > Any reason why we don't want these uncommented all the time? This is just an interim thing. It's to keep "make syntax-check" from failing, while we wait for someone to find the energy to fix the currently-not-so-translatable diagnostics and mark them. The idea is that anyone who is interested can uncomment a single function name, run "make syntax-check" to see the list of unmarked and untranslatable diagnostics associated with that name, and (with enough fortitude ;-) convert them all to marked-and-translatable strings. Until then, any new unmarked string args to that name are not going to be checked. An alternative is simply to mark the untranslatable strings, but if we do that, they'll probably never be rewritten, and that's not a service to translators or user. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 4/9] qemudReportError: mark for translation string args to this function
"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 26, 2008 at 08:55:53PM +0100, Jim Meyering wrote:
>> qemudReportError(NULL, NULL, NULL, VIR_ERR_NO_MEMORY,
>> - "vncTLSx509certdir");
>> + "%s", _("failed to allocate
>> vncTLSx509certdir"));
>
> versus:
>
>> qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
>> - "Cannot find QEMU binary %s: %s", binary,
>> + _("Cannot find QEMU binary %s: %s"), binary,
>> strerror(errno));
>
> I assume that the problem with the first one is that gettext might
> erroneously return a string containing % sequences, resulting in a
> runtime failure or even exploit. But that could also be a problem
> with the second one too, surely? (ie. gettext might return three or
> more % sequences).
Right.
But there's nothing we can do about the latter, and there *is* something
we can do about the former: precede with "%s". Of course, gettext tools
like msgmerge are careful to ensure that %-directives in translations
match those in the original, so it's not a problem, in general.
> OCaml gettext offers two forms of the gettext function, one for plain
> strings and one for format strings[1]. The format string version
> checks that any % sequences in the translated string are compatible
> with those in the original string. (If not then the original string
> is returned to avoid any exploit). Sounds as if we need a similar
Nice.
> feature in C gettext. A cursory check of the info file didn't show
> anything like this.
>
> Rich.
>
> [1] and of course the powerful type system ensures that you always use
> the correct form, ho hum ...
;-)
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 4/9] qemudReportError: mark for translation string args to this function
On Fri, Mar 28, 2008 at 12:15:04PM +0100, Jim Meyering wrote:
> But there's nothing we can do about the latter, and there *is* something
> we can do about the former: precede with "%s". Of course, gettext tools
> like msgmerge are careful to ensure that %-directives in translations
> match those in the original, so it's not a problem, in general.
Does msgmerge distinguish between ordinary strings and format strings,
eg. puts (_("SQL lets you write LIKE '%string%'")); ?
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: [Libvir] [PATCH 4/9] qemudReportError: mark for translation string args to this function
"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 28, 2008 at 12:15:04PM +0100, Jim Meyering wrote:
>> But there's nothing we can do about the latter, and there *is* something
>> we can do about the former: precede with "%s". Of course, gettext tools
>> like msgmerge are careful to ensure that %-directives in translations
>> match those in the original, so it's not a problem, in general.
>
> Does msgmerge distinguish between ordinary strings and format strings,
> eg. puts (_("SQL lets you write LIKE '%string%'")); ?
Yes, though actually it's xgettext that does the checking,
and you tell it which functions take format strings and how.
Here's part of coreutils' bootstrap.conf:
# Additional xgettext options to use. Use "\\\newline" to break lines.
XGETTEXT_OPTIONS=$XGETTEXT_OPTIONS'\\\
--from-code=UTF-8\\\
--flag=asprintf:2:c-format\\\
--flag=asnprintf:3:c-format\\\
--flag=error:3:c-format\\\
--flag=error_at_line:5:c-format\\\
--flag=vasprintf:2:c-format\\\
--flag=vasnprintf:3:c-format\\\
--flag=wrapf:1:c-format\\\
--flag=xasprintf:1:c-format\\\
--flag=xfprintf:2:c-format\\\
--flag=xprintf:1:c-format\\\
'
libvirt could use something similar.
This is yet another reason to try to avoid adding a
new error-printing function per subsystem.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Lxc driver patch
Patch against CVS version, it tries to avoid 2 issues:
- problem with global data settings when loading of the driver got
interrupted. Check more NULLs and reset to NULL, i was getting crashes
when running the regression tests and the /etc/libvirtd/lxc was not
accessible.
- avoid trying to open the driver if not running as root, that's not
a problem in normal case because the daemon runs as root, but
when running 'make check' as a normal user libvirtd is run as an
user and compiling the lxc driver in would break the regression tests
Dave could you double-check this, hopefully it has no side effect ?
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Index: src/lxc_driver.c
===
RCS file: /data/cvs/libxen/src/lxc_driver.c,v
retrieving revision 1.2
diff -p -r1.2 lxc_driver.c
*** src/lxc_driver.c27 Mar 2008 09:34:06 - 1.2
--- src/lxc_driver.c28 Mar 2008 12:53:14 -
***
*** 61,67
static int lxcStartup(void);
static int lxcShutdown(void);
! static lxc_driver_t *lxc_driver;
/* Functions */
static int lxcDummyChild( void *argv ATTRIBUTE_UNUSED )
--- 61,67
static int lxcStartup(void);
static int lxcShutdown(void);
! static lxc_driver_t *lxc_driver = NULL;
/* Functions */
static int lxcDummyChild( void *argv ATTRIBUTE_UNUSED )
*** static char *lxcDomainDumpXML(virDomainP
*** 378,383
--- 378,390
static int lxcStartup(void)
{
+ uid_t uid = getuid();
+
+ /* Check that the user is root */
+ if (0 != uid) {
+ return -1;
+ }
+
lxc_driver = calloc(1, sizeof(lxc_driver_t));
if (NULL == lxc_driver) {
return -1;
*** static void lxcFreeDriver(lxc_driver_t *
*** 412,422
static int lxcShutdown(void)
{
! lxc_vm_t *vms = lxc_driver->vms;
!
! lxcFreeVMs(vms);
lxc_driver->vms = NULL;
lxcFreeDriver(lxc_driver);
return 0;
}
--- 419,430
static int lxcShutdown(void)
{
! if (lxc_driver == NULL)
! return(NULL);
! lxcFreeVMs(lxc_driver->vms);
lxc_driver->vms = NULL;
lxcFreeDriver(lxc_driver);
+ lxc_driver = NULL;
return 0;
}
*** static int lxcShutdown(void)
*** 430,435
--- 438,445
*/
static int
lxcActive(void) {
+ if (lxc_driver == NULL)
+ return(0);
/* If we've any active networks or guests, then we
* mark this driver as active
*/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Lxc conf patch
Okay, that's something i promised last week, but it has some significant
changes:
- cleanup the XPath methods to access the XML informations, reusing the
existing methods from xml.h
- make string fields from __lxc_vm_def dynamic (except the UUID)
- fix what looked like a funny leak situation when vm def structures were
deallocated (see changes around lxcFreeVM/lxcFreeVMs/lxcFreeVMDef),
i hope i didn't overlooked something but valgrind seems happy now leak
wise.
Overall it looks a bit simpler to me :-)
Valgrind only report left is
==1== Invalid write of size 4
==1==at 0x470C8C: lxcCheckContainerSupport (lxc_driver.c:91)
==1== Address 0xFFEC is not stack'd, malloc'd or (recently) free'd
==1==
==1== Process terminating with default action of signal 11 (SIGSEGV)
==1== Access not within mapped region at address 0xFFEC
==1==at 0x470C8C: lxcCheckContainerSupport (lxc_driver.c:91)
which is related to the probe code of the driver
---
stack = malloc(getpagesize() * 4);
if(!stack) {
DEBUG0("Unable to allocate stack");
rc = -1;
goto check_complete;
}
childStack = stack + (getpagesize() * 4);
cpid = clone(lxcDummyChild, childStack, flags, NULL);
---
I would assume it's valgrind being a bit pedantic because we pass the address
just over the allocated stack limit, which should be fine since stack is
addressed in predecrementing mode (BTW isn't that a portability bug in the
code stack direction should probably be checked no ?). Still maybe it's a
good idea to pass a pointer in the allocated area ...
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Index: src/lxc_conf.c
===
RCS file: /data/cvs/libxen/src/lxc_conf.c,v
retrieving revision 1.3
diff -p -r1.3 lxc_conf.c
*** src/lxc_conf.c 27 Mar 2008 14:02:57 - 1.3
--- src/lxc_conf.c 28 Mar 2008 13:29:58 -
***
*** 41,46
--- 41,47
#include "buf.h"
#include "util.h"
#include "uuid.h"
+ #include "xml.h"
#include "lxc_conf.h"
*** void lxcError(virConnectPtr conn, virDom
*** 70,87
codeErrorMessage, errorMessage);
}
- static inline int lxcIsEmptyXPathStringObj(xmlXPathObjectPtr xpathObj)
- {
- if ((xpathObj == NULL) ||
- (xpathObj->type != XPATH_STRING) ||
- (xpathObj->stringval == NULL) ||
- (xpathObj->stringval[0] == 0)) {
- return 1;
- } else {
- return 0;
- }
- }
-
static int lxcParseMountXML(virConnectPtr conn, xmlNodePtr nodePtr,
lxc_mount_t *lxcMount)
{
--- 71,76
*** static int lxcParseMountXML(virConnectPt
*** 92,98
int strLen;
int rc = -1;
! if (NULL == (fsType = xmlGetProp(nodePtr, BAD_CAST "type"))) {
lxcError(conn, NULL, VIR_ERR_INTERNAL_ERROR,
_("missing filesystem type"));
goto error;
--- 81,88
int strLen;
int rc = -1;
! fsType = xmlGetProp(nodePtr, BAD_CAST "type");
! if (NULL == fsType) {
lxcError(conn, NULL, VIR_ERR_INTERNAL_ERROR,
_("missing filesystem type"));
goto error;
*** static int lxcParseMountXML(virConnectPt
*** 155,160
--- 145,151
rc = 0;
error:
+ xmlFree(fsType);
xmlFree(mountSource);
xmlFree(mountTarget);
*** error:
*** 164,218
static int lxcParseDomainName(virConnectPtr conn, char **name,
xmlXPathContextPtr contextPtr)
{
! int rc = -1;
! xmlXPathObjectPtr xpathObj = NULL;
! xpathObj = xmlXPathEval(BAD_CAST "string(/domain/name[1])", contextPtr);
! if (lxcIsEmptyXPathStringObj(xpathObj)) {
lxcError(conn, NULL, VIR_ERR_NO_NAME, NULL);
! goto parse_complete;
}
! *name = strdup((const char *)xpathObj->stringval);
! if (NULL == *name) {
! lxcError(conn, NULL, VIR_ERR_NO_MEMORY, NULL);
! goto parse_complete;
! }
!
!
! rc = 0;
!
! parse_complete:
! xmlXPathFreeObject(xpathObj);
! return rc;
}
static int lxcParseDomainUUID(virConnectPtr conn, unsigned char *uuid,
xmlXPathContextPtr contextPtr)
{
! int rc = -1;
! xmlXPathObjectPtr xpathObj = NULL;
! xpathObj = xmlXPathEval(BAD_CAST "string(/domain/uuid[1])", contextPtr);
! if (lxcIsEmptyXPathStringObj(xpathObj)) {
! if ((rc = virUUIDGenerate(uuid))) {
lxcError(conn, NULL, VIR_ERR_INTERNAL_ERROR,
! _("failed to generate uuid: %s"), stre
[Libvir] use C99 initializer for lastErr
...this makes things just a bit more readable.
-- Guido
---
src/virterror.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/virterror.c b/src/virterror.c
index 1e39be4..1463129 100644
--- a/src/virterror.c
+++ b/src/virterror.c
@@ -19,7 +19,9 @@
#include "internal.h"
static virError lastErr = /* the last error */
-{ 0, 0, NULL, VIR_ERR_NONE, NULL, NULL, NULL, NULL, NULL, 0, 0, NULL };
+{ .code = 0, .domain = 0, .message = NULL, .level = VIR_ERR_NONE,
+ .conn = NULL, .dom = NULL, .str1 = NULL, .str2 = NULL, .str3 = NULL,
+ .int1 = 0, .int2 = 0, .net = NULL };
static virErrorFunc virErrorHandler = NULL; /* global error handler */
static void *virUserData = NULL;/* associated data */
--
1.5.4.4
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH/RFC] remote driver uses already freed dom
Hi,
when trying to undefine a running qemu domain the domain name gets
corrupted:
$ ./virsh undefine system1
Name: /�em1
libvir: QEMU error /�em1: internal error cannot delete active domain
error: Failed to undefine domain system1
the reaseon is that in qemud/remote.c the domain is freed after failure:
remoteDispatchDomainUndefine (struct qemud_server *server ATTRIBUTE_UNUSED,
...
{
...
if (virDomainUndefine (dom) == -1) {
virDomainFree(dom);
return -1;
}
...
}
This doesn't work out since remoteDispatchClient accesses the dom
structure that was stored in the virtErrorPtr structure to report the
error back to the client (This is just an example and hits any error
path of functions in remote_dispatch_proc_switch.h that reference dom).
There are two possible solutions I see: move the virtDomainFree down to
the bottom of remoteDispatchClient or deep copy the dom structure in
virDefaultErrorFunc. A patch for the later is attached since similar
things seem to be possible in other drivers too.
-- Guido
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH] deep copy dom structure
---
src/virterror.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/virterror.c b/src/virterror.c
index 1463129..49f3b89 100644
--- a/src/virterror.c
+++ b/src/virterror.c
@@ -115,6 +115,11 @@ virResetError(virErrorPtr err)
free(err->str1);
free(err->str2);
free(err->str3);
+if(err->dom) {
+if(err->dom->name)
+free(err->dom->name);
+free(err->dom);
+}
memset(err, 0, sizeof(virError));
}
@@ -383,6 +388,15 @@ __virRaiseError(virConnectPtr conn, virDomainPtr dom,
virNetworkPtr net,
virResetError(to);
to->conn = conn;
to->dom = dom;
+if (dom) {
+if (!(to->dom = malloc(sizeof(virDomain {
+fprintf(stderr, "cannot allocate memory in %s", __FUNCTION__);
+} else {
+to->dom->name = strdup(dom->name);
+memcpy (to->dom->uuid, dom->uuid, VIR_UUID_BUFLEN);
+to->dom->id = dom->id;
+}
+}
to->net = net;
to->domain = domain;
to->code = code;
--
1.5.4.4
--45Z9DzgjV8m4Oswq--
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH/RFC] remote driver uses already freed dom
...and here's the patch attached again. It seems mailman stripped the
attachment and the original mail into two parts because of the git
headers.
-- Guido
---
src/virterror.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/virterror.c b/src/virterror.c
index 1463129..49f3b89 100644
--- a/src/virterror.c
+++ b/src/virterror.c
@@ -115,6 +115,11 @@ virResetError(virErrorPtr err)
free(err->str1);
free(err->str2);
free(err->str3);
+if(err->dom) {
+if(err->dom->name)
+free(err->dom->name);
+free(err->dom);
+}
memset(err, 0, sizeof(virError));
}
@@ -383,6 +388,15 @@ __virRaiseError(virConnectPtr conn, virDomainPtr dom, virNetworkPtr net,
virResetError(to);
to->conn = conn;
to->dom = dom;
+if (dom) {
+if (!(to->dom = malloc(sizeof(virDomain {
+fprintf(stderr, "cannot allocate memory in %s", __FUNCTION__);
+} else {
+to->dom->name = strdup(dom->name);
+memcpy (to->dom->uuid, dom->uuid, VIR_UUID_BUFLEN);
+to->dom->id = dom->id;
+}
+}
to->net = net;
to->domain = domain;
to->code = code;
--
1.5.4.4
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] ruby binding patch
Hi Vadim, thanks a lot for the patch. First off, can you send patches in the future as text patches, either attached or inline[1] ? I was able to apply your hg bundle though. On Thu, 2008-03-27 at 23:59 -0700, Vadim Zaliva wrote: > I have attempted to add following methods to Domain class: > > 1. vcpus= > 2. memory= > > This is my first patch to libvirt-ruby, and I will appreciate your > feedback. > My next goal is to add binding for virDomainPinVcpu() method. The patch overall looks good, and I committed it. There were some minor nits: * libvirt_dom_memory_set called virDomainSetMaxMemory instead of virDomainSetMemory (probably cut&paste error) * there were no tests for the two new methods. In general, try to add/expand the tests in tests/tc_connect.rb when you add to the bindings, though that is highly dependent on what the test driver supports. In this case though it was pretty easy. Thanks again for doing this, and I am looking forward to the virDomainPinVcpu patch. David [1] the hg patchbomb extension makes that very easy: http://hgbook.red-bean.com/hgbookch14.html#x18-32100014.4 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] Patch for routed virtual networks
On Tue, Mar 25, 2008 at 12:56:31PM +0100, Mads Chr. Olesen wrote: > > man, 24 03 2008 kl. 19:00 +, skrev Daniel P. Berrange: > > > > On Mon, Mar 24, 2008 at 10:52:41AM +0100, Mads Chr. Olesen wrote: > > > Anything further I can do to help get this patch commited? > > > > > > I have been running with it, without problems across restarts, etc., > > for > > > a couple of weeks now. > > > > I still don't see where the routing rules are defined / take place > > with this setup. There must be rules somewhere specifying the routing > > for the subnet 78.47.YYY.YYY/30, but its not being done in your > > patchset AFAICT > > Do you mean entries in the routing table, or? > > This is my routing table: > > $ route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse Iface > 78.47.YYY.YYY 0.0.0.0 255.255.255.248 U 0 00 > virsubnetbr0 > 85.10.XXX.0 0.0.0.0 255.255.255.224 U 0 00 eth0 > 0.0.0.0 85.10.XXX.1 0.0.0.0 UG10000 eth0 Ok, so this takes care of letting the hsot correctly route guest traffic off the box. The local LAN router still also needs to have routing table setup to ensure other physical hosts can reach the guests. So, this patch is sufficient in this regard & I've committed it to CVS. In theory I think it might be possible to avoid the need to configure the local LAN router, by messing with proxy_arp, but I've not got it to work so far. Dan. -- |: 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] ruby binding patch
On Mar 28, 2008, at 10:48, David Lutterkort wrote:
* there were no tests for the two new methods. In general, try to
add/expand the tests in tests/tc_connect.rb when you add to the
bindings, though that is highly dependent on what the test
driver supports. In this case though it was pretty easy.
Thanks again for doing this, and I am looking forward to the
virDomainPinVcpu patch.
Attached is a patch, implementing Domain.pin_vcpu method.
I have tested it locally and it works. Here is my test code:
require 'libvirt'
conn = Libvirt::open("")
dom = conn.lookup_domain_by_name("centos52")
dom.pin_vcpu(0,[2,3])
After running it, I can verify via virsh that it does pin CPUs
correctly:
virsh > vcpuinfo centos52
VCPU: 0
CPU:2
State: blocked
CPU time: 40.8s
CPU Affinity: --yy
However, when I try this method from test/tc_connect.rb it fails:
# rake test
(in /home/lord/src/ruby-libvirt)
Loaded suite /usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake/
rake_test_loader
Started
libvir: error : this function is not supported by the hypervisor:
virDomainPinVcpu
E
Finished in 0.006319 seconds.
1) Error:
test_domain(TestConnect):
SystemCallError: unknown error - libvir call virDomainPinVcpu failed
./tests/tc_connect.rb:113:in `pin_vcpu'
./tests/tc_connect.rb:113:in `test_domain'
5 tests, 60 assertions, 0 failures, 1 errors
rake aborted!
Command failed with status (1): [/usr/bin/ruby -Ilib:ext/libvirt "/usr/
lib/...]
(See full trace by running task with --trace)
I will appreciate if somebody could help me to figure out why it is
happening.
I might need to implement couple more methods, so if there are any
remarks on
my code, I will appreciate your feedback.
Sincerely,
Vadim
pin_vcpu.patch
Description: Binary data
--
"La perfection est atteinte non quand il ne reste rien a ajouter, mais
quand il ne reste rien a enlever." (Antoine de Saint-Exupery)
smime.p7s
Description: S/MIME cryptographic signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
