- Devel - libvirt List Archives

[libvirt] Libvirt/LXC (lxcControllerMain:380 : EPOLLHUP from fd 7)
by Tony Risinger 07 Dec '09

07 Dec '09

hello, i am trying to use libvirt with LXC, and having some issues... everything seems ok when using lxc-* tools. host box is Arch Linux. ultimately i'm getting this error in the domain log: ..... 05:45:31.353: debug : lxcControllerMain:380 : EPOLLHUP from fd 7 i was getting this last night in #virt: ..... 20:49:57.545: error : lxcFdForward:230 : read of fd 7 failed: Input/output error libvir: Linux Container error : read of fd 7 failed: Input/output error instead of the former, but i can seem to reproduce now. i might have replaced 0.7.4 version with git version... i dont remember. right now the build is direct from master, and i am getting EPOLLHUP. didnt see anything interesting in virsh or libvirtd debug output, but i can paste/bin the whole thing or whatever else if need be. -----VERSIONS/SOURCES (loadmodconfig make target + below) kernel: Linux PHS-001 2.6.32-custom #1 SMP PREEMPT Sun Dec 6 05:29:37 CST 2009 i686 Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel GNU/Linux CONFIG_DEVPTS_MULTIPLE_INSTANCES=y CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_RT_GROUP_SCHED=y CONFIG_CGROUP_SCHED=y CONFIG_CGROUPS=y CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y CONFIG_MM_OWNER=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_NET_CLS_CGROUP=y CONFIG_SECURITY_FILE_CAPABILITIES=y (built from master) libvirt: http://aur.archlinux.org/packages/libvirt-git/libvirt-git/PKGBUILD --with-capng --with-network --with-lxc --without-xen --without-xen-inotify --without-qemu --without-uml --without-openvz --without-vbox --without-one --without-esx libcap-ng: http://aur.archlinux.org/packages/libcap-ng/libcap-ng/PKGBUILD container: http://www.stgraber.org/2009/11/06/lxc-containers-or-extremely-fast-virtual… http://www.stgraber.org/download/lxc-ubuntu-8.04-i386.tar.gz -----CONFIGURATION # host ptmx symlinked to pts/ptmx [root@PHS-001 vps]# ls -l /dev/ptmx lrwxrwxrwx 1 root root 8 2009-12-08 04:40 /dev/ptmx -> pts/ptmx # guest ptmx symlinked to pts/ptmx [root@PHS-001 vps]# ls -l /vps/dom/ubuntu/root/dev/ptmx lrwxrwxrwx 1 root root 8 2009-12-06 04:11 /vps/dom/ubuntu/root/dev/ptmx -> pts/ptmx # host devpts mounted newinstance [root@PHS-001 vps]# mount | grep devpts none on /dev/pts type devpts (rw,newinstance) # single cgroup mount on host [root@PHS-001 vps]# mount | grep cgroup none on /cgroup type cgroup (rw) # libvirt config [root@PHS-001 vps]# grep -v -e '^#\|^ *$' /etc/libvirt/libvirtd.conf auth_unix_ro = "none" auth_unix_rw = "none" # guest config... # i have tried the legacy <console type='pty' /> with same results # i dont fully understand this, why do i need to specify a host/source pty? [root@PHS-001 vps]# cat /vps/def/exec/sys/ubuntu.xml <domain type='lxc'> <name>ubuntu</name> <memory>500000</memory> <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> <filesystem type='mount'> <source dir='/vps/dom/ubuntu/root'/> <target dir='/'/> </filesystem> <console type='pty'> <source path='/dev/pts/4'/> <target port='0'/> </console> </devices> </domain> -----PROCEDURE [root@PHS-001 vps]# LIBVIRT_DEBUG=1 libvirtd --daemon 05:42:46.121: debug : virInitialize:278 : register drivers ..... [root@PHS-001 vps]# virsh -c lxc:/// define /vps/def/exec/sys/ubuntu.xml Domain ubuntu defined from /vps/def/exec/sys/ubuntu.xml [root@PHS-001 vps]# virsh -c lxc:/// define /vps/def/exec/sys/ubuntu.xml Domain ubuntu defined from /vps/def/exec/sys/ubuntu.xml [root@PHS-001 vps]# virsh -c lxc:/// start ubuntu Domain ubuntu started [root@PHS-001 vps]# virsh -c lxc:/// console ubuntu error: Unable to get domain status error: internal error Unable to get cgroup for ubuntu -----LOGS # /var/log/libvirt/lxc/ubuntu.log 05:45:31.105: debug : lxcControllerRun:540 : Setting up private /dev/pts 05:45:31.125: debug : lxcControllerRun:566 : Mouting 'devpts' on /vps/dom/ubuntu/root/dev/pts 05:45:31.125: debug : lxcControllerRun:581 : Opening tty on private /vps/dom/ubuntu/root/dev/pts/ptmx 05:45:31.125: debug : virCgroupNew:492 : New group / 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 0:cpu at /cgroup in /1534 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 1:cpuacct at /cgroup in /1534 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 2:cpuset at /cgroup in /1534 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 3:memory at /cgroup in /1534 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 4:devices at /cgroup in /1534 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 5:freezer at /cgroup in /1534 05:45:31.125: debug : virCgroupNew:492 : New group /libvirt 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 0:cpu at /cgroup in /1534 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 1:cpuacct at /cgroup in /1534 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 2:cpuset at /cgroup in /1534 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 3:memory at /cgroup in /1534 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 4:devices at /cgroup in /1534 05:45:31.125: debug : virCgroupDetect:230 : Detected mount/mapping 5:freezer at /cgroup in /1534 05:45:31.125: debug : virCgroupMakeGroup:450 : Make group /libvirt 05:45:31.125: debug : virCgroupMakeGroup:462 : Make controller /cgroup/1534/libvirt/ 05:45:31.125: debug : virCgroupCpuSetInherit:416 : Setting up inheritance / -> /libvirt 05:45:31.126: debug : virCgroupGetValueStr:305 : Get value /cgroup/1534/cpuset.cpus 05:45:31.126: debug : virCgroupCpuSetInherit:429 : Inherit cpuset.cpus = 0-3 05:45:31.126: debug : virCgroupSetValueStr:275 : Set value /cgroup/1534/libvirt/cpuset.cpus 05:45:31.126: debug : virCgroupGetValueStr:305 : Get value /cgroup/1534/cpuset.mems 05:45:31.126: debug : virCgroupCpuSetInherit:429 : Inherit cpuset.mems = 0 05:45:31.126: debug : virCgroupSetValueStr:275 : Set value /cgroup/1534/libvirt/cpuset.mems 05:45:31.126: debug : virCgroupMakeGroup:462 : Make controller /cgroup/1534/libvirt/ 05:45:31.126: debug : virCgroupMakeGroup:462 : Make controller /cgroup/1534/libvirt/ 05:45:31.126: debug : virCgroupMakeGroup:462 : Make controller /cgroup/1534/libvirt/ 05:45:31.126: debug : virCgroupMakeGroup:462 : Make controller /cgroup/1534/libvirt/ 05:45:31.126: debug : virCgroupMakeGroup:462 : Make controller /cgroup/1534/libvirt/ 05:45:31.126: debug : virCgroupNew:492 : New group /libvirt/lxc 05:45:31.126: debug : virCgroupDetect:230 : Detected mount/mapping 0:cpu at /cgroup in /1534 05:45:31.126: debug : virCgroupDetect:230 : Detected mount/mapping 1:cpuacct at /cgroup in /1534 05:45:31.126: debug : virCgroupDetect:230 : Detected mount/mapping 2:cpuset at /cgroup in /1534 05:45:31.126: debug : virCgroupDetect:230 : Detected mount/mapping 3:memory at /cgroup in /1534 05:45:31.126: debug : virCgroupDetect:230 : Detected mount/mapping 4:devices at /cgroup in /1534 05:45:31.126: debug : virCgroupDetect:230 : Detected mount/mapping 5:freezer at /cgroup in /1534 05:45:31.126: debug : virCgroupMakeGroup:450 : Make group /libvirt/lxc 05:45:31.126: debug : virCgroupMakeGroup:462 : Make controller /cgroup/1534/libvirt/lxc/ 05:45:31.211: debug : lxcContainerStart:832 : clone() returned, 1536 05:45:31.353: debug : lxcControllerMain:380 : EPOLLHUP from fd 7 -----END i've tried endless variations of the <devices> section, but i just cant seem to get anything going with libvirt/LXC once i move the root to a new location for a system container. same container works fine with lxc-* tools (although i manually make a bridge). any help is appreciated, C Anthony Risinger

2 2

[libvirt] [PATCH 00/14] Introduce support for the JSON based QEMU monitor
by Daniel P. Berrange 07 Dec '09

07 Dec '09

This is an updated series fully implementing the new QEMU monitor protocol based on JSON instead of plain text. I previously posted a proof of concept here http://www.redhat.com/archives/libvir-list/2009-November/msg00098.html Since that time, the QEMU side is actually working, so I've been able todo a real impl for libvirt now & also test it. I threw out the JSON library code I used last time, since it turned out to be quite unreliable code. Instead I'm using YAJL which is a much nicer library & integrates with libvirt very nicely. Daniel

6 56

[libvirt] Synchronous commands block virsh?
by Matthew Richardson 07 Dec '09

07 Dec '09

I'm currently playing with libvirt on Ubuntu 9.10: Compiled against library: libvir 0.7.0 Using library: libvir 0.7.0 Using API: QEMU 0.7.0 Running hypervisor: QEMU 0.11.0 I've noticed that if I open virsh on a host and set a live migration going, then virsh doesn't return until the migration is complete. However, if I open a second virsh command, it too blocks on commands (e.g list), meaning that I can't perform any other operations against other domains until the initial migration is complete. Is this deliberate or accidental? Is there any way round this? Thanks, Matthew The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

3 2

[libvirt] [PATCH] vbox: Use virIndexToDiskName() in vboxGenerateMediumName()
by Matthias Bolte 07 Dec '09

07 Dec '09

--- src/vbox/vbox_tmpl.c | 48 +++++++++--------------------------------------- 1 files changed, 9 insertions(+), 39 deletions(-) diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c index 10cc1ed..33f5334 100644 --- a/src/vbox/vbox_tmpl.c +++ b/src/vbox/vbox_tmpl.c @@ -426,15 +426,14 @@ static void vboxUtf8toIID(virConnectPtr conn, char *uuidstr, vboxIID **iid) { * @param aMaxSlotPerPort Input array of max slot per device port * */ -static char *vboxGenerateMediumName(virConnectPtr conn, - PRUint32 storageBus, +static char *vboxGenerateMediumName(PRUint32 storageBus, PRInt32 deviceInst, PRInt32 devicePort, PRInt32 deviceSlot, PRUint32 *aMaxPortPerInst, PRUint32 *aMaxSlotPerPort) { + const char *prefix = NULL; char *name = NULL; - int len = 0; int total = 0; PRUint32 maxPortPerInst = 0; PRUint32 maxSlotPerPort = 0; @@ -453,48 +452,20 @@ static char *vboxGenerateMediumName(virConnectPtr conn, + (devicePort * maxSlotPerPort) + deviceSlot; - if ((total >= 0) && (total < 26)) - len = 4; - else if ((total >= 26) && (total < 26*26 + 26)) - len = 5; - else if ((total >= 26*26 + 26) && (total < 26*26*26 + 26*26 + 26)) - len = 6; - else - return NULL; - - if (VIR_ALLOC_N(name, len) < 0) { - virReportOOMError(conn); - return NULL; - } - - /* TODO: use virIndexToDiskName() here when available */ if (storageBus == StorageBus_IDE) { - name[0] = 'h'; - name[1] = 'd'; + prefix = "hd"; } else if ( (storageBus == StorageBus_SATA) || (storageBus == StorageBus_SCSI)) { - name[0] = 's'; - name[1] = 'd'; + prefix = "sd"; } else if (storageBus == StorageBus_Floppy) { - name[0] = 'f'; - name[1] = 'd'; + prefix = "fd"; } - if (len == 4) { - name[2] = (char)(97 + total); - } else if (len == 5) { - name[2] = (char)(96 + (total / 26)); - name[3] = (char)(97 + (total % 26)); - } else if (len == 6) { - name[2] = (char)(96 + (total / 26*26)); - name[3] = (char)(96 + ((total % (26*26)) / 26)); - name[4] = (char)(97 + ((total % (26*26)) % 26)); - } + name = virIndexToDiskName(total, prefix); - name[len - 1] = '\0'; - DEBUG("name=%s, len=%d, total=%d, storageBus=%u, deviceInst=%d, " + DEBUG("name=%s, total=%d, storageBus=%u, deviceInst=%d, " "devicePort=%d deviceSlot=%d, maxPortPerInst=%u maxSlotPerPort=%u", - name, len, total, storageBus, deviceInst, devicePort, + NULLSTR(name), total, storageBus, deviceInst, devicePort, deviceSlot, maxPortPerInst, maxSlotPerPort); return name; } @@ -2496,8 +2467,7 @@ static char *vboxDomainDumpXML(virDomainPtr dom, int flags) { imediumattach->vtbl->GetPort(imediumattach, &devicePort); imediumattach->vtbl->GetDevice(imediumattach, &deviceSlot); - def->disks[diskCount]->dst = vboxGenerateMediumName(dom->conn, - storageBus, + def->disks[diskCount]->dst = vboxGenerateMediumName(storageBus, deviceInst, devicePort, deviceSlot, -- 1.6.0.4

3 2

[libvirt] [PATCH] Export all symbols from xml.h for internal use
by Jiri Denemark 05 Dec '09

05 Dec '09

Some of the very useful calls for XML parsing provided by util/xml.[ch] were not exported as private symbols. This patch fixes this. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/libvirt_private.syms | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index edac3bc..0e53063 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -543,3 +543,9 @@ virXPathNodeSet; virXPathString; virXMLPropString; virXPathStringLimit; +virXPathBoolean; +virXPathNumber; +virXPathULong; +virXPathULongLong; +virXPathLongHex; +virXPathULongHex; -- 1.6.5.4

2 1

[libvirt] [PATCH 0/2] Xen: Add support for interface model='netfront'
by Jiri Denemark 04 Dec '09

04 Dec '09

Xen HVM guests with PV drivers end up with two network interfaces for each configured interface. One of them being emulated by qemu and the other one paravirtual. As this might not be desirable, the attached patch provides a way for users to specify that only paravirtual network interface should be presented to the guest. The configuration was inspired by qemu/kvm driver, for which users can specify model='virtio' to use paravirtual network interface. The patch adds support for model='netfront' which results in type=netfront instead of type=ioemu (or nothing for newer xen versions) in guests native configuration. Xen's qemu ignores interfaces with type != ioemu and only paravirtual network device will be seen in the guest. Four possible configuration scenarios follow: - no model specified in domain's XML - libvirt will behave like before this change; it will set type=ioemu for HVM guests on xen host which is not newer than XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU - covered by existing tests - PV guest, any model - no functional change, model is passed as is (and ignored by the hypervisor) - covered by existing tests (e.g., *-net-e1000.*) - HVM guest, model=netfront - type is set to "netfront", model is not specified - covered by new *-net-netfront.* tests - HVM guest, model != netfront - type is set to "ioemu", model is passed as is - covered by new *-net-ioemu.* tests The fourth scenario feels like a regression for xen newer than XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU as users who had a model specified in their guest's configuration won't see a paravirtual interface in their guests any more. On the other hand, the reason for specifying a model is most likely the fact that they want to use such model which implies emulated interface. Users of older xen won't be affected at all as their xen provides paravirtual interface regardless of the type used. In previous version of this patch, I used "xenpv" instead of "netfront" as it looked more like kvm/qemu's virtio. However, you can find several tips how to force PV network interface for HVM guest by using type="netfront" so I changed it to conform with those tips. It also matches guest's driver name used for that device. Jiri Denemark (2): Support for interface model='netfront' Tests for interface type/model configuration src/xen/xend_internal.c | 32 +++++++++++---- src/xen/xm_internal.c | 38 +++++++++++++++-- tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr | 1 + tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml | 42 +++++++++++++++++++ .../sexpr2xmldata/sexpr2xml-fv-net-netfront.sexpr | 1 + tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml | 42 +++++++++++++++++++ tests/sexpr2xmltest.c | 3 + tests/xmconfigdata/test-fullvirt-net-ioemu.cfg | 25 +++++++++++ tests/xmconfigdata/test-fullvirt-net-ioemu.xml | 43 ++++++++++++++++++++ tests/xmconfigdata/test-fullvirt-net-netfront.cfg | 25 +++++++++++ tests/xmconfigdata/test-fullvirt-net-netfront.xml | 43 ++++++++++++++++++++ tests/xmconfigtest.c | 3 + tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr | 1 + tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml | 31 ++++++++++++++ .../xml2sexprdata/xml2sexpr-fv-net-netfront.sexpr | 1 + tests/xml2sexprdata/xml2sexpr-fv-net-netfront.xml | 31 ++++++++++++++ tests/xml2sexprtest.c | 3 + 17 files changed, 352 insertions(+), 13 deletions(-) create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.sexpr create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml create mode 100644 tests/xmconfigdata/test-fullvirt-net-ioemu.cfg create mode 100644 tests/xmconfigdata/test-fullvirt-net-ioemu.xml create mode 100644 tests/xmconfigdata/test-fullvirt-net-netfront.cfg create mode 100644 tests/xmconfigdata/test-fullvirt-net-netfront.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-netfront.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-netfront.xml

3 4

[libvirt] [PATCH] Support for virtualbox version 3.1
by pritesh 04 Dec '09

04 Dec '09

Hi All, I have just added support for VirtualBox Version 3.1 (works for the beta as well) in the libvirt vbox driver. The patch for the same is attached below. Regards, Pritesh

3 8

[libvirt] libvirtd crashes
by Shi Jin 04 Dec '09

04 Dec '09

Hi there, My libvirtd built from the latest git code keeps on crashing on all machines. I turned on debugging and this is the information I have in the log file before crashing: 14:31:50.828: debug : virEventUpdateHandleImpl:146 : Update handle w=110 e=12 14:31:50.828: debug : virEventInterruptLocked:662 : Interrupting 14:31:50.828: debug : qemuMonitorCommandWithHandler:271 : Receive command reply ret=-1 errno=104 0 bytes '(null)' 14:31:50.828: error : qemuMonitorCommandWithHandler:290 : cannot send monitor command 'info cpus': Connection reset by peer 14:31:50.828: error : qemuMonitorTextGetCPUInfo:436 : internal error cannot run monitor command to fetch CPU thread info I am not sure if there is any other information needed to help identify the problem. My building options are: ./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --without-xen --with-qemu --with-qemu-user=oneadmin --with-qemu-group=oneadmin --without-uml --without-vbox --without-openvz --without-lxc Please help me here. I can accept the service failing queries from time to time since I have error handling written so that they can be re-tried. But a crashing libvirtd takes the whole thing down. Thanks a lot. Shi -- Shi Jin, PhD

2 3

[libvirt] ANNOUNCE: New releases virt-manager 0.8.1 and virtinst 0.500.1
by Cole Robinson 03 Dec '09

03 Dec '09

I'm happy to announce two new releases: virt-manager 0.8.1: virt-manager is a desktop application for managing KVM and Xen virtual machines via libvirt. virtinst 0.500.1: virtinst is a collection of command line tools for provisioning libvirt virtual machines, including virt-install and virt-clone. The releases can be downloaded from: http://virt-manager.org/download.html The direct download links are: http://virt-manager.org/download/sources/virt-manager/virt-manager-0.8.1.ta… http://virt-manager.org/download/sources/virtinst/virtinst-0.500.1.tar.gz The virt-manager release includes: - VM Migration wizard, exposing various migration options - Enumerate CDROM and bridge devices on remote connections - Can once again list multiple graphs in the manager window (Jon Nordby) - Support disabling dhcp (Michal Novotny), and specifying 'routed' type for new virtual networks - Support storage pool source enumeration for LVM, NFS, and SCSI - Allow changing VM ACPI, APIC, clock offset, individual vcpu pinning, and video model (vga, cirrus, etc.) - Many improvements and bugfixes The virtinst release includes: - virt-install now attempts --os-variant detection by default. This can be disabled with '--os-variant none' (distro detection currently only works for URL installs) - New --disk option 'format', for creating image disks formats such as qcow2 or vmdk - Many improvements and bugfixes Thanks to everyone who has contributed to this release through testing, bug reporting, submitting patches, and otherwise sending in feedback! Thanks, Cole

1 0

[libvirt] both libvirt 0.7.4 and latest git crashing
by Nikola Ciprich 03 Dec '09

03 Dec '09

Hi, few days ago, I've reported problem with libvirt getting stuck while saving kvm. Today, I tried latest git and it seems the problem is solved which is great. Unfortunately, there seems to be another problem (which I noticed even for 0.7.4 although haven't reported yet) is that libvirtd sometimes crashes. I'm not 100% sure which action causes it to crash as it's being executed by cluster resource manager, but the backtrace might help those familiar with it's internals. (I think it's domain start) (gdb) bt #0 0x00007f4f46d03cd0 in pthread_mutex_unlock () from /lib64/libpthread.so.0 #1 0x000000000042da91 in qemuDomainObjExitMonitor (obj=0x980a80) at qemu/qemu_driver.c:287 #2 0x000000000043ca84 in qemudDomainGetInfo (dom=0x978d50, info=0x42690de0) at qemu/qemu_driver.c:3294 #3 0x00007f4f47ddf3fb in virDomainGetInfo (domain=0x978d50, info=0x42690de0) at libvirt.c:2786 #4 0x000000000041d79e in remoteDispatchDomainGetInfo (server=<value optimized out>, client=<value optimized out>, conn=0x961840, hdr=<value optimized out>, rerr=0x42690e70, args=<value optimized out>, ret=0x42690f50) at remote.c:1076 #5 0x000000000041f35c in remoteDispatchClientCall (server=0x95b780, client=0x97e310, msg=0x980b00) at dispatch.c:506 #6 0x000000000041f712 in remoteDispatchClientRequest (server=0x95b780, client=0x97e310, msg=0x980b00) at dispatch.c:388 #7 0x00000000004147e2 in qemudWorker (data=<value optimized out>) at libvirtd.c:1518 #8 0x00007f4f46d004a7 in start_thread () from /lib64/libpthread.so.0 #9 0x00007f4f46a76c2d in clone () from /lib64/libc.so.6 Could anyone please have a look at it? thanks a lot in advance nik -- ------------------------------------- Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax: +420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: servis(a)linuxbox.cz -------------------------------------

2 1