- 31 7月, 2013 4 次提交
-
-
由 Ján Tomko 提交于
parentIndex is used in virNetworkDefUpdateIPDHCPRange
-
由 Bamvor Jian Zhang 提交于
this patch introduce the console api in libxl driver for both pv and hvm guest. and import and update the libxlMakeChrdevStr function which was deleted in commit dfa1e1dd. Signed-off-by: NBamvor Jian Zhang <bjzhang@suse.com>
-
由 Dan Walsh 提交于
This function is needed for virt-login-shell. Also modify virGirUserDirectory to use the new function, to simplify the code. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
* src/openvz/openvz_driver.c: Use correct spelling. * src/vmware/vmware_conf.c: Likewise. * src/vmware/vmware_conf.h: Likewise. * src/vmware/vmware_driver.c: Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 30 7月, 2013 4 次提交
-
-
由 Yuri Chornoivan 提交于
Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrange 提交于
The VIR_DOMAIN_PAUSED_GUEST_PANICKED constant is badly named, leaking the QEMU event name. Elsewhere in the API we use 'CRASHED' rather than 'PANICKED', and the addition of 'GUEST' is redundant since all events are guest related. Thus rename it to VIR_DOMAIN_PAUSED_CRASHED, which matches with VIR_DOMAIN_RUNNING_CRASHED and VIR_DOMAIN_EVENT_CRASHED. It was added in commit 14e7e0ae which post-dates v1.1.0, so is safe to rename before 1.1.1 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The VIR_DOMAIN_SHUTDOWN_CRASHED state constant does not appear to be used in the QEMU code anyway. It also doesn't make much (any) sense, since the 'shutdown' state is a transient state between 'running' and 'shutoff' and when a guest crashes, it does not end up in a 'shutdown' state, only 'shutoff'. It was added in commit 14e7e0ae which post-dates v1.1.0, so is safe to remove before 1.1.1 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The way we were casting small (<32bit) integers was broken on big endian hosts, causing stack smashing. This was detected in the test suite either by test failures due to incorrect results, or by libc/gcc abort'ing with its stack canary triggered. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 29 7月, 2013 10 次提交
-
-
由 Eric Blake 提交于
Depending on the set of mingw packages installed, it is possible that other .c files hit the mingw header pollution from the virdbus.h file. In file included from ../../src/rpc/virnetserver.c:39:0: ../../src/util/virdbus.h:41:35: error: expected ';', ',' or ')' before 'struct' const char *interface, ^ * src/util/virdbus.h (virDBusCallMethod): Match .c file change. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
On platforms without decent group support, the build failed: Cannot export virGetGroupList: symbol not defined ./.libs/libvirt_security_manager.a(libvirt_security_manager_la-security_dac.o): In function `virSecurityDACPreFork': /home/eblake/libvirt-tmp/build/src/../../src/security/security_dac.c:248: undefined reference to `virGetGroupList' collect2: error: ld returned 1 exit status * src/util/virutil.c (virGetGroupList): Provide dummy implementation. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Our recent conversion to make VIR_ALLOC report oom wasn't tested on mingw: In file included from ../../src/util/virthread.c:29:0: ../../src/util/virthreadwin32.c: In function 'virCondWait': ../../src/util/virthreadwin32.c:166:81: error: 'VIR_FROM_THIS' undeclared (first use in this function) if (VIR_REALLOC_N(c->waiters, c->nwaiters + 1) < 0) { ^ * src/util/virthreadwin32.c (VIR_FROM_THIS): Define. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Mingw headers pollute the namespace. CC libvirt_util_la-virdbus.lo ../../src/util/virdbus.c:1102:35: error: expected ';', ',' or ')' before 'struct' const char *interface, ^ * src/util/virdbus.c (virDBusCallMethod): Avoid 'interface'. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
The previous patch was incomplete. CC libvirt_util_la-vircgroup.lo ../../src/util/vircgroup.c:70:12: error: 'virCgroupPartitionEscape' declared 'static' but never defined [-Werror=unused-function] static int virCgroupPartitionEscape(char **path); ^ * src/util/vircgroup.c (virCgroupPartitionEscape): Move forward declaration inside conditional. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrange 提交于
The virCgroupValidateMachineGroup method calls some functions which are only conditionally compiled, thus it too must be made conditional. This fixes the build on non-Linux hosts. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Eric Blake 提交于
A VPATH build 'make check' was failing with: GEN check-driverimpls Can't open ../../src/../../src/lxc/lxc_monitor_protocol.h: No such file or directory at ../../src/check-driverimpls.pl line 29, <> line 27153. Can't open ../../src/../../src/lxc/lxc_monitor_protocol.c: No such file or directory at ../../src/check-driverimpls.pl line 29, <> line 27153. ... GEN check-aclrules cannot read ../../src/../../src/remote/remote_protocol.x at ../../src/check-aclrules.pl line 128. because $(srcdir) was being prepended to file names that already included it. * src/Makefile.am (check-driverimpls): Don't add srcdir twice. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrange 提交于
When the legacy Xen driver probes with a NULL URI, and finds itself running on Xen, it will set conn->uri. A little bit later though it checks to see if libxl support exists, and if so declines the driver. This leaves the conn->uri set to 'xen:///', so if libxl also declines it, it prevents probing of the QEMU driver. Once a driver has set the conn->uri, it must *never* decline an open request. So we must move the libxl check earlier Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Li Zhang 提交于
CPU data structure is refined, which causes one compile error for PPC. Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
-
由 Guannan Ren 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=981094 The commit 0ad9025e introduce qemu flag QEMU_CAPS_DEVICE_VIDEO_PRIMARY for using -device VGA, -device cirrus-vga, -device vmware-svga and -device qxl-vga. In use, for -device qxl-vga, mouse doesn't display in guest window like the desciption in above bug. This patch try to use -device for primary video when qemu >=1.6 which contains the bug fix patch
-
- 27 7月, 2013 2 次提交
-
-
由 Eric Blake 提交于
Otherwise, with new enough gcc compiling at -O2, the build fails with: ../../src/conf/domain_conf.c: In function ‘virDomainDeviceDefPostParse’: ../../src/conf/domain_conf.c:2821:29: error: ‘cnt’ may be used uninitialized in this function [-Werror=maybe-uninitialized] for (i = 0; i < *cnt; i++) { ^ ../../src/conf/domain_conf.c:2795:20: note: ‘cnt’ was declared here size_t i, *cnt; ^ ../../src/conf/domain_conf.c:2794:30: error: ‘arrPtr’ may be used uninitialized in this function [-Werror=maybe-uninitialized] virDomainChrDefPtr **arrPtr; ^ * src/conf/domain_conf.c (virDomainChrGetDomainPtrs): Always assign into output parameters. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrange 提交于
By setting the default partition in libvirt_lxc it is not visible when querying the live XML. Move setting of the default partition into libvirtd virLXCProcessStart Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 26 7月, 2013 12 次提交
-
-
由 John Ferlan 提交于
Adjust these drivers to handle their Autostart functionality after each of the drivers has gone through their Initialization functions
-
由 John Ferlan 提交于
Separation allows for dependent drivers to be make a connection during the AutoStart phase of state initialization.
-
由 Ján Tomko 提交于
ip has to be NULL at this point.
-
由 Ján Tomko 提交于
-
由 Ján Tomko 提交于
This fixes a crash if one of them is missing. https://bugzilla.redhat.com/show_bug.cgi?id=988718
-
由 Ján Tomko 提交于
Decrementing it when it was already 0 causes an invalid free in virNetworkDefUpdateDNSHost if virNetworkDNSHostDefParseXML fails and virNetworkDNSHostDefClear gets called twice. virNetworkForwardDefClear left the number untouched even if it freed all the elements.
-
由 Alex Jia 提交于
Signed-off-by: NAlex Jia <ajia@redhat.com>
-
由 Daniel P. Berrange 提交于
If the app has provided a whitelist of controllers to be used, we skip detecting its mount point. We still, however, fill in the placement info which later confuses the machine name validation code. Skip detecting placement if the controller mount point is not set Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When detecting cgroups we must honour any controllers whitelist the driver may have. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When a VM has an 'emulator' child cgroup present, we must strip off that suffix when detecting the cgroup for a machine Rename the virCgroupIsValidMachineGroup method to virCgroupValidateMachineGroup to make a bit clearer that this isn't simply a boolean check, it will make changes to the object. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The virCgroupIsValidMachine does not need to be called from outside the cgroups file now, so make it static. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Instead of requiring drivers to use a combination of calls to virCgroupNewDetect and virCgroupIsValidMachine, combine the two into virCgroupNewDetectMachine Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 25 7月, 2013 5 次提交
-
-
由 Ján Tomko 提交于
Both virStoragePoolFree and virStorageVolFree reset the last error, which might lead to the cryptic message: An error occurred, but the cause is unknown When the volume wasn't found, virStorageVolFree was called with NULL, leading to an error: invalid storage volume pointer in virStorageVolFree This patch changes it to: Storage volume not found: no storage vol with matching name 'tomato'
-
由 Daniel P. Berrange 提交于
Add protection such that the virCgroupRemove and virCgroupKill* do not do anything to the root cgroup. Killing all PIDs in the root cgroup does not end well. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Convert the LXC driver code to use the new atomic API for setup of cgroups Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Convert the QEMU driver code to use the new atomic API for setup of cgroups Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Instead of requiring one API call to create a cgroup and another to add a task to it, introduce a new API virCgroupNewMachine which does both jobs at once. This will facilitate the later code to talk to systemd to achieve this job which is also atomic. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 24 7月, 2013 3 次提交
-
-
由 Michal Privoznik 提交于
There's a race in lxc driver causing a deadlock. If a domain is destroyed immediately after started, the deadlock can occur. When domain is started, the even loop tries to connect to the monitor. If the connecting succeeds, virLXCProcessMonitorInitNotify() is called with @mon->client locked. The first thing that callee does, is virObjectLock(vm). So the order of locking is: 1) @mon->client, 2) @vm. However, if there's another thread executing virDomainDestroy on the very same domain, the first thing done here is locking the @vm. Then, the corresponding libvirt_lxc process is killed and monitor is closed via calling virLXCMonitorClose(). This callee tries to lock @mon->client too. So the order is reversed to the first case. This situation results in deadlock and unresponsive libvirtd (since the eventloop is involved). The proper solution is to unlock the @vm in virLXCMonitorClose prior entering virNetClientClose(). See the backtrace as follows: Thread 25 (Thread 0x7f1b7c9b8700 (LWP 16312)): 0 0x00007f1b80539714 in __lll_lock_wait () from /lib64/libpthread.so.0 1 0x00007f1b8053516c in _L_lock_516 () from /lib64/libpthread.so.0 2 0x00007f1b80534fbb in pthread_mutex_lock () from /lib64/libpthread.so.0 3 0x00007f1b82a637cf in virMutexLock (m=0x7f1b3c0038d0) at util/virthreadpthread.c:85 4 0x00007f1b82a4ccf2 in virObjectLock (anyobj=0x7f1b3c0038c0) at util/virobject.c:320 5 0x00007f1b82b861f6 in virNetClientCloseInternal (client=0x7f1b3c0038c0, reason=3) at rpc/virnetclient.c:696 6 0x00007f1b82b862f5 in virNetClientClose (client=0x7f1b3c0038c0) at rpc/virnetclient.c:721 7 0x00007f1b6ee12500 in virLXCMonitorClose (mon=0x7f1b3c007210) at lxc/lxc_monitor.c:216 8 0x00007f1b6ee129f0 in virLXCProcessCleanup (driver=0x7f1b68100240, vm=0x7f1b680ceb70, reason=VIR_DOMAIN_SHUTOFF_DESTROYED) at lxc/lxc_process.c:174 9 0x00007f1b6ee14106 in virLXCProcessStop (driver=0x7f1b68100240, vm=0x7f1b680ceb70, reason=VIR_DOMAIN_SHUTOFF_DESTROYED) at lxc/lxc_process.c:710 10 0x00007f1b6ee1aa36 in lxcDomainDestroyFlags (dom=0x7f1b5c002560, flags=0) at lxc/lxc_driver.c:1291 11 0x00007f1b6ee1ab1a in lxcDomainDestroy (dom=0x7f1b5c002560) at lxc/lxc_driver.c:1321 12 0x00007f1b82b05be5 in virDomainDestroy (domain=0x7f1b5c002560) at libvirt.c:2303 13 0x00007f1b835a7e85 in remoteDispatchDomainDestroy (server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0, rerr=0x7f1b7c9b7c30, args=0x7f1b5c004a50) at remote_dispatch.h:3143 14 0x00007f1b835a7d78 in remoteDispatchDomainDestroyHelper (server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0, rerr=0x7f1b7c9b7c30, args=0x7f1b5c004a50, ret=0x7f1b5c0029e0) at remote_dispatch.h:3121 15 0x00007f1b82b93704 in virNetServerProgramDispatchCall (prog=0x7f1b8573af90, server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0) at rpc/virnetserverprogram.c:435 16 0x00007f1b82b93263 in virNetServerProgramDispatch (prog=0x7f1b8573af90, server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0) at rpc/virnetserverprogram.c:305 17 0x00007f1b82b8c0f6 in virNetServerProcessMsg (srv=0x7f1b857419d0, client=0x7f1b8574ae40, prog=0x7f1b8573af90, msg=0x7f1b8574acf0) at rpc/virnetserver.c:163 18 0x00007f1b82b8c1da in virNetServerHandleJob (jobOpaque=0x7f1b8574dca0, opaque=0x7f1b857419d0) at rpc/virnetserver.c:184 19 0x00007f1b82a64158 in virThreadPoolWorker (opaque=0x7f1b8573cb10) at util/virthreadpool.c:144 20 0x00007f1b82a63ae5 in virThreadHelper (data=0x7f1b8574b9f0) at util/virthreadpthread.c:161 21 0x00007f1b80532f4a in start_thread () from /lib64/libpthread.so.0 22 0x00007f1b7fc4f20d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f1b83546740 (LWP 16297)): 0 0x00007f1b80539714 in __lll_lock_wait () from /lib64/libpthread.so.0 1 0x00007f1b8053516c in _L_lock_516 () from /lib64/libpthread.so.0 2 0x00007f1b80534fbb in pthread_mutex_lock () from /lib64/libpthread.so.0 3 0x00007f1b82a637cf in virMutexLock (m=0x7f1b680ceb80) at util/virthreadpthread.c:85 4 0x00007f1b82a4ccf2 in virObjectLock (anyobj=0x7f1b680ceb70) at util/virobject.c:320 5 0x00007f1b6ee13bd7 in virLXCProcessMonitorInitNotify (mon=0x7f1b3c007210, initpid=4832, vm=0x7f1b680ceb70) at lxc/lxc_process.c:601 6 0x00007f1b6ee11fd3 in virLXCMonitorHandleEventInit (prog=0x7f1b3c001f10, client=0x7f1b3c0038c0, evdata=0x7f1b8574a7d0, opaque=0x7f1b3c007210) at lxc/lxc_monitor.c:109 7 0x00007f1b82b8a196 in virNetClientProgramDispatch (prog=0x7f1b3c001f10, client=0x7f1b3c0038c0, msg=0x7f1b3c003928) at rpc/virnetclientprogram.c:259 8 0x00007f1b82b87030 in virNetClientCallDispatchMessage (client=0x7f1b3c0038c0) at rpc/virnetclient.c:1019 9 0x00007f1b82b876bb in virNetClientCallDispatch (client=0x7f1b3c0038c0) at rpc/virnetclient.c:1140 10 0x00007f1b82b87d41 in virNetClientIOHandleInput (client=0x7f1b3c0038c0) at rpc/virnetclient.c:1312 11 0x00007f1b82b88f51 in virNetClientIncomingEvent (sock=0x7f1b3c0044e0, events=1, opaque=0x7f1b3c0038c0) at rpc/virnetclient.c:1832 12 0x00007f1b82b9e1c8 in virNetSocketEventHandle (watch=3321, fd=54, events=1, opaque=0x7f1b3c0044e0) at rpc/virnetsocket.c:1695 13 0x00007f1b82a272cf in virEventPollDispatchHandles (nfds=21, fds=0x7f1b8574ded0) at util/vireventpoll.c:498 14 0x00007f1b82a27af2 in virEventPollRunOnce () at util/vireventpoll.c:645 15 0x00007f1b82a25a61 in virEventRunDefaultImpl () at util/virevent.c:273 16 0x00007f1b82b8e97e in virNetServerRun (srv=0x7f1b857419d0) at rpc/virnetserver.c:1097 17 0x00007f1b8359db6b in main (argc=2, argv=0x7ffff98dbaa8) at libvirtd.c:1512
-
由 Stefan Bader 提交于
The avail_vcpu bitmap has to be allocated before it can be used (using the maximum allowed value for that). Then for each available VCPU the bit in the mask has to be set (libxl_bitmap_set takes a bit position as an argument, not the number of bits to set). Without this, I would always only get one VCPU for guests created through libvirt/libxl. Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
-
由 Ján Tomko 提交于
As we do for other errors with an extra string.
-