Re: [libvirt] Segfault in event-test.c example
by pspreadborough＠comcast.net
----- pspreadborough(a)comcast.net wrote:
> ----- "Matthias Bolte" <matthias.bolte(a)googlemail.com> wrote:
>
> > 2010/1/11 <pspreadborough(a)comcast.net>:
> > >
> > > ----- "Matthias Bolte" <matthias.bolte(a)googlemail.com> wrote:
> > >
> > >> 2010/1/10 <pspreadborough(a)comcast.net>:
> > >> >
> > >> > ----- "Matthias Bolte" <matthias.bolte(a)googlemail.com> wrote:
> > >> >
> > >> >> 2010/1/10 <pspreadborough(a)comcast.net>:
> > >> >> >
> > >> >> > Hello,
> > >> >> >
> > >> >> > I have been trying to use the domain event C code example
> but
> > >> >> > unfortunately it segfaults (signal 11) every time I run it:
> > >> >> >
> > >> >> > [root@Spring events-c]# ./event-test
> > >> >> > myEventAddHandleFunc:221: Add handle 5 1 0xf081a0 0x8f727f8
> > >> >> > myEventAddHandleFunc:221: Add handle 7 1 0xf09990 0x8f727f8
> > >> >> > myEventAddHandleFunc:221: Add handle 8 1 0xed7940 0x8f727f8
> > >> >> > myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0
> > 0x8f727f8
> > >> >> > myEventAddHandleFunc:221: Add handle 11 1 0xed7940 0x8f727f8
> > >> >> > myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0
> > 0x8f727f8
> > >> >> > main:322 :: Registering domain event cbs
> > >> >> > Segmentation fault (core dumped)
> > >> >> >
> > >> >> > Core was generated by
> > >> >> >
> > >> >>
> > >>
> >
> `/root/libvirt-0.7.5/examples/domain-events/events-c/.libs/lt-event-test'.
> > >> >> > Program terminated with signal 11, Segmentation fault.
> > >> >> > [New process 21806]
> > >> >> > [New process 21822]
> > >> >> > #0 remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8)
> > at
> > >> >> > remote/remote_driver.c:8720
> > >> >> > 8720 tempQueue.count = priv->domainEvents->count;
> > >> >> > (gdb) bt
> > >> >> > #0 remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8)
> > at
> > >> >> > remote/remote_driver.c:8720
> > >> >> > #1 0x080490d3 in main (argc=Cannot access memory at address
> > 0x1
> > >> >> > ) at event-test.c:347
> > >> >> >
> > >> >> > The stack looks corrupted so I'm doubtful that this trace if
> > of
> > >> much
> > >> >> value.
> > >> >> > I have built
> > >> >> > and installed libvirt-0.7.5 and it and it's tools seem to be
> > >> >> operating
> > >> >> > correctly.
> > >> >>
> > >> >> I tried the event-test with libvirt-0.7.5 and QEMU/Xen and
> both
> > >> are
> > >> >> working as expected. No segfaults.
> > >> >>
> > >> >> Could you inspect the values of priv and priv->domainEvents in
> > GDB
> > >> >> using 'p priv' to see if they are NULL and try to dereference
> > them
> > >> in
> > >> >> GDB using 'p *priv' to see if they point to valid memory
> areas?
> > >> >>
> > >> >> Yes the backtrace looks corrupted. If there is stack/heap
> > >> corruption
> > >> >> involved valgrind may reveal it, so try to run the event-test
> > in
> > >> >> valgrind and see if that gives any hints.
> > >> >>
> > >> >> You can also try the GIT version of libvirt. There was a
> > invalid
> > >> free
> > >> >> call (resulting in heap corruption) in the node device code
> > fixed
> > >> >> after the 0.7.5 release. But that should have no effect on the
> > >> >> event-test.
> > >> >>
> > >> >> Matthias
> > >> >
> > >> > Matthias,
> > >> >
> > >> > priv->domainEvents is NULL, here's the gdb output:
> > >>
> > >> This explains the segfault. The next question is, why is it NULL?
> > >>
> > >> > (gdb) p *priv
> > >> > $1 = {lock = {lock = {__data = {__lock = 1, __count = 0,
> __owner
> > =
> > >> 21806, __kind = 0, __nusers = 1, {__spins = 0, __list = {
> > >> > __next = 0x0}}}, __size =
> > >>
> >
> "\001\000\000\000\000\000\000\000.U\000\000\000\000\000\000\001\000\000\000\000\000\000",
> > >> > __align = 1}}, sock = 150469168, watch = 3, pid = 4,
> > uses_tls =
> > >> 1982791681, is_secure = 1815048801, session = 0x782f6269,
> > >>
> > >> Seeing uses_tls and is_secure being large numbers and knowing
> that
> > >> both are used as boolean values in the code and should have
> values
> > of
> > >> 0 or 1 make me think that priv points to already freed memory
> > here.
> > >>
> > >> > type = 0x2f646e65 <Address 0x2f646e65 out of bounds>, counter
> =
> > >> 1684956536, localUses = 1668248365,
> > >> > hostname = 0x74656b <Address 0x74656b out of bounds>, debugLog
> > =
> > >> 0x0, saslconn = 0x0, saslDecoded = 0x0, saslDecodedLength = 0,
> > >>
> > >> type and hostname are char pointers, but the seem to point into
> > >> nowhere, confirms that this is either freed memory or priv itself
> > got
> > >> overwritten due to heap corruption.
> > >>
> > >> > saslDecodedOffset = 0, saslEncoded = 0x0, saslEncodedLength =
> > 0,
> > >> saslEncodedOffset = 0,
> > >> > buffer = '\0' <repeats 68 times>,
> > >>
> >
> "n\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\bQ�\b����\030\034�\b\000\000\000\000�\033�\b\001\000\000\000\002\000\000\000�\033�\b\000\000\000\000\025|�\000\a",
> > >> '\0' <repeats 11 times>, "X\000�\b", '\0' <repeats 12 times>,
> > >> "\021\000\000\000\002\000\000\000P��\b\000\000\000\000\021", '\0'
> > >> <repeats 15 times>,
> > >>
> >
> "\021\000\000\0008\036�\b\f\000\000\000\020\000\000\000\021\000\000\000\a\000\000\000\b\000\000\000\t\000\000\000\021\000\000\000\002\000\000\000\230\034�\b\000\000\000\000A\000\000\000\003\000\000\000\001\000\000\000\001\000"...,
> > >> bufferLength = 0,
> > >> > bufferOffset = 0, callbackList = 0x0, domainEvents = 0x0,
> > >> eventFlushTimer = 0, domainEventDispatching = 1, wakeupSendFD =
> 0,
> > >> > wakeupReadFD = 0, waitDispatch = 0x0, streams = 0x0}
> > >> >
> > >> > I'll try a run with valgrind and post the results.
> > >> >
> > >> > Pete
> > >> >
> > >>
> > >> Could you test the Python version of this example found in
> > >> examples/domain-events/events-python/event-test.py? Does this
> > work?
> > >>
> > >> Otherwise lets see if valgrind gives any hints.
> > >>
> > >> Matthias
> > >
> > >
> > > During initialization I notice that the myEventAddHandleFunc()
> > method is
> > > called multiple times, each time with a different fd value (5,7,8
> > and 11).
> > > The way the code is written only the last fd value is recorded and
> > then
> > > used in the poll() call. Is this the intended? if so why are the
> > preceding
> > > fds ignored?
> > >
> > > myEventAddHandleFunc:223: Add handle 5 1 0xf13480 0x97b97d8
> > > myEventAddHandleFunc:223: Add handle 7 1 0xf14c70 0x97b97d8
> > > Allocating domainEvents:0x97c6b10
> > > myEventAddHandleFunc:223: Add handle 8 1 0xee2940 0x97b97d8
> > > myEventAddTimeoutFunc:260: Adding Timeout -1 0xee9fc0 0x97b97d8
> > > Allocating domainEvents:0x97c5780
> > > myEventAddHandleFunc:223: Add handle 11 1 0xee2940 0x97b97d8
> > > myEventAddTimeoutFunc:260: Adding Timeout -1 0xee9fc0 0x97b97d8
> > > main:333 :: Registering domain event cbs
> > >
> > >
> > > Regards,
> > >
> > > Pete
> > >
> >
> > That's strange. I can't reproduce this neither. I always get exactly
> > one call to myEventAddHandleFunc:
> >
> > myEventAddHandleFunc:221: Add handle 3 1 0x7ff116f68b00 0x1d97f00
> > myEventAddTimeoutFunc:251: Adding Timeout -1 0x7ff116f68750
> 0x1d97f00
> > main:322 :: Registering domain event cbs
> > myEventUpdateHandleFunc:232: Updated Handle 0 0
> > myEventUpdateHandleFunc:232: Updated Handle 0 1
> >
> > You could try to run the event-test in GDB and set a breakpoint on
> > myEventAddHandleFunc to see where 4 additional calls to
> > myEventAddHandleFunc come from.
> >
> > In my case I get this backtrace when setting a breakpoint on
> > myEventAddHandleFunc:
> >
> > (gdb) bt
> > #0 myEventAddHandleFunc (fd=6, event=1, cb=0x7f1be6ec3b00
> > <remoteDomainEventFired>, opaque=0xc68f00, ff=0) at event-test.c:220
> > #1 0x00007f1be6ecbaaf in doRemoteOpen (conn=0xc68f00,
> > priv=0x7f1be7350010, auth=0x0, flags=0) at
> remote/remote_driver.c:893
> > #2 0x00007f1be6ece053 in remoteOpen (conn=0xc68f00, auth=0x0,
> > flags=13007744) at remote/remote_driver.c:1076
> > #3 0x00007f1be6eb155d in do_open (name=0x7fff48400968
> > "qemu:///system", auth=0x0, flags=0) at libvirt.c:1117
> > #4 0x0000000000400eb3 in main (argc=<value optimized out>,
> > argv=<value optimized out>) at event-test.c:313
> >
> > Matthias
>
>
> Matthias
>
> Here are the four stack traces, one for each time
> myEventAddHandleFunc() was
> called.
>
> #0 myEventAddHandleFunc (fd=8, event=1, cb=0x85b480
> <xenStoreWatchEvent>, opaque=0x824a7d8, ff=0) at event-test.c:223
> #1 0x007ccf55 in virEventAddHandle (fd=8, events=1, cb=0x85b480
> <xenStoreWatchEvent>, opaque=0x824a7d8, ff=0)
> at util/event.c:45
> #2 0x0085b291 in xenStoreOpen (conn=0x824a7d8, auth=0x0, flags=<value
> optimized out>) at xen/xs_internal.c:339
> #3 0x00844287 in xenUnifiedOpen (conn=0x824a7d8, auth=0x0, flags=0)
> at xen/xen_driver.c:352
> #4 0x00811d05 in do_open (name=0xbf8c49d4 "xen:///", auth=0x0,
> flags=0) at libvirt.c:1117
> #5 0x08048e92 in main (argc=Cannot access memory at address 0x2
> ) at event-test.c:325
> (gdb) c
> Continuing.
> (gdb) b
> Note: breakpoint 1 also set at pc 0x8048bc9.
> Breakpoint 2 at 0x8048bc9: file event-test.c, line 223.
> (gdb) bt
> #0 myEventAddHandleFunc (fd=10, event=1, cb=0x85cc70
> <xenInotifyEvent>, opaque=0x824a7d8, ff=0) at event-test.c:223
> #1 0x007ccf55 in virEventAddHandle (fd=10, events=1, cb=0x85cc70
> <xenInotifyEvent>, opaque=0x824a7d8, ff=0) at util/event.c:45
> #2 0x0085c827 in xenInotifyOpen (conn=0x824a7d8, auth=0x0, flags=0)
> at xen/xen_inotify.c:460
> #3 0x008444f1 in xenUnifiedOpen (conn=0x824a7d8, auth=0x0, flags=0)
> at xen/xen_driver.c:391
> #4 0x00811d05 in do_open (name=0xbf8c49d4 "xen:///", auth=0x0,
> flags=0) at libvirt.c:1117
> #5 0x08048e92 in main (argc=Cannot access memory at address 0x1
> ) at event-test.c:325
> (gdb) c
> Continuing.
> (gdb) bt
> #0 myEventAddHandleFunc (fd=11, event=1, cb=0x82a940
> <remoteDomainEventFired>, opaque=0x824a7d8, ff=0) at event-test.c:223
> #1 0x007ccf55 in virEventAddHandle (fd=11, events=1, cb=0x82a940
> <remoteDomainEventFired>, opaque=0x824a7d8, ff=0)
> at util/event.c:45
> #2 0x0082c478 in doRemoteOpen (conn=0x824a7d8, priv=0xb7534008,
> auth=0x0, flags=0) at remote/remote_driver.c:894
> #3 0x00830448 in remoteOpenSecondaryDriver (conn=0x824a7d8, auth=0x0,
> flags=0, priv=0xbf8c2668) at remote/remote_driver.c:1006
> #4 0x0083082a in remoteNetworkOpen (conn=0x824a7d8, auth=0x0,
> flags=0) at remote/remote_driver.c:3549
> #5 0x00811e2f in do_open (name=0xbf8c49d4 "xen:///", auth=0x0,
> flags=0) at libvirt.c:1137
> #6 0x08048e92 in main (argc=1, argv=0xbf8c28b4) at event-test.c:325
> (gdb) c
> Continuing.
> (gdb) bt
> #0 myEventAddHandleFunc (fd=14, event=1, cb=0x82a940
> <remoteDomainEventFired>, opaque=0x824a7d8, ff=0) at event-test.c:223
> #1 0x007ccf55 in virEventAddHandle (fd=14, events=1, cb=0x82a940
> <remoteDomainEventFired>, opaque=0x824a7d8, ff=0)
> at util/event.c:45
> #2 0x0082c478 in doRemoteOpen (conn=0x824a7d8, priv=0x8258ab0,
> auth=0x0, flags=0) at remote/remote_driver.c:894
> #3 0x00830448 in remoteOpenSecondaryDriver (conn=0x824a7d8, auth=0x0,
> flags=0, priv=0xbf8c2668) at remote/remote_driver.c:1006
> #4 0x0083078a in remoteInterfaceOpen (conn=0x824a7d8, auth=0x0,
> flags=0) at remote/remote_driver.c:4104
> #5 0x00811f4e in do_open (name=0xbf8c49d4 "xen:///", auth=0x0,
> flags=0) at libvirt.c:1156
> #6 0x08048e92 in main (argc=1, argv=0xbf8c28b4) at event-test.c:325
>
> Regards,
>
> Pete
>
>
> --
> Libvir-list mailing list
> Libvir-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
Matthias,
Using the UIR xen+unix:/// works! I'm curious to know why when
using the UIR xen:/// multiple myEventAddHandleFunc() calls occurred.
Are there and fields I could use to identify and ignore
the spurious calls?
I'd like to use the event monitoring for several remote Xen hosts.
I assume I'll have to modify the code to connect remotely to each
host and hope for just one myEventAddHandleFunc() call per host.
Thanks for your assistance it's much apprecied,
Regards,
Pete
14 years, 9 months
[libvirt] [PATCH] remote_driver.c: fix a NULL dereference in remoteDomainEventQueueFlush().
by kakuma
Hi, all.
There is a case of a NULL dereference in function remoteDomainEventQueueFlush()
in remote_driver.c
In the case of local connection conn->privateData->domainEvents isn't reserved.
In this case it will occurs segment fault.
(for example examples/domain-events/events-c/event-test.c)
I think the following patch will be available.
Thanks.
---
src/remote/remote_driver.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index d6f5fce..b112fd3 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -8709,7 +8709,7 @@ void
remoteDomainEventQueueFlush(int timer ATTRIBUTE_UNUSED, void *opaque)
{
virConnectPtr conn = opaque;
- struct private_data *priv = conn->privateData;
+ struct private_data *priv = conn->networkPrivateData;
virDomainEventQueue tempQueue;
remoteDriverLock(priv);
--
1.5.6.1
--
kakuma <f-kak(a)ksh.biglobe.ne.jp>
14 years, 9 months
Re: [libvirt] Segfault in event-test.c example
by pspreadborough＠comcast.net
----- "Matthias Bolte" <matthias.bolte(a)googlemail.com> wrote:
> 2010/1/10 <pspreadborough(a)comcast.net>:
> >
> > ----- "Matthias Bolte" <matthias.bolte(a)googlemail.com> wrote:
> >
> >> 2010/1/10 <pspreadborough(a)comcast.net>:
> >> >
> >> > Hello,
> >> >
> >> > I have been trying to use the domain event C code example but
> >> > unfortunately it segfaults (signal 11) every time I run it:
> >> >
> >> > [root@Spring events-c]# ./event-test
> >> > myEventAddHandleFunc:221: Add handle 5 1 0xf081a0 0x8f727f8
> >> > myEventAddHandleFunc:221: Add handle 7 1 0xf09990 0x8f727f8
> >> > myEventAddHandleFunc:221: Add handle 8 1 0xed7940 0x8f727f8
> >> > myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0 0x8f727f8
> >> > myEventAddHandleFunc:221: Add handle 11 1 0xed7940 0x8f727f8
> >> > myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0 0x8f727f8
> >> > main:322 :: Registering domain event cbs
> >> > Segmentation fault (core dumped)
> >> >
> >> > Core was generated by
> >> >
> >>
> `/root/libvirt-0.7.5/examples/domain-events/events-c/.libs/lt-event-test'.
> >> > Program terminated with signal 11, Segmentation fault.
> >> > [New process 21806]
> >> > [New process 21822]
> >> > #0 remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8) at
> >> > remote/remote_driver.c:8720
> >> > 8720 tempQueue.count = priv->domainEvents->count;
> >> > (gdb) bt
> >> > #0 remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8) at
> >> > remote/remote_driver.c:8720
> >> > #1 0x080490d3 in main (argc=Cannot access memory at address 0x1
> >> > ) at event-test.c:347
> >> >
> >> > The stack looks corrupted so I'm doubtful that this trace if of
> much
> >> value.
> >> > I have built
> >> > and installed libvirt-0.7.5 and it and it's tools seem to be
> >> operating
> >> > correctly.
> >>
> >> I tried the event-test with libvirt-0.7.5 and QEMU/Xen and both
> are
> >> working as expected. No segfaults.
> >>
> >> Could you inspect the values of priv and priv->domainEvents in GDB
> >> using 'p priv' to see if they are NULL and try to dereference them
> in
> >> GDB using 'p *priv' to see if they point to valid memory areas?
> >>
> >> Yes the backtrace looks corrupted. If there is stack/heap
> corruption
> >> involved valgrind may reveal it, so try to run the event-test in
> >> valgrind and see if that gives any hints.
> >>
> >> You can also try the GIT version of libvirt. There was a invalid
> free
> >> call (resulting in heap corruption) in the node device code fixed
> >> after the 0.7.5 release. But that should have no effect on the
> >> event-test.
> >>
> >> Matthias
> >
> > Matthias,
> >
> > priv->domainEvents is NULL, here's the gdb output:
>
> This explains the segfault. The next question is, why is it NULL?
>
> > (gdb) p *priv
> > $1 = {lock = {lock = {__data = {__lock = 1, __count = 0, __owner =
> 21806, __kind = 0, __nusers = 1, {__spins = 0, __list = {
> > __next = 0x0}}}, __size =
> "\001\000\000\000\000\000\000\000.U\000\000\000\000\000\000\001\000\000\000\000\000\000",
> > __align = 1}}, sock = 150469168, watch = 3, pid = 4, uses_tls =
> 1982791681, is_secure = 1815048801, session = 0x782f6269,
>
> Seeing uses_tls and is_secure being large numbers and knowing that
> both are used as boolean values in the code and should have values of
> 0 or 1 make me think that priv points to already freed memory here.
>
> > type = 0x2f646e65 <Address 0x2f646e65 out of bounds>, counter =
> 1684956536, localUses = 1668248365,
> > hostname = 0x74656b <Address 0x74656b out of bounds>, debugLog =
> 0x0, saslconn = 0x0, saslDecoded = 0x0, saslDecodedLength = 0,
>
> type and hostname are char pointers, but the seem to point into
> nowhere, confirms that this is either freed memory or priv itself got
> overwritten due to heap corruption.
>
> > saslDecodedOffset = 0, saslEncoded = 0x0, saslEncodedLength = 0,
> saslEncodedOffset = 0,
> > buffer = '\0' <repeats 68 times>,
> "n\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\bQ�\b����\030\034�\b\000\000\000\000�\033�\b\001\000\000\000\002\000\000\000�\033�\b\000\000\000\000\025|�\000\a",
> '\0' <repeats 11 times>, "X\000�\b", '\0' <repeats 12 times>,
> "\021\000\000\000\002\000\000\000P��\b\000\000\000\000\021", '\0'
> <repeats 15 times>,
> "\021\000\000\0008\036�\b\f\000\000\000\020\000\000\000\021\000\000\000\a\000\000\000\b\000\000\000\t\000\000\000\021\000\000\000\002\000\000\000\230\034�\b\000\000\000\000A\000\000\000\003\000\000\000\001\000\000\000\001\000"...,
> bufferLength = 0,
> > bufferOffset = 0, callbackList = 0x0, domainEvents = 0x0,
> eventFlushTimer = 0, domainEventDispatching = 1, wakeupSendFD = 0,
> > wakeupReadFD = 0, waitDispatch = 0x0, streams = 0x0}
> >
> > I'll try a run with valgrind and post the results.
> >
> > Pete
> >
>
> Could you test the Python version of this example found in
> examples/domain-events/events-python/event-test.py? Does this work?
>
> Otherwise lets see if valgrind gives any hints.
>
> Matthias
During initialization I notice that the myEventAddHandleFunc() method is
called multiple times, each time with a different fd value (5,7,8 and 11).
The way the code is written only the last fd value is recorded and then
used in the poll() call. Is this the intended? if so why are the preceding
fds ignored?
myEventAddHandleFunc:223: Add handle 5 1 0xf13480 0x97b97d8
myEventAddHandleFunc:223: Add handle 7 1 0xf14c70 0x97b97d8
Allocating domainEvents:0x97c6b10
myEventAddHandleFunc:223: Add handle 8 1 0xee2940 0x97b97d8
myEventAddTimeoutFunc:260: Adding Timeout -1 0xee9fc0 0x97b97d8
Allocating domainEvents:0x97c5780
myEventAddHandleFunc:223: Add handle 11 1 0xee2940 0x97b97d8
myEventAddTimeoutFunc:260: Adding Timeout -1 0xee9fc0 0x97b97d8
main:333 :: Registering domain event cbs
Regards,
Pete
14 years, 9 months
[libvirt] [PATCH] Document the domain XML cache attribute for disk devices
by Matthias Bolte
---
docs/formatdomain.html.in | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 46ab0ac..af31699 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -343,7 +343,7 @@
<pre>
...
<disk type='file'>
- <driver name="tap" type="aio">
+ <driver name="tap" type="aio" cache="default">
<source file='/var/lib/xen/images/fv0'/>
<target dev='hda' bus='ide'/>
<encryption type='...'>
@@ -383,7 +383,9 @@
<dd>If the hypervisor supports multiple backend drivers, then the optional
<code>driver</code> element allows them to be selected. The <code>name</code>
attribute is the primary backend driver name, while the optional <code>type</code>
- attribute provides the sub-type. <span class="since">Since 0.1.8</span>
+ attribute provides the sub-type. The optional <code>cache</code> attribute
+ controls the cache mechanism, possible values are "default", "none",
+ "writethrough" and "writeback". <span class="since">Since 0.1.8</span>
</dd>
<dt><code>encryption</code></dt>
<dd>If present, specifies how the volume is encrypted. See
--
1.6.0.4
14 years, 9 months
[libvirt] [PATCH] qemu: Fix a memory leak in qemudExtractTTYPath
by Matthias Bolte
qemudWaitForMonitor calls qemudReadLogOutput with qemudFindCharDevicePTYs
as callback. qemudFindCharDevicePTYs calls qemudExtractTTYPath to assign
a string to chr->data.file.path. Afterwards qemudWaitForMonitor may call
qemudFindCharDevicePTYsMonitor that overwrites chr->data.file.path without
freeing the old value. This results in leaking the memory allocated by
qemudExtractTTYPath.
Report an OOM error if the strdup in qemudFindCharDevicePTYsMonitor fails.
---
src/qemu/qemu_driver.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index daa6f94..8817565 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -1433,7 +1433,13 @@ qemudFindCharDevicePTYsMonitor(virConnectPtr conn,
return -1; \
} \
\
+ VIR_FREE(chr->data.file.path); \
chr->data.file.path = strdup(path); \
+ \
+ if (chr->data.file.path == NULL) { \
+ virReportOOMError(conn); \
+ return -1; \
+ } \
} \
}
--
1.6.0.4
14 years, 9 months
[libvirt] Just to make sure I understand the API
by Bryan Kearney
To make sure I understand the API. If I have a domain defined, but not
started.. it will show up in the list returned by:
virConnectListDefinedDomains
but not in the list
virConnectListDomains
Conversely, if it is started... it will only be in the list:
virConnectListDomains
not in the list
virConnectListDefinedDomains
Is that correct?
-- bk
14 years, 9 months
Re: [libvirt] Segfault in event-test.c example
by pspreadborough＠comcast.net
----- "Matthias Bolte" <matthias.bolte(a)googlemail.com> wrote:
> 2010/1/10 <pspreadborough(a)comcast.net>:
> >
> > ----- "Matthias Bolte" <matthias.bolte(a)googlemail.com> wrote:
> >
> >> 2010/1/10 <pspreadborough(a)comcast.net>:
> >> >
> >> > Hello,
> >> >
> >> > I have been trying to use the domain event C code example but
> >> > unfortunately it segfaults (signal 11) every time I run it:
> >> >
> >> > [root@Spring events-c]# ./event-test
> >> > myEventAddHandleFunc:221: Add handle 5 1 0xf081a0 0x8f727f8
> >> > myEventAddHandleFunc:221: Add handle 7 1 0xf09990 0x8f727f8
> >> > myEventAddHandleFunc:221: Add handle 8 1 0xed7940 0x8f727f8
> >> > myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0 0x8f727f8
> >> > myEventAddHandleFunc:221: Add handle 11 1 0xed7940 0x8f727f8
> >> > myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0 0x8f727f8
> >> > main:322 :: Registering domain event cbs
> >> > Segmentation fault (core dumped)
> >> >
> >> > Core was generated by
> >> >
> >> `/root/libvirt-0.7.5/examples/domain-events/events-c/.libs/lt-event-test'.
> >> > Program terminated with signal 11, Segmentation fault.
> >> > [New process 21806]
> >> > [New process 21822]
> >> > #0 remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8) at
> >> > remote/remote_driver.c:8720
> >> > 8720 tempQueue.count = priv->domainEvents->count;
> >> > (gdb) bt
> >> > #0 remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8) at
> >> > remote/remote_driver.c:8720
> >> > #1 0x080490d3 in main (argc=Cannot access memory at address 0x1
> >> > ) at event-test.c:347
> >> >
> >> > The stack looks corrupted so I'm doubtful that this trace if of much
> >> value.
> >> > I have built
> >> > and installed libvirt-0.7.5 and it and it's tools seem to be
> >> operating
> >> > correctly.
> >>
> >> I tried the event-test with libvirt-0.7.5 and QEMU/Xen and both are
> >> working as expected. No segfaults.
> >>
> >> Could you inspect the values of priv and priv->domainEvents in GDB
> >> using 'p priv' to see if they are NULL and try to dereference them in
> >> GDB using 'p *priv' to see if they point to valid memory areas?
> >>
> >> Yes the backtrace looks corrupted. If there is stack/heap corruption
> >> involved valgrind may reveal it, so try to run the event-test in
> >> valgrind and see if that gives any hints.
> >>
> >> You can also try the GIT version of libvirt. There was a invalid free
> >> call (resulting in heap corruption) in the node device code fixed
> >> after the 0.7.5 release. But that should have no effect on the
> >> event-test.
> >>
> >> Matthias
> >
> > Matthias,
> >
> > priv->domainEvents is NULL, here's the gdb output:
>
> This explains the segfault. The next question is, why is it NULL?
>
> > (gdb) p *priv
> > $1 = {lock = {lock = {__data = {__lock = 1, __count = 0, __owner = 21806, __kind = 0, __nusers = 1, {__spins = 0, __list = {
> > __next = 0x0}}}, __size = "\001\000\000\000\000\000\000\000.U\000\000\000\000\000\000\001\000\000\000\000\000\000",
> > __align = 1}}, sock = 150469168, watch = 3, pid = 4, uses_tls = 1982791681, is_secure = 1815048801, session = 0x782f6269,
>
> Seeing uses_tls and is_secure being large numbers and knowing that
> both are used as boolean values in the code and should have values of
> 0 or 1 make me think that priv points to already freed memory here.
>
> > type = 0x2f646e65 <Address 0x2f646e65 out of bounds>, counter = 1684956536, localUses = 1668248365,
> > hostname = 0x74656b <Address 0x74656b out of bounds>, debugLog = 0x0, saslconn = 0x0, saslDecoded = 0x0, saslDecodedLength = 0,
>
> type and hostname are char pointers, but the seem to point into
> nowhere, confirms that this is either freed memory or priv itself got
> overwritten due to heap corruption.
>
> > saslDecodedOffset = 0, saslEncoded = 0x0, saslEncodedLength = 0, saslEncodedOffset = 0,
> > buffer = '\0' <repeats 68 times>, "n\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\bQ�\b����\030\034�\b\000\000\000\000�\033�\b\001\000\000\000\002\000\000\000�\033�\b\000\000\000\000\025|�\000\a", '\0' <repeats 11 times>, "X\000�\b", '\0' <repeats 12 times>, "\021\000\000\000\002\000\000\000P��\b\000\000\000\000\021", '\0' <repeats 15 times>, "\021\000\000\0008\036�\b\f\000\000\000\020\000\000\000\021\000\000\000\a\000\000\000\b\000\000\000\t\000\000\000\021\000\000\000\002\000\000\000\230\034�\b\000\000\000\000A\000\000\000\003\000\000\000\001\000\000\000\001\000"..., bufferLength = 0,
> > bufferOffset = 0, callbackList = 0x0, domainEvents = 0x0, eventFlushTimer = 0, domainEventDispatching = 1, wakeupSendFD = 0,
> > wakeupReadFD = 0, waitDispatch = 0x0, streams = 0x0}
> >
> > I'll try a run with valgrind and post the results.
> >
> > Pete
> >
>
> Could you test the Python version of this example found in
> examples/domain-events/events-python/event-test.py? Does this work?
>
> Otherwise lets see if valgrind gives any hints.
>
> Matthias
>
Matthias,
I have built the latest git image and run it through valgrind, here's the valgrind output:
[root@Spring .libs]# valgrind -v ./event-test xen:///
==19881== Memcheck, a memory error detector.
==19881== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==19881== Using LibVEX rev 1658, a library for dynamic binary translation.
==19881== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==19881== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==19881== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==19881==
--19881-- Command line
--19881-- ./event-test
--19881-- xen:///
--19881-- Startup, with flags:
--19881-- -v
--19881-- Contents of /proc/version:
--19881-- Linux version 2.6.18-164.10.1.el5xen (mockbuild(a)builder16.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Thu Jan 7 21:14:48 EST 2010
--19881-- Arch and hwcaps: X86, x86-sse1-sse2
--19881-- Valgrind library directory: /usr/lib/valgrind
--19881-- Reading syms from /lib/ld-2.5.so (0x163000)
--19881-- Reading syms from /root/libvirt/libvirt/examples/domain-events/events-c/.libs/event-test (0x8048000)
--19881-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck (0x38000000)
--19881-- object doesn't have a dynamic symbol table
--19881-- Reading suppressions file: /usr/lib/valgrind/default.supp
--19881-- REDIR: 0x178790 (index) redirected to 0x38027D0F (vgPlain_x86_linux_REDIR_FOR_index)
--19881-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so (0x4001000)
--19881-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x4003000)
==19881== WARNING: new redirection conflicts with existing -- ignoring it
--19881-- new: 0x00178790 (index ) R-> 0x04006080 index
--19881-- REDIR: 0x178930 (strlen) redirected to 0x4006250 (strlen)
--19881-- Reading syms from /usr/local/lib/libvirt.so.0.7.5 (0x4009000)
--19881-- Reading syms from /usr/lib/libxml2.so.2.6.26 (0x6254000)
--19881-- object doesn't have a symbol table
--19881-- Reading syms from /usr/lib/libz.so.1.2.3 (0xCD2000)
--19881-- object doesn't have a symbol table
--19881-- Reading syms from /lib/libm-2.5.so (0x413B000)
--19881-- Reading syms from /usr/lib/libgnutls.so.13.0.6 (0x670D000)
--19881-- object doesn't have a symbol table
--19881-- Reading syms from /usr/lib/libgcrypt.so.11.5.2 (0x6590000)
--19881-- object doesn't have a symbol table
--19881-- Reading syms from /usr/lib/libsasl2.so.2.0.22 (0x6536000)
--19881-- object doesn't have a symbol table
--19881-- Reading syms from /usr/lib/libxenstore.so.3.0.0 (0x4162000)
--19881-- object doesn't have a symbol table
--19881-- Reading syms from /lib/libpthread-2.5.so (0x416A000)
--19881-- Reading syms from /lib/libc-2.5.so (0x4183000)
--19881-- Reading syms from /lib/libdl-2.5.so (0xCA7000)
--19881-- Reading syms from /usr/lib/libgpg-error.so.0.3.0 (0xB28000)
--19881-- object doesn't have a symbol table
--19881-- Reading syms from /lib/libresolv-2.5.so (0x26E000)
--19881-- Reading syms from /lib/libcrypt-2.5.so (0x64CE000)
--19881-- REDIR: 0x41F42D0 (memset) redirected to 0x4006540 (memset)
--19881-- REDIR: 0x41F47C0 (memcpy) redirected to 0x4006C20 (memcpy)
--19881-- REDIR: 0x41F3430 (rindex) redirected to 0x4005F60 (rindex)
--19881-- REDIR: 0x41F3090 (strlen) redirected to 0x4006230 (strlen)
--19881-- REDIR: 0x41EED20 (malloc) redirected to 0x400533B (malloc)
--19881-- REDIR: 0x41F2B30 (strcmp) redirected to 0x4006300 (strcmp)
--19881-- REDIR: 0x41EE9E0 (calloc) redirected to 0x4004668 (calloc)
--19881-- REDIR: 0x41F3DD0 (memchr) redirected to 0x4006420 (memchr)
--19881-- REDIR: 0x41EC980 (free) redirected to 0x4004F55 (free)
--19881-- REDIR: 0x41EF190 (realloc) redirected to 0x40053EA (realloc)
==19881== Warning: noted but unhandled ioctl 0x305000 with no size/direction hints
==19881== This could cause spurious value errors to appear.
==19881== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==19881== Warning: noted but unhandled ioctl 0x305000 with no size/direction hints
==19881== This could cause spurious value errors to appear.
==19881== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==19881== Warning: noted but unhandled ioctl 0x305000 with no size/direction hints
==19881== This could cause spurious value errors to appear.
==19881== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
--19881-- REDIR: 0x41F29C0 (index) redirected to 0x4006050 (index)
--19881-- REDIR: 0x41F3280 (strncmp) redirected to 0x4006290 (strncmp)
--19881-- REDIR: 0x41F44C0 (stpcpy) redirected to 0x40068D0 (stpcpy)
--19881-- REDIR: 0x41F3140 (strnlen) redirected to 0x4006200 (strnlen)
--19881-- REDIR: 0x41F3380 (strncpy) redirected to 0x4006DA0 (strncpy)
--19881-- REDIR: 0x41F2BA0 (strcpy) redirected to 0x40069B0 (strcpy)
myEventAddHandleFunc:221: Add handle 5 1 0x40ad4a0 0x42d6188
myEventAddHandleFunc:221: Add handle 7 1 0x40aec90 0x42d6188
Allocating domainEvents:0x43bea68
myEventAddHandleFunc:221: Add handle 8 1 0x407c940 0x42d6188
myEventAddTimeoutFunc:251: Adding Timeout -1 0x4083fe0 0x42d6188
Allocating domainEvents:0x4e8c320
myEventAddHandleFunc:221: Add handle 11 1 0x407c940 0x42d6188
myEventAddTimeoutFunc:251: Adding Timeout -1 0x4083fe0 0x42d6188
main:322 :: Registering domain event cbs
poll
==19881== Invalid read of size 4
==19881== at 0x4084011: remoteDomainEventQueueFlush (remote_driver.c:8722)
==19881== by 0x80490C2: main (event-test.c:341)
==19881== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==19881==
==19881== Process terminating with default action of signal 11 (SIGSEGV)
==19881== Access not within mapped region at address 0x0
==19881== at 0x4084011: remoteDomainEventQueueFlush (remote_driver.c:8722)
==19881== by 0x80490C2: main (event-test.c:341)
==19881==
==19881== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 30 from 1)
==19881==
==19881== 1 errors in context 1 of 1:
==19881== Invalid read of size 4
==19881== at 0x4084011: remoteDomainEventQueueFlush (remote_driver.c:8722)
==19881== by 0x80490C2: main (event-test.c:341)
==19881== Address 0x0 is not stack'd, malloc'd or (recently) free'd
--19881--
--19881-- supp: 30 Fedora-Core-6-hack3-ld25
==19881==
==19881== IN SUMMARY: 1 errors from 1 contexts (suppressed: 30 from 1)
==19881==
==19881== malloc/free: in use at exit: 590,340 bytes in 686 blocks.
==19881== malloc/free: 1,695 allocs, 1,009 frees, 1,700,423 bytes allocated.
==19881==
==19881== searching for pointers to 686 not-freed blocks.
==19881== checked 11,495,892 bytes.
==19881==
==19881== LEAK SUMMARY:
==19881== definitely lost: 0 bytes in 0 blocks.
==19881== possibly lost: 136 bytes in 1 blocks.
==19881== still reachable: 590,204 bytes in 685 blocks.
==19881== suppressed: 0 bytes in 0 blocks.
==19881== Reachable blocks (those to which a pointer was found) are not shown.
==19881== To see them, rerun with: --show-reachable=yes
--19881-- memcheck: sanity checks: 3 cheap, 1 expensive
--19881-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--19881-- memcheck: auxmaps: 0 searches, 0 comparisons
--19881-- memcheck: SMs: n_issued = 36 (576k, 0M)
--19881-- memcheck: SMs: n_deissued = 0 (0k, 0M)
--19881-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)
--19881-- memcheck: SMs: max_undefined = 0 (0k, 0M)
--19881-- memcheck: SMs: max_defined = 244 (3904k, 3M)
--19881-- memcheck: SMs: max_non_DSM = 36 (576k, 0M)
--19881-- memcheck: max sec V bit nodes: 115 (5k, 0M)
--19881-- memcheck: set_sec_vbits8 calls: 679 (new: 115, updates: 564)
--19881-- memcheck: max shadow mem size: 885k, 0M
--19881-- translate: fast SP updates identified: 7,064 ( 89.2%)
--19881-- translate: generic_known SP updates identified: 543 ( 6.8%)
--19881-- translate: generic_unknown SP updates identified: 304 ( 3.8%)
--19881-- tt/tc: 13,590 tt lookups requiring 14,331 probes
--19881-- tt/tc: 13,590 fast-cache updates, 3 flushes
--19881-- transtab: new 6,511 (139,232 -> 2,275,366; ratio 163:10) [0 scs]
--19881-- transtab: dumped 0 (0 -> ??)
--19881-- transtab: discarded 8 (187 -> ??)
--19881-- scheduler: 374,982 jumps (bb entries).
--19881-- scheduler: 3/10,454 major/minor sched events.
--19881-- sanity: 4 cheap, 1 expensive checks.
--19881-- exectx: 30,011 lists, 566 contexts (avg 0 per list)
--19881-- exectx: 2,732 searches, 2,171 full compares (794 per 1000)
--19881-- exectx: 0 cmp2, 67 cmp4, 0 cmpAll
Killed
[root@Spring .libs]#
I tried the python version and did have some success, but not 100% since I didn't
see events for pausing the VM:
[root@Spring events-python]# python event-test.py xen:///
Using uri:xen:///
myDomainEventCallback2 EVENT: Domain vm-full-1(1) Started 0
myDomainEventCallback1 EVENT: Domain vm-full-1(1) Started 0
I noticed that the the C version looks in one place for the libvirt socket and the
python version in a different place, I don't know if this is significant or not?
I tweaked the /etc/libvirt/libvirtd.conf file to alter the location.
C: /usr/local/var/run/libvirt
python: /var/run/libvirt/
Regards,
Pete
14 years, 9 months
[libvirt] [PATCH] Only use pseudo-random generator for uuid if using /dev/random fails.
by Laine Stump
The original code. would only print the warning message if using
/dev/random failed, but would still go ahead and call
virUUIDGeneratePseudoRandomBytes in all cases anyway.
---
src/util/uuid.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/util/uuid.c b/src/util/uuid.c
index 002a64d..846581c 100644
--- a/src/util/uuid.c
+++ b/src/util/uuid.c
@@ -104,9 +104,9 @@ virUUIDGenerate(unsigned char *uuid)
VIR_WARN(_("Falling back to pseudorandom UUID,"
" failed to generate random bytes: %s"),
virStrerror(err, ebuf, sizeof ebuf));
+ err = virUUIDGeneratePseudoRandomBytes(uuid, VIR_UUID_BUFLEN);
}
-
- return virUUIDGeneratePseudoRandomBytes(uuid, VIR_UUID_BUFLEN);
+ return err;
}
/* Convert C from hexadecimal character to integer. */
--
1.6.6
14 years, 9 months
[libvirt] LXC: init problem
by Robin Green
I'm trying to install Exherbo Linux in an LXC container using
libvirt. I've basically succeeded, in that I can "virsh console" in
and start sshd, but I haven't managed to boot it starting from
/sbin/init rather than /bin/bash.
If I have the following (I probably should have modified the uuid and
the mac address from the standard example, but that's not relevant):
<domain type='lxc'>
<name>exherbo</name>
<uuid>a4047015-171c-ae56-bc1e-57102d4b86bf</uuid>
<memory>1000000</memory>
<currentMemory>1000000</currentMemory>
<vcpu>2</vcpu>
<os>
<type arch='i686'>exe</type>
<init>/sbin/init</init>
</os>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/libexec/libvirt_lxc</emulator>
<filesystem type='mount'>
<source dir='/home/greenrd/exherbo'/>
<target dir='/'/>
</filesystem>
<interface type='network'>
<mac address='52:54:00:56:64:42'/>
<source network='default'/>
<target dev='veth0'/>
</interface>
<console type='pty'>
<target port='0'/>
</console>
</devices>
</domain>
and do
virsh --connect lxc:/// start exherbo && virsh --connect lxc:///
console exherbo
nothing appears - then if I press Enter, the container dies.
In pstree all I see that's relevant is:
├─libvirt_lxc───libvirt_lxc
so it looks like init dies.
If I run init in gdb in the container I just get:
Starting program: /sbin/init
Usage: init 0123456SsQqAaBbCcUu
Program exited with code 01.
so I suppose it could be wanting a runlevel as argument. I'm guessing
though that /sbin/init is running in a different mode - telinit mode
- as its PID is not 1.
Is there any way to get an instant console from the virsh start
command, so I can see what's going on?
--
Robin
14 years, 9 months
[libvirt] Re: [virt-tools-list] Questions about virt-manager running on Arch of Itanium 64
by Cole Robinson
cc-ing libvirt-list
On 11/19/2009 10:35 PM, Dustin Xiong wrote:
>
>
>>> Hi everyone!
>>> I am a newer to the virt-manager and maillist. I sent the mail just want
>>> to ask some questions about virt-manager running on Arch of Itanium 64.
>>> My itanium 64 cpu actualy support the VT. I compiled the kvm85
>>> successful. Then I can use the binary /usr/local/bin/qemu-system-ia64 to
>>> create a vm and running. But in my /proc/cpuinfo , there doesn't have
>>> flags such as vmx or svm. So when I use the virt-manager to install a
>>> vm, the virt-manager will tell me my cpu doesn't support fully
>>> virtualization, then I can't install vm. In fact I can't get understand
>>> how the virt-manager find my cpu support the fully virtualization or
>>> not.In src, which file implements this.
>>>
>>
>> Just because qemu-kvm works doesn't mean virt is working on your box, since it
>> can fall back to full emulation mode. If you are trying to use kvm, is the kvm
>> module actually loaded? lsmod | grep kvm
>
> My kvm mod actually loaded.
>
> [root@kvm bin]# lsmod | grep kvm
>
> kvm_intel 306104 4294967281
>
> kvm 327544 1 kvm_intel
>
>
>
> [root@kvm bin]# modinfo kvm
>
> filename: /lib/modules/2.6.28.9hzp/extra/kvm.ko
>
> license: GPL
>
> author: Qumranet
>
> version: kvm-85
>
> srcversion: C399DD2D9B40BAAC05CD509
>
> depends:
>
> vermagic: 2.6.28.9hzp SMP mod_unload modversions ia64gcc-4.1
>
>> If so, libvirt may need to be fixed. What's the output of 'virsh --connect
>> qemu:///system capabilities'
>
> [root@kvm bin]# virsh --connect qemu:///system capabilities
> <capabilities>
>
> <host>
> <cpu>
> <arch>ia64</arch>
> </cpu>
> <topology>
> <cells num='1'>
> <cell id='0'>
> <cpus num='16'>
> <cpu id='0'/>
> <cpu id='1'/>
> <cpu id='2'/>
> <cpu id='3'/>
> <cpu id='4'/>
> <cpu id='5'/>
> <cpu id='6'/>
> <cpu id='7'/>
> <cpu id='8'/>
> <cpu id='9'/>
> <cpu id='10'/>
> <cpu id='11'/>
> <cpu id='12'/>
> <cpu id='13'/>
> <cpu id='14'/>
> <cpu id='15'/>
> </cpus>
> </cell>
> </cells>
> </topology>
> </host>
>
>
>>> My cpu is itanium 64, the OS is RHEL.The libvirt is 0.6.3, virt-manager
>>> is 0.6.1.
Ah, are you using the version of libvirt that comes with RHEL 5.4? That
version has been patched to only look for the qemu-kvm binary in one
spot: /usr/libexec/qemu-kvm IIRC. You could try to work with that, but
since you are already building upstream KVM, virt-manager, and virtinst,
might not be a bad idea to pull upstream libvirt as well.
>>> Once i tried to compile the virt-manager-0.8.0, but when i make check,
>>> it returns:
>>>
>>> PYTHONPATH=./..:../graphWidgets/.libs python addhardware.py && touch
>>> .tstamp.addhardware.py
>>> Traceback (mos! t recent call last):
>>> File "addhardware.py", line 32, in ?
>>> from virtinst import VirtualCharDevice, VirtualDevice,
>>> VirtualVideoDevice
>>>
>>> when i rpm -ivh virt-manager-0.6.1-8.el5.ia64.rpm, it could work.
>>>
>>> I don't know why this error occur. Can anyone be kind to tell me how?
>>> thanks a lot.
>>>
>>
>> You will also need to install the latest version of virtinst, found at:
>>
>> http://virt-manager.org/download.html
>
> I downloaded and compiled the latest version of virtinst: virtinst-0.500.0.tar.gz.
> then compile the virt-manager-0.8.0, error changed as below:
>
> [root@kvm virt-manager-0.8.0]# make check
> Making check in src
> make[1]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src'
> Making check in virtManager
> make[2]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager'
> make check-local
> make[3]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager'
> PYTHONPATH=./..:../graphWidgets/.libs python about.py && touch .tstamp.about.py
> PYTHONPATH=./..:../graphWidgets/.libs python addhardware.py && touch .tstamp.addhardware.py
> Traceback (most recent call last):
> File "addhardware.py", line 35, in ?
> from virtManager.asyncjob import vmmAsyncJob
> File "/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager/asyncjob.py", line 30, in ?
> class vmmAsyncJob(gobject.GObject):
> File "/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager/asyncjob.py", line 40, in vmmAsyncJob
> def __init__(self, config, callback, args=None,
> NameError: name '_' is not defined
>
> Thanks for help.If you need any further infos please dont't hesitate to tell me.
>
Ah, didn't notice the make check in the first mail. 'make check' doesn't
work in the virt-manager code base, never taken the time to fix it. You
should just be able to 'make && make install', or 'make' and python
src/virt-manager.py to run from the source dir. If running virt-manager
then throws an error, report here and Ill try to help.
- Cole
14 years, 9 months
