- 19 2月, 2014 5 次提交
-
-
由 Chen Hanxiao 提交于
Free dst before lxcDomainAttachDeviceDiskLive returns Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com> (cherry picked from commit c82513ac)
-
由 Hongwei Bi 提交于
The variable vroot should be freed in label cleanup. (cherry picked from commit 46c9bce4)
-
由 Yuri Chornoivan 提交于
Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 5b4c035b)
-
由 Gao feng 提交于
Create parent directroy for hostdev automatically when we start a lxc domain or attach a hostdev to a lxc domain. Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com> (cherry picked from commit 468ee0bc)
-
由 Gao feng 提交于
This helper function is used to create parent directory for the hostdev which will be added to the container. If the parent directory of this hostdev doesn't exist, the mknod of the hostdev will fail. eg with /dev/net/tun Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com> (cherry picked from commit c0d8c7c8)
-
- 06 2月, 2014 6 次提交
-
-
由 Daniel P. Berrange 提交于
The NWFilter code has as a deadlock race condition between the virNWFilter{Define,Undefine} APIs and starting of guest VMs due to mis-matched lock ordering. In the virNWFilter{Define,Undefine} codepaths the lock ordering is 1. nwfilter driver lock 2. virt driver lock 3. nwfilter update lock 4. domain object lock In the VM guest startup paths the lock ordering is 1. virt driver lock 2. domain object lock 3. nwfilter update lock As can be seen the domain object and nwfilter update locks are not acquired in a consistent order. The fix used is to push the nwfilter update lock upto the top level resulting in a lock ordering for virNWFilter{Define,Undefine} of 1. nwfilter driver lock 2. nwfilter update lock 3. virt driver lock 4. domain object lock and VM start using 1. nwfilter update lock 2. virt driver lock 3. domain object lock This has the effect of serializing VM startup once again, even if no nwfilters are applied to the guest. There is also the possibility of deadlock due to a call graph loop via virNWFilterInstantiate and virNWFilterInstantiateFilterLate. These two problems mean the lock must be turned into a read/write lock instead of a plain mutex at the same time. The lock is used to serialize changes to the "driver->nwfilters" hash, so the write lock only needs to be held by the define/undefine methods. All other methods can rely on a read lock which allows good concurrency. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 6e5c79a1) Conflicts: src/conf/nwfilter_conf.c - virReportOOMError() in context of one hunk. src/lxc/lxc_driver.c - functions renamed, and lxc object locking changed, creating a conflict in the context. (cherry picked from commit 2331e5c8)
-
由 Daniel P. Berrange 提交于
Add virRWLock backed up by a POSIX rwlock primitive Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit c065984b)
-
由 Daniel P. Berrange 提交于
The virConnectPtr is passed around loads of nwfilter code in order to provide it as a parameter to the callback registered by the virt drivers. None of the virt drivers use this param though, so it serves no purpose. Avoiding the need to pass a virConnectPtr means that the nwfilterStateReload method no longer needs to open a bogus QEMU driver connection. This addresses a race condition that can lead to a crash on startup. The nwfilter driver starts before the QEMU driver and registers some callbacks with DBus to detect firewalld reload. If the firewalld reload happens while the QEMU driver is still starting up though, the nwfilterStateReload method will open a connection to the partially initialized QEMU driver and cause a crash. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 999d72fb) Conflicts: src/nwfilter/nwfilter_driver.c - *EnsureACL*() was added after this branch was created, and caused two small conflicts in the context around a hunk.
-
由 Daniel P. Berrange 提交于
The nwfilter driver only needs a reference to its private state object, not a full virConnectPtr. Update the domUpdateCBStruct struct to have a 'void *opaque' field instead of a virConnectPtr. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit ebca369e)
-
由 Daniel P. Berrange 提交于
None of the virNWFilterDefParse* methods require a virConnectPtr arg, so just drop it Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit b77b16ce)
-
由 Daniel P. Berrange 提交于
For inexplicable reasons, the nwfilter XML parser is intentionally ignoring errors that arise during parsing. As well as meaning that users don't get any feedback on their XML mistakes, this will lead it to silently drop data in OOM conditions. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 4f209434)
-
- 16 1月, 2014 8 次提交
-
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1047577 When writing commit 173c2914, I missed the fact virNetServerClientClose unlocks the client object before actually clearing client->sock and thus it is possible to hit a window when client->keepalive is NULL while client->sock is not NULL. I was thinking client->sock == NULL was a better check for a closed connection but apparently we have to go with client->keepalive == NULL to actually fix the crash. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit 066c8ef6)
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1047577 When a client closes its connection to libvirtd early during virConnectOpen, more specifically just after making REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call to check if VIR_DRV_FEATURE_PROGRAM_KEEPALIVE is supported without even waiting for the result, libvirtd may crash due to a race in keep-alive initialization. Once receiving the REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call, the daemon's event loop delegates it to a worker thread. In case the event loop detects EOF on the connection and calls virNetServerClientClose before the worker thread starts to handle REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call, client->keepalive will be disposed by the time virNetServerClientStartKeepAlive gets called from remoteDispatchConnectSupportsFeature. Because the flow is common for both authenticated and read-only connections, even unprivileged clients may cause the daemon to crash. To avoid the crash, virNetServerClientStartKeepAlive needs to check if the connection is still open before starting keep-alive protocol. Every libvirt release since 0.9.8 is affected by this bug. (cherry picked from commit 173c2914)
-
由 Jiri Denemark 提交于
CVE-2013-6458 Every API that is going to begin a job should do that before fetching data from vm->def. (cherry picked from commit 3b564259)
-
由 Jiri Denemark 提交于
Every API that is going to begin a job should do that before fetching data from vm->def. (cherry picked from commit ff5f30b6) Conflicts: src/qemu/qemu_driver.c - context
-
由 Jiri Denemark 提交于
CVE-2013-6458 Every API that is going to begin a job should do that before fetching data from vm->def. (cherry picked from commit f93d2caa)
-
由 Jiri Denemark 提交于
CVE-2013-6458 Generally, every API that is going to begin a job should do that before fetching data from vm->def. However, qemuDomainGetBlockInfo does not know whether it will have to start a job or not before checking vm->def. To avoid using disk alias that might have been freed while we were waiting for a job, we use its copy. In case the disk was removed in the meantime, we will fail with "cannot find statistics for device '...'" error message. (cherry picked from commit b7992595)
-
由 Jiri Denemark 提交于
CVE-2013-6458 https://bugzilla.redhat.com/show_bug.cgi?id=1043069 When virDomainDetachDeviceFlags is called concurrently to virDomainBlockStats: libvirtd may crash because qemuDomainBlockStats finds a disk in vm->def before getting a job on a domain and uses the disk pointer after getting the job. However, the domain in unlocked while waiting on a job condition and thus data behind the disk pointer may disappear. This happens when thread 1 runs virDomainDetachDeviceFlags and enters monitor to actually remove the disk. Then another thread starts running virDomainBlockStats, finds the disk in vm->def, and while it's waiting on the job condition (owned by the first thread), the first thread finishes the disk removal. When the second thread gets the job, the memory pointed to be the disk pointer is already gone. That said, every API that is going to begin a job should do that before fetching data from vm->def. (cherry picked from commit db86da5c) Conflicts: src/qemu/qemu_driver.c - context: no ACLs
-
由 Eric Blake 提交于
While working on v1.0.5-maint (the branch in use on Fedora 19) with the host at Fedora 20, I got a failure in virstoragetest. I traced it to the fact that we were using qemu-img to create a qcow2 file, but qemu-img changed from creating v2 files by default in F19 to creating v3 files in F20. Rather than leaving it up to qemu-img, it is better to write the test to force testing of BOTH file formats (better code coverage and all). This patch alone does not fix all the failures in v1.0.5-maint; for that, we must decide to either teach the older branch to understand v3 files, or to reject them outright as unsupported. But for upstream, making the test less dependent on changing qemu-img defaults is always a good thing. * tests/virstoragetest.c (testPrepImages): Simplify creation of raw file; check if qemu supports compat and if so use it. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 974e5914) Conflicts: tests/virstoragetest.c - hardcode test to v2, since this branch doesn't handle v3 correctly
-
- 20 12月, 2013 2 次提交
-
-
由 Martin Kletzander 提交于
The function doesn't check whether the request is made for active or inactive domain. Thus when the domain is not running it still tries accessing non-existing cgroups (priv->cgroup, which is NULL). I re-made the function in order for it to work the same way it's qemu counterpart does. Reproducer: 1) Define an LXC domain 2) Do 'virsh memtune <domain> --hard-limit 133T' Backtrace: Thread 6 (Thread 0x7fffec8c0700 (LWP 26826)): #0 0x00007ffff70edcc4 in virCgroupPathOfController (group=0x0, controller=3, key=0x7ffff75734bd "memory.limit_in_bytes", path=0x7fffec8bf718) at util/vircgroup.c:1764 #1 0x00007ffff70e9206 in virCgroupSetValueStr (group=0x0, controller=3, key=0x7ffff75734bd "memory.limit_in_bytes", value=0x7fffe409f360 "1073741824") at util/vircgroup.c:669 #2 0x00007ffff70e98b4 in virCgroupSetValueU64 (group=0x0, controller=3, key=0x7ffff75734bd "memory.limit_in_bytes", value=1073741824) at util/vircgroup.c:740 #3 0x00007ffff70ee518 in virCgroupSetMemory (group=0x0, kb=1048576) at util/vircgroup.c:1904 #4 0x00007ffff70ee675 in virCgroupSetMemoryHardLimit (group=0x0, kb=1048576) at util/vircgroup.c:1944 #5 0x00005555557d54c8 in lxcDomainSetMemoryParameters (dom=0x7fffe40cc420, params=0x7fffe409f100, nparams=1, flags=0) at lxc/lxc_driver.c:774 #6 0x00007ffff72c20f9 in virDomainSetMemoryParameters (domain=0x7fffe40cc420, params=0x7fffe409f100, nparams=1, flags=0) at libvirt.c:4051 #7 0x000055555561365f in remoteDispatchDomainSetMemoryParameters (server=0x555555eb7e00, client=0x555555ec4b10, msg=0x555555eb94e0, rerr=0x7fffec8bfb70, args=0x7fffe40b8510) at remote_dispatch.h:7621 #8 0x00005555556133fd in remoteDispatchDomainSetMemoryParametersHelper (server=0x555555eb7e00, client=0x555555ec4b10, msg=0x555555eb94e0, rerr=0x7fffec8bfb70, args=0x7fffe40b8510, ret=0x7fffe40b84f0) at remote_dispatch.h:7591 #9 0x00007ffff73b293f in virNetServerProgramDispatchCall (prog=0x555555ec3ae0, server=0x555555eb7e00, client=0x555555ec4b10, msg=0x555555eb94e0) at rpc/virnetserverprogram.c:435 #10 0x00007ffff73b207f in virNetServerProgramDispatch (prog=0x555555ec3ae0, server=0x555555eb7e00, client=0x555555ec4b10, msg=0x555555eb94e0) at rpc/virnetserverprogram.c:305 #11 0x00007ffff73a4d2c in virNetServerProcessMsg (srv=0x555555eb7e00, client=0x555555ec4b10, prog=0x555555ec3ae0, msg=0x555555eb94e0) at rpc/virnetserver.c:165 #12 0x00007ffff73a4e8d in virNetServerHandleJob (jobOpaque=0x555555ec3e30, opaque=0x555555eb7e00) at rpc/virnetserver.c:186 #13 0x00007ffff7187f3f in virThreadPoolWorker (opaque=0x555555eb7ac0) at util/virthreadpool.c:144 #14 0x00007ffff718733a in virThreadHelper (data=0x555555eb7890) at util/virthreadpthread.c:161 #15 0x00007ffff468ed89 in start_thread (arg=0x7fffec8c0700) at pthread_create.c:308 #16 0x00007ffff3da26bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> (cherry picked from commit 9faf3f29) Conflicts: src/lxc/lxc_driver.c
-
由 Martin Kletzander 提交于
The function doesn't check whether the request is made for active or inactive domain. Thus when the domain is not running it still tries accessing non-existing cgroups (priv->cgroup, which is NULL). I re-made the function in order for it to work the same way it's qemu counterpart does. Reproducer: 1) Define an LXC domain 2) Do 'virsh memtune <domain>' Backtrace: Thread 6 (Thread 0x7fffec8c0700 (LWP 13387)): #0 0x00007ffff70edcc4 in virCgroupPathOfController (group=0x0, controller=3, key=0x7ffff75734bd "memory.limit_in_bytes", path=0x7fffec8bf750) at util/vircgroup.c:1764 #1 0x00007ffff70e958c in virCgroupGetValueStr (group=0x0, controller=3, key=0x7ffff75734bd "memory.limit_in_bytes", value=0x7fffec8bf7c0) at util/vircgroup.c:705 #2 0x00007ffff70e9d29 in virCgroupGetValueU64 (group=0x0, controller=3, key=0x7ffff75734bd "memory.limit_in_bytes", value=0x7fffec8bf810) at util/vircgroup.c:804 #3 0x00007ffff70ee706 in virCgroupGetMemoryHardLimit (group=0x0, kb=0x7fffec8bf8a8) at util/vircgroup.c:1962 #4 0x00005555557d590f in lxcDomainGetMemoryParameters (dom=0x7fffd40024a0, params=0x7fffd40027a0, nparams=0x7fffec8bfa24, flags=0) at lxc/lxc_driver.c:826 #5 0x00007ffff72c28d3 in virDomainGetMemoryParameters (domain=0x7fffd40024a0, params=0x7fffd40027a0, nparams=0x7fffec8bfa24, flags=0) at libvirt.c:4137 #6 0x000055555563714d in remoteDispatchDomainGetMemoryParameters (server=0x555555eb7e00, client=0x555555ebaef0, msg=0x555555ebb3e0, rerr=0x7fffec8bfb70, args=0x7fffd40024e0, ret=0x7fffd4002420) at remote.c:1895 #7 0x00005555556052c4 in remoteDispatchDomainGetMemoryParametersHelper (server=0x555555eb7e00, client=0x555555ebaef0, msg=0x555555ebb3e0, rerr=0x7fffec8bfb70, args=0x7fffd40024e0, ret=0x7fffd4002420) at remote_dispatch.h:4050 #8 0x00007ffff73b293f in virNetServerProgramDispatchCall (prog=0x555555ec3ae0, server=0x555555eb7e00, client=0x555555ebaef0, msg=0x555555ebb3e0) at rpc/virnetserverprogram.c:435 #9 0x00007ffff73b207f in virNetServerProgramDispatch (prog=0x555555ec3ae0, server=0x555555eb7e00, client=0x555555ebaef0, msg=0x555555ebb3e0) at rpc/virnetserverprogram.c:305 #10 0x00007ffff73a4d2c in virNetServerProcessMsg (srv=0x555555eb7e00, client=0x555555ebaef0, prog=0x555555ec3ae0, msg=0x555555ebb3e0) at rpc/virnetserver.c:165 #11 0x00007ffff73a4e8d in virNetServerHandleJob (jobOpaque=0x555555ebc7e0, opaque=0x555555eb7e00) at rpc/virnetserver.c:186 #12 0x00007ffff7187f3f in virThreadPoolWorker (opaque=0x555555eb7ac0) at util/virthreadpool.c:144 #13 0x00007ffff718733a in virThreadHelper (data=0x555555eb7890) at util/virthreadpthread.c:161 #14 0x00007ffff468ed89 in start_thread (arg=0x7fffec8c0700) at pthread_create.c:308 #15 0x00007ffff3da26bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> (cherry picked from commit f8c1cb90) Conflicts: src/lxc/lxc_driver.c
-
- 18 10月, 2013 2 次提交
-
-
由 Zhou Yimin 提交于
Introduced by 7b87a3 When I quit the process which only register VIR_DOMAIN_EVENT_ID_REBOOT, I got error like: "libvirt: XML-RPC error : internal error: domain event 0 not registered". Then I add the following code, it fixed. Signed-off-by: NZhou Yimin <zhouyimin@huawei.com> Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 9712c251)
-
由 Martin Kletzander 提交于
Commit a0b6a36f "fixed" what abfff210 broke (URI precedence), but there was still one more thing missing to fix. When using virsh parameters to setup debugging, those weren't honored, because at the time debugging was initializing, arguments weren't parsed yet. To make ewerything work as expected, we need to initialize the debugging twice, once before debugging (so we can debug option parsing properly) and then again after these options are parsed. As a side effect, this patch also fixes a leak when virsh is ran with multiple '-l' parameters. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> (cherry picked from commit ac43da70)
-
- 15 10月, 2013 6 次提交
-
-
由 Martin Kletzander 提交于
Commit abfff210 changed the order of vshParseArgv() and vshInit() in order to make fix debugging of parameter parsing. However, vshInit() did a vshReconnect() even though ctl->name wasn't set according to the '-c' parameter yet. In order to keep both issues fixed, I've split the vshInit() into vshInitDebug() and vshInit(). One simple memleak of ctl->name is fixed as a part of this patch, since it is related to the issue it's fixing. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=999323 (cherry picked from commit a0b6a36f)
-
由 Daniel Hansel 提交于
Introduced by commit 3f029fb5 the RPM build was broken due to a missing LXC textcase. Signed-off-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com> (cherry picked from commit 6285c17f)
-
由 Ján Tomko 提交于
Since 76b644c3 when the support for RAM filesystems was introduced, libvirt accepted the following XML: <source usage='1024' unit='KiB'/> This was parsed correctly and internally stored in bytes, but it was formatted as (with an extra 's'): <source usage='1024' units='KiB'/> When read again, this was treated as if the units were missing, meaning libvirt was unable to parse its own XML correctly. The usage attribute was documented as being in KiB, but it was not scaled if the unit was missing. Transient domains still worked, because this was balanced by an extra 'k' in the mount options. This patch: Changes the parser to use 'units' instead of 'unit', as the latter was never documented (fixing persistent domains) and some programs (libvirt-glib, libvirt-sandbox) already parse the 'units' attribute. Removes the extra 'k' from the tmpfs mount options, which is needed because now we parse our own XML correctly. Changes the default input unit to KiB to match documentation, fixing: https://bugzilla.redhat.com/show_bug.cgi?id=1015689 (cherry picked from commit 3f029fb5) Conflicts: src/conf/domain_conf.c src/lxc/lxc_container.c
-
由 Michal Privoznik 提交于
After successful @cmd construction the memory where @keys points to is part of @cmd. Avoid double freeing it. (cherry picked from commit 3e8343e1)
-
由 Liuji (Jeremy) 提交于
After freeing the bitmap pointer, it must set the pointer to NULL. This will avoid any other use of the freed memory of the bitmap pointer. https://bugzilla.redhat.com/show_bug.cgi?id=1006710Signed-off-by: NLiuji (Jeremy) <jeremy.liu@huawei.com> (cherry picked from commit ef5d51d4)
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1006864 Commit 38ab1225 changed the default value of ret from true to false but forgot to set ret = true when job is NONE. Thus, virsh domjobinfo returned 1 when there was no job running for a domain but it used to (and should) return 0 in this case. (cherry picked from commit f084caae)
-
- 07 10月, 2013 1 次提交
-
-
由 Claudio Bley 提交于
Commit 27e81517 set the payload size to 256 KB, which is actually the max packet size, including the size of the header. Reduce this by VIR_NET_MESSAGE_HEADER_MAX (24) and set VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX to 262120, which was the original value before increasing the limit in commit eb635de1. (cherry picked from commit 609eb987)
-
- 01 10月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The libvirtd server pushes data out to clients. It does not know what protocol version the client might have, so must be conservative and use the old payload limits. ie send no more than 256kb of data per packet. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 27e81517)
-
- 19 9月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The 'stats' variable was not initialized to NULL, so if some early validation of the RPC call fails, it is possible to jump to the 'cleanup' label and VIR_FREE an uninitialized pointer. This is a security flaw, since the API can be called from a readonly connection which can trigger the validation checks. This was introduced in release v0.9.1 onwards by commit 158ba873 Author: Daniel P. Berrange <berrange@redhat.com> Date: Wed Apr 13 16:21:35 2011 +0100 Merge all returns paths from dispatcher into single path Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit e7f400a1) Conflicts: daemon/remote.c - context
-
- 18 9月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
With the existing pkcheck (pid, start time) tuple for identifying the process, there is a race condition, where a process can make a libvirt RPC call and in another thread exec a setuid application, causing it to change to effective UID 0. This in turn causes polkit to do its permission check based on the wrong UID. To address this, libvirt must get the UID the caller had at time of connect() (from SO_PEERCRED) and pass a (pid, start time, uid) triple to the pkcheck program. Signed-off-by: NColin Walters <walters@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 922b7fda) Conflicts: src/access/viraccessdriverpolkit.c Resolution: Dropped file that does not exist in this branch.
-
- 05 9月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
The @qemunbd variable can be used uninitialized. (cherry picked from commit 2dba0323)
-
- 20 8月, 2013 1 次提交
-
-
由 Peter Krempa 提交于
The virBitmapParse function was calling virBitmapIsSet() function that requires the caller to check the bounds of the bitmap without checking them. This resulted into crashes when parsing a bitmap string that was exceeding the bounds used as argument. This patch refactors the function to use virBitmapSetBit without checking if the bit is set (this function does the checks internally) and then counts the bits in the bitmap afterwards (instead of keeping track while parsing the string). This patch also changes the "parse_error" label to a more common "error". The refactor should also get rid of the need to call sa_assert on the returned variable as the callpath should allow coverity to infer the possible return values. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=997367 Thanks to Alex Jia for tracking down the issue. This issue is introduced by commit 0fc89098. (cherry picked from commit 47b9127e)
-
- 12 7月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
Remove assignment of the string freed by virURIFree to hostname, since it's not used anywhere. Double free introduced by ddf8ad82, useless code introduced by f03dcc5d. https://bugzilla.redhat.com/show_bug.cgi?id=977961 (cherry picked from commit 5744d96f)
-
- 11 7月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
Don't reuse the return value of virStorageBackendFileSystemIsMounted. If it's 0, we'd return it even if the mount command failed. Also, don't report another error if it's -1, since one has already been reported. Introduced by 258e06c8. https://bugzilla.redhat.com/show_bug.cgi?id=981251 (cherry picked from commit 13fde7ce)
-
由 Ján Tomko 提交于
If qemuMonitorBlockJob returned 0, qemuDomainBlockPivot might return 0 even if an error occured. https://bugzilla.redhat.com/show_bug.cgi?id=977678 (cherry picked from commit c34107df)
-
- 09 7月, 2013 1 次提交
-
-
由 Viktor Mihajlovski 提交于
The device bus value was used instead of the device target when building the sysfs device path. Trivial. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com> (cherry picked from commit 2c94e00c)
-
- 01 7月, 2013 1 次提交
-
-
由 Dennis Chen 提交于
When creating a virtual FC HBA with virsh/libvirt API, an error message will be returned: "error: Node device not found", also the 'nodedev-dumpxml' shows wrong information of wwpn & wwnn for the new created device. Signed-off-by: xschen@tnsoft.com.cn This reverts f90af691 which switched wwpn & wwwn in the wrong place. https://www.kernel.org/doc/Documentation/scsi/scsi_fc_transport.txt (cherry picked from commit 3c0d5e22)
-