Hello, after updating to the last official release 0.5.1 my application stopped working. No errors to the log file though i raised exceptions where it was possible. i checked with virsh xml description used for creating OpenVZ container and got the following: virsh # create ovz.xml Segmentation fault after that virsh just closed (as well as my application did before). But itself container was created: [root@alt-03 ~]# vzlist -a CTID NPROC STATUS IP_ADDR HOSTNAME 3005 5 running - - Ovz.xml looks like this: <domain type="openvz" id="3005"> <name>3005</name> <memory>131072</memory> <vcpu>1</vcpu> <os> <type>exe</type> <init>/sbin/init</init> </os> <devices> <filesystem type="template"> <source name="altlinux-4.0"/> <target dir="/"/> </filesystem> <interface type="bridge"> <source bridge="vzrb1"/> <target dev="veth3005.0"/> </interface> </devices> <domain> With previous version it worked just fine. Further, it is impossible to create OpenVZ container without <memory> tag though i didn't notice any effects from it. Does it realy needed? <vcpu> tag stopped working. Previously it added in config file of the container a record like CPUS="1". No it doesn't add anything. Mac generation still an issue. It seems my notification about it was missed. Here is a string from config file for created container. [root@alt-03 ~]# cat /etc/vz/conf/3005.conf | grep NETIF NETIF="ifname=eth0,bridge=vzrb1,mac=52:54:00:4B:BB:F4,host_ifname=veth3005.0,host_mac=52:54:00:4B:BB:F4" mac = host_mac = network issue. ________________________________ This message (including attachments) is private and confidential. If you have received this message in error, please notify us and remove it from your system.
On Sat, Dec 13, 2008 at 07:52:55AM -0800, Ivan Vovk wrote:
Hello,
after updating to the last official release 0.5.1 my application stopped working. No errors to the log file though i raised exceptions where it was possible.
i checked with virsh xml description used for creating OpenVZ container and got the following:
virsh # create ovz.xml Segmentation fault
This is bad ! Can you re-run with 'valgrind virsh' and post the errors it shows Or run under 'gdb virsh' and get a stack trace. If running on Fedora, you'll probably need to install the libvirt-debuginfo package first. 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 :|
This is bad ! Can you re-run with 'valgrind virsh' and post the errors it shows
virsh # create ovz.xml ==8393== ==8393== Invalid read of size 4 ==8393== at 0x40A3CF2: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x40A5A93: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x404D8D1: virDomainCreateXML (in /usr/lib/libvirt.so.0.5.1) ==8393== by 0x8056895: (within /usr/bin/virsh) ==8393== by 0x804C195: (within /usr/bin/virsh) ==8393== by 0x80597EA: (within /usr/bin/virsh) ==8393== by 0x4126924: (below main) (in /lib/libc-2.8.90.so) ==8393== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==8393== ==8393== Process terminating with default action of signal 11 (SIGSEGV) ==8393== Access not within mapped region at address 0x8 ==8393== at 0x40A3CF2: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x40A5A93: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x404D8D1: virDomainCreateXML (in /usr/lib/libvirt.so.0.5.1) ==8393== by 0x8056895: (within /usr/bin/virsh) ==8393== by 0x804C195: (within /usr/bin/virsh) ==8393== by 0x80597EA: (within /usr/bin/virsh) ==8393== by 0x4126924: (below main) (in /lib/libc-2.8.90.so) ==8393== ==8393== ERROR SUMMARY: 44 errors from 9 contexts (suppressed: 0 from 0) ==8393== ==8393== 1 errors in context 1 of 9: ==8393== Invalid read of size 4 ==8393== at 0x40A3CF2: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x40A5A93: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x404D8D1: virDomainCreateXML (in /usr/lib/libvirt.so.0.5.1) ==8393== by 0x8056895: (within /usr/bin/virsh) ==8393== by 0x804C195: (within /usr/bin/virsh) ==8393== by 0x80597EA: (within /usr/bin/virsh) ==8393== by 0x4126924: (below main) (in /lib/libc-2.8.90.so) ==8393== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==8393== ==8393== 1 errors in context 2 of 9: ==8393== Conditional jump or move depends on uninitialised value(s) ==8393== at 0x4009F9C: _dl_relocate_object (in /lib/ld-2.8.90.so) ==8393== by 0x4003051: dl_main (in /lib/ld-2.8.90.so) ==8393== by 0x401320E: _dl_sysdep_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000D98: _dl_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000956: (within /lib/ld-2.8.90.so) ==8393== ==8393== 1 errors in context 3 of 9: ==8393== Conditional jump or move depends on uninitialised value(s) ==8393== at 0x4009C7E: _dl_relocate_object (in /lib/ld-2.8.90.so) ==8393== by 0x4003051: dl_main (in /lib/ld-2.8.90.so) ==8393== by 0x401320E: _dl_sysdep_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000D98: _dl_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000956: (within /lib/ld-2.8.90.so) ==8393== ==8393== 1 errors in context 4 of 9: ==8393== Conditional jump or move depends on uninitialised value(s) ==8393== at 0x4009C76: _dl_relocate_object (in /lib/ld-2.8.90.so) ==8393== by 0x4003051: dl_main (in /lib/ld-2.8.90.so) ==8393== by 0x401320E: _dl_sysdep_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000D98: _dl_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000956: (within /lib/ld-2.8.90.so) ==8393== ==8393== 1 errors in context 5 of 9: ==8393== Conditional jump or move depends on uninitialised value(s) ==8393== at 0x4009C7E: _dl_relocate_object (in /lib/ld-2.8.90.so) ==8393== by 0x4002F46: dl_main (in /lib/ld-2.8.90.so) ==8393== by 0x401320E: _dl_sysdep_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000D98: _dl_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000956: (within /lib/ld-2.8.90.so) ==8393== ==8393== 1 errors in context 6 of 9: ==8393== Conditional jump or move depends on uninitialised value(s) ==8393== at 0x4009C76: _dl_relocate_object (in /lib/ld-2.8.90.so) ==8393== by 0x4002F46: dl_main (in /lib/ld-2.8.90.so) ==8393== by 0x401320E: _dl_sysdep_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000D98: _dl_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000956: (within /lib/ld-2.8.90.so) ==8393== ==8393== 2 errors in context 7 of 9: ==8393== Conditional jump or move depends on uninitialised value(s) ==8393== at 0x400AC8A: _dl_relocate_object (in /lib/ld-2.8.90.so) ==8393== by 0x4002F46: dl_main (in /lib/ld-2.8.90.so) ==8393== by 0x401320E: _dl_sysdep_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000D98: _dl_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000956: (within /lib/ld-2.8.90.so) ==8393== ==8393== 17 errors in context 8 of 9: ==8393== Conditional jump or move depends on uninitialised value(s) ==8393== at 0x4009F9C: _dl_relocate_object (in /lib/ld-2.8.90.so) ==8393== by 0x4002F46: dl_main (in /lib/ld-2.8.90.so) ==8393== by 0x401320E: _dl_sysdep_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000D98: _dl_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000956: (within /lib/ld-2.8.90.so) ==8393== ==8393== 19 errors in context 9 of 9: ==8393== Conditional jump or move depends on uninitialised value(s) ==8393== at 0x400B4B5: _dl_relocate_object (in /lib/ld-2.8.90.so) ==8393== by 0x4002F46: dl_main (in /lib/ld-2.8.90.so) ==8393== by 0x401320E: _dl_sysdep_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000D98: _dl_start (in /lib/ld-2.8.90.so) ==8393== by 0x4000956: (within /lib/ld-2.8.90.so) ==8393== IN SUMMARY: 44 errors from 9 contexts (suppressed: 0 from 0) ==8393== ==8393== malloc/free: in use at exit: 84,638 bytes in 613 blocks. ==8393== malloc/free: 1,543 allocs, 930 frees, 166,402 bytes allocated. ==8393== ==8393== searching for pointers to 613 not-freed blocks. ==8393== checked 411,932 bytes. ==8393== ==8393== LEAK SUMMARY: ==8393== definitely lost: 0 bytes in 0 blocks. ==8393== possibly lost: 0 bytes in 0 blocks. ==8393== still reachable: 84,638 bytes in 613 blocks. ==8393== suppressed: 0 bytes in 0 blocks. ==8393== Rerun with --leak-check=full to see details of leaked memory. --8393-- memcheck: sanity checks: 6 cheap, 2 expensive --8393-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --8393-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10 --8393-- memcheck: auxmaps_L2: 0 searches, 0 nodes --8393-- memcheck: SMs: n_issued = 26 (416k, 0M) --8393-- memcheck: SMs: n_deissued = 0 (0k, 0M) --8393-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) --8393-- memcheck: SMs: max_undefined = 3 (48k, 0M) --8393-- memcheck: SMs: max_defined = 77 (1232k, 1M) --8393-- memcheck: SMs: max_non_DSM = 26 (416k, 0M) --8393-- memcheck: max sec V bit nodes: 276 (14k, 0M) --8393-- memcheck: set_sec_vbits8 calls: 1233 (new: 276, updates: 957) --8393-- memcheck: max shadow mem size: 734k, 0M --8393-- translate: fast SP updates identified: 12,480 ( 88.9%) --8393-- translate: generic_known SP updates identified: 1,058 ( 7.5%) --8393-- translate: generic_unknown SP updates identified: 490 ( 3.4%) --8393-- tt/tc: 24,409 tt lookups requiring 27,195 probes --8393-- tt/tc: 24,409 fast-cache updates, 3 flushes --8393-- transtab: new 11,504 (227,328 -> 3,334,263; ratio 146:10) [0 scs] --8393-- transtab: dumped 0 (0 -> ??) --8393-- transtab: discarded 6 (185 -> ??) --8393-- scheduler: 651,511 jumps (bb entries). --8393-- scheduler: 6/25,065 major/minor sched events. --8393-- sanity: 7 cheap, 2 expensive checks. --8393-- exectx: 1,543 lists, 1,396 contexts (avg 0 per list) --8393-- exectx: 2,516 searches, 1,971 full compares (783 per 1000) --8393-- exectx: 0 cmp2, 103 cmp4, 0 cmpAll --8393-- errormgr: 9 supplist searches, 450 comparisons during search --8393-- errormgr: 44 errlist searches, 111 comparisons during search Segmentation fault
Or run under 'gdb virsh' and get a stack trace.
[root@alt-03 ~]# gdb virsh -d 5 GNU gdb 6.6-alt3 (ALT Linux) (gdb) run Starting program: /usr/bin/virsh [New Thread -1214211888 (LWP 15303)] Welcome to virsh, the virtualization interactive terminal. virsh # create ovz.xml Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1214211888 (LWP 15303)] 0xb7f19cf2 in ?? () from /usr/lib/libvirt.so.0 (gdb) backtrace #0 0xb7f19cf2 in ?? () from /usr/lib/libvirt.so.0 #1 0xb7f1ba94 in ?? () from /usr/lib/libvirt.so.0 #2 0xb7ec38d2 in virDomainCreateXML () from /usr/lib/libvirt.so.0 #3 0x08056896 in ?? () #4 0x0804c196 in ?? () #5 0x080597eb in ?? () #6 0xb7d21925 in __libc_start_main () from /lib/libc.so.6 #7 0x0804b5c1 in ?? () (gdb) - Ivan This message (including attachments) is private and confidential. If you have received this message in error, please notify us and remove it from your system.
On Sun, Dec 14, 2008 at 02:34:37AM -0800, Ivan Vovk wrote:
This is bad ! Can you re-run with 'valgrind virsh' and post the errors it shows
virsh # create ovz.xml ==8393== ==8393== Invalid read of size 4 ==8393== at 0x40A3CF2: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x40A5A93: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x404D8D1: virDomainCreateXML (in /usr/lib/libvirt.so.0.5.1)
please install the corresponding libvirt-debuginfo so we can see where t fails. thanks Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
2008/12/15 Daniel Veillard <veillard@redhat.com>
On Sun, Dec 14, 2008 at 02:34:37AM -0800, Ivan Vovk wrote:
This is bad ! Can you re-run with 'valgrind virsh' and post the errors it shows
virsh # create ovz.xml ==8393== ==8393== Invalid read of size 4 ==8393== at 0x40A3CF2: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x40A5A93: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x404D8D1: virDomainCreateXML (in /usr/lib/libvirt.so.0.5.1)
please install the corresponding libvirt-debuginfo so we can see where t fails.
We have no libvirt-debuginfo package in ALT. Is it one with --enable-debug=yes? If it is, then here is a result of command [root@snow tmp]# LIBVIRT_DEBUG=yes virsh create ju >ham 2>&1 Segmentation fault --------- ham --------------------------- DEBUG: libvirt.c: virInitialize (register drivers) DEBUG: libvirt.c: virRegisterDriver (registering Test as driver 0) DEBUG: libvirt.c: virRegisterNetworkDriver (registering Test as network driver 0) DEBUG: libvirt.c: virRegisterStorageDriver (registering Test as storage driver 0) DEBUG: libvirt.c: virRegisterDeviceMonitor (registering Test as device driver 0) DEBUG: libvirt.c: virRegisterDriver (registering Xen as driver 1) DEBUG: libvirt.c: virRegisterDriver (registering OPENVZ as driver 2) DEBUG: libvirt.c: virRegisterDriver (registering remote as driver 3) DEBUG: libvirt.c: virRegisterNetworkDriver (registering remote as network driver 1) DEBUG: libvirt.c: virRegisterStorageDriver (registering remote as storage driver 1) DEBUG: libvirt.c: virRegisterDeviceMonitor (registering remote as device driver 1) DEBUG: libvirt.c: virConnectOpenAuth (name=(null), auth=0x1e66dc, flags=0) DEBUG: libvirt.c: do_open (no name, allowing driver auto-select) DEBUG: libvirt.c: do_open (trying driver 0 (Test) ...) DEBUG: libvirt.c: do_open (driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (trying driver 1 (Xen) ...) DEBUG: libvirt.c: do_open (driver 1 Xen returned DECLINED) DEBUG: libvirt.c: do_open (trying driver 2 (OPENVZ) ...) DEBUG: util.c: virExec (/usr/sbin/vzctl --help) DEBUG: libvirt.c: do_open (driver 2 OPENVZ returned SUCCESS) DEBUG: libvirt.c: do_open (network driver 0 Test returned DECLINED) DEBUG: remote_internal.c: doRemoteOpen (proceeding with name = openvz:///system) DEBUG: remote_internal.c: doRemoteOpen (Adding Handler for remote events) DEBUG: remote_internal.c: doRemoteOpen (virEventAddHandle failed: No addHandleImpl defined. continuing without events.) DEBUG: libvirt.c: do_open (network driver 1 remote returned SUCCESS) DEBUG: libvirt.c: do_open (storage driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (storage driver 1 remote returned SUCCESS) DEBUG: libvirt.c: do_open (node driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (node driver 1 remote returned DECLINED) DEBUG: libvirt.c: virDomainCreateXML (conn=0x9dc4940, xmlDesc=<domain type="openvz"> <name>109</name> <memory>524288</memory> <os> <type>exe</type> </os> <devices> <filesystem type="template"> <source name="altlinux-Charibdis"/> <target dir="/"/> </filesystem> <interface type="bridge"> <source bridge="mkvebr0"/> </interface> </devices> </domain> , flags=0) DEBUG: util.c: virRun (/usr/sbin/vzctl --quiet create 109 --ostemplate altlinux-Charibdis) DEBUG: util.c: virRun (/usr/sbin/vzctl --quiet set 109 --netif_add eth0,52:54:00:0F:80:3A,veth109.0,52:54:00:0F:80:3A,mkvebr0 --save) DEBUG: util.c: virRun (/usr/sbin/vzctl --quiet start 109) DEBUG: util.c: virRun (Command stdout: Adding interface veth109.0 to bridge mkvebr0 on CT0 for CT109 ) DEBUG: util.c: virRun (Command stderr: Error: an inet prefix is expected rather than "0". /usr/sbin/vznetaddbr: line 34: /proc/sys/net/ipv4/conf/veth109.0/proxy_arp: No such file or directory /usr/sbin/vznetaddbr: line 35: /proc/sys/net/ipv4/conf/veth109.0/forwarding: No such file or directory ) ---------------------------------------------
On Mon, Dec 15, 2008 at 12:53:28PM +0300, Anton Protopopov wrote:
2008/12/15 Daniel Veillard <veillard@redhat.com>
On Sun, Dec 14, 2008 at 02:34:37AM -0800, Ivan Vovk wrote:
This is bad ! Can you re-run with 'valgrind virsh' and post the errors it shows
virsh # create ovz.xml ==8393== ==8393== Invalid read of size 4 ==8393== at 0x40A3CF2: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x40A5A93: (within /usr/lib/libvirt.so.0.5.1) ==8393== by 0x404D8D1: virDomainCreateXML (in /usr/lib/libvirt.so.0.5.1)
please install the corresponding libvirt-debuginfo so we can see where t fails.
We have no libvirt-debuginfo package in ALT. Is it one with --enable-debug=yes?
No that's the package including the compiler debug informations/
If it is, then here is a result of command [root@snow tmp]# LIBVIRT_DEBUG=yes virsh create ju >ham 2>&1 Segmentation fault
please run this under gdb for libvirt compiled with -g (I assume you use gcc) and provide the stack trace where the segfault happens, thanks Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
If it is, then here is a result of command [root@snow tmp]# LIBVIRT_DEBUG=yes virsh create ju >ham 2>&1 Segmentation fault
Now I have a patch (see next message), that fixes that problem. Nevertheless, the other problem is still here and its name is 'pthread usage': [root@snow tmp]# LIBVIRT_DEBUG=y gdb virsh GNU gdb 6.6-alt3 (ALT Linux) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-alt-linux"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/virsh [Thread debugging using libthread_db enabled] [New process 4187] DEBUG: libvirt.c: virInitialize (register drivers) DEBUG: libvirt.c: virRegisterDriver (registering Test as driver 0) DEBUG: libvirt.c: virRegisterNetworkDriver (registering Test as network driver 0) DEBUG: libvirt.c: virRegisterStorageDriver (registering Test as storage driver 0) DEBUG: libvirt.c: virRegisterDeviceMonitor (registering Test as device driver 0) DEBUG: libvirt.c: virRegisterDriver (registering Xen as driver 1) DEBUG: libvirt.c: virRegisterDriver (registering OPENVZ as driver 2) DEBUG: libvirt.c: virRegisterDriver (registering remote as driver 3) DEBUG: libvirt.c: virRegisterNetworkDriver (registering remote as network driver 1) DEBUG: libvirt.c: virRegisterStorageDriver (registering remote as storage driver 1) DEBUG: libvirt.c: virRegisterDeviceMonitor (registering remote as device driver 1) DEBUG: libvirt.c: virConnectOpenAuth (name=(null), auth=0x6c26dc, flags=0) DEBUG: libvirt.c: do_open (no name, allowing driver auto-select) DEBUG: libvirt.c: do_open (trying driver 0 (Test) ...) DEBUG: libvirt.c: do_open (driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (trying driver 1 (Xen) ...) DEBUG: libvirt.c: do_open (driver 1 Xen returned DECLINED) DEBUG: libvirt.c: do_open (trying driver 2 (OPENVZ) ...) [New Thread -1208350512 (LWP 4187)] DEBUG: util.c: virExec (/usr/sbin/vzctl --help) DEBUG: libvirt.c: do_open (driver 2 OPENVZ returned SUCCESS) DEBUG: libvirt.c: do_open (network driver 0 Test returned DECLINED) DEBUG: remote_internal.c: doRemoteOpen (proceeding with name = openvz:///system) DEBUG: remote_internal.c: doRemoteOpen (Adding Handler for remote events) DEBUG: remote_internal.c: doRemoteOpen (virEventAddHandle failed: No addHandleImpl defined. continuing without events.) DEBUG: libvirt.c: do_open (network driver 1 remote returned SUCCESS) DEBUG: libvirt.c: do_open (storage driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (storage driver 1 remote returned SUCCESS) DEBUG: libvirt.c: do_open (node driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (node driver 1 remote returned DECLINED) Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # create joo DEBUG: libvirt.c: virDomainCreateXML (conn=0x81ac910, xmlDesc=<domain type="openvz"> <name>109</name> <memory>524288</memory> <os> <type>exe</type> </os> <devices> <filesystem type="template"> <source name="altlinux-Charibdis"/> <target dir="/"/> </filesystem> <interface type="bridge"> <source bridge="mkvebr0"/> </interface> </devices> </domain> , flags=0) DEBUG: util.c: virRun (/usr/sbin/vzctl --quiet create 109 --ostemplate altlinux-Charibdis) DEBUG: util.c: virRun (/usr/sbin/vzctl --quiet set 109 --netif_add eth0,52:54:00:60:E8:FF,veth109.0,52:54:00:60:E8:FF,mkvebr0 --save) DEBUG: util.c: virRun (/usr/sbin/vzctl --quiet start 109) DEBUG: util.c: virRun (Command stdout: Adding interface veth109.0 to bridge mkvebr0 on CT0 for CT109 ) DEBUG: util.c: virRun (Command stderr: Error: an inet prefix is expected rather than "0". /usr/sbin/vznetaddbr: line 34: /proc/sys/net/ipv4/conf/veth109.0/proxy_arp: No such file or directory /usr/sbin/vznetaddbr: line 35: /proc/sys/net/ipv4/conf/veth109.0/forwarding: No such file or directory ) DEBUG: datatypes.c: virGetDomain (New hash entry 0x81c4b38) <virsh is sleeping, I typing Ctrl-C> Program received signal SIGINT, Interrupt. [Switching to Thread -1208350512 (LWP 4187)] 0x00510de4 in __lll_lock_wait () from /lib/libpthread.so.0 (gdb) backtrace #0 0x00510de4 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x0050c695 in _L_lock_58 () from /lib/libpthread.so.0 #2 0x0050c0ea in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x0064ec1d in virDomainObjLock (obj=0x81c1ef0) at domain_conf.c:3503 #4 0x00650a15 in virDomainFindByUUID (doms=0x81aca14, uuid=0x81c4b4c "+\211$�e\027�ITy#�e\fK�\021") at domain_conf.c:174 #5 0x0069ff65 in openvzDomainSetVcpus (dom=0x81c4b38, nvcpus=1) at openvz_driver.c:979 #6 0x006a1cdc in openvzDomainCreateXML (conn=0x81ac910, xml=0x81bed78 "<domain type=\"openvz\">\n <name>109</name>\n <memory>524288</memory>\n <os>\n <type>exe</type>\n </os>\n <devices>\n <filesystem type=\"template\">\n <source name=\"altlinux-Charibdis\"/>\n <ta"..., flags=0) at openvz_driver.c:791 #7 0x00649862 in virDomainCreateXML (conn=0x81ac910, xmlDesc=0x81bed78 "<domain type=\"openvz\">\n <name>109</name>\n <memory>524288</memory>\n <os>\n <type>exe</type>\n </os>\n <devices>\n <filesystem type=\"template\">\n <source name=\"altlinux-Charibdis\"/>\n <ta"..., flags=0) at libvirt.c:1365 #8 0x08056876 in cmdCreate (ctl=0xbfe46c58, cmd=0x81ba048) at virsh.c:896 #9 0x0804c166 in vshCommandRun (ctl=0xbfe46c58, cmd=0x81ba048) at virsh.c:6168 #10 0x080597ce in main (argc=1, argv=0xbfe46d34) at virsh.c:7139 (gdb)
On Tue, Dec 16, 2008 at 03:02:29PM +0300, Anton Protopopov wrote:
If it is, then here is a result of command [root@snow tmp]# LIBVIRT_DEBUG=yes virsh create ju >ham 2>&1 Segmentation fault
Now I have a patch (see next message), that fixes that problem.
Nevertheless, the other problem is still here and its name is 'pthread usage':
After a quick look at the code, most likely suspect is the src/openvz_conf.c file, the openvzLoadDomains method. Where it does if (VIR_ALLOC(dom) < 0 || VIR_ALLOC(dom->def) < 0) goto no_memory; There is a missing called to pthread_mutex_init(&dom->lock, NULL); So we're likely trying to lock an un-initialized mutex which is results in 'undefined' behaviour. Can you add that init call and let me know if that helps.. 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 :|
Guys, is it really an issue to fix also mac generation for OpenVZ? Vzctl generates different macs for host's and domain's eth devices. Libvirt creates them with equal macs. In this case there is a bridge support for OpenVZ in libvirt but it doesn't work ... :-( And it has to implement additional steps for changing macs after container creation. This message (including attachments) is private and confidential. If you have received this message in error, please notify us and remove it from your system.
Hi, attached patch fix problem.
Guys,
is it really an issue to fix also mac generation for OpenVZ? Vzctl generates different macs for host's and domain's eth devices. Libvirt creates them with equal macs.
In this case there is a bridge support for OpenVZ in libvirt but it doesn't work ... :-( And it has to implement additional steps for changing macs after container creation.
This message (including attachments) is private and confidential. If you have received this message in error, please notify us and remove it from your system.
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Thanks Evgeniy! Was this patch committed? -----Original Message----- From: Evgeniy Sokolov [mailto:evg@openvz.org] Sent: Thursday, December 18, 2008 4:49 PM To: Ivan Vovk Cc: veillard@redhat.com; Daniel P. Berrange; aspsk2@gmail.com; libvir-list@redhat.com Subject: Re: [libvirt] [OpenVZ] Hi, attached patch fix problem.
Guys,
is it really an issue to fix also mac generation for OpenVZ? Vzctl generates different macs for host's and domain's eth devices. Libvirt creates them with equal macs.
In this case there is a bridge support for OpenVZ in libvirt but it doesn't work ... :-( And it has to implement additional steps for changing macs after container creation.
This message (including attachments) is private and confidential. If you have received this message in error, please notify us and remove it from your system.
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
This message (including attachments) is private and confidential. If you have received this message in error, please notify us and remove it from your system.
On Thu, Dec 18, 2008 at 04:49:13PM +0300, Evgeniy Sokolov wrote:
Hi,
attached patch fix problem.
Guys,
is it really an issue to fix also mac generation for OpenVZ? Vzctl generates different macs for host's and domain's eth devices. Libvirt creates them with equal macs.
Okay, patch looks faily contained and seems to fix the issue, so applied and commited, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (5)
-
Anton Protopopov -
Daniel P. Berrange -
Daniel Veillard -
Evgeniy Sokolov -
Ivan Vovk