- 30 4月, 2015 4 次提交
-
-
由 Jiri Denemark 提交于
Only USB addresses are allowed for USB disks. Report an error if another address is configured. https://bugzilla.redhat.com/show_bug.cgi?id=1043436Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=858147Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Ján Tomko 提交于
Just as we allow stopping filesystem pools when they were unmounted externally, do not fail to stop an iscsi pool when someone else closed the session externally. Reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1171984
-
由 Jim Fehlig 提交于
Provide integration with libvirt's lock manager in the libxl driver. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
- 29 4月, 2015 11 次提交
-
-
由 Cole Robinson 提交于
The phyp driver stuffed it into a DomainDefPtr during its attachdevice routine, but the value is never advertised via capabilities so it should be safe to drop. Have the phyp driver use OSTYPE_LINUX, which is what it advertises via capabilities.
-
由 Michael Chapman 提交于
In qemuMigrationDriveMirror we can start all disk mirrors in parallel. We wait until they are all ready, or one of them aborts. In qemuMigrationCancelDriveMirror, we wait until all mirrors are properly stopped. This is necessary to ensure that destination VM is fully in sync with the (paused) source VM. If a drive mirror can not be cancelled, then the destination is not in a consistent state. In this case it is not safe to continue with the migration. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
The !modern code path needs to call qemuBlockJobEventProcess directly. the modern code path will call it via qemuBlockJobSyncWait. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
Other threads may be blocked in qemuBlockJobSyncWait. Ensure that they're woken up when the domain is stopped. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
qemuBlockJobSyncBegin and qemuBlockJobSyncEnd delimit a region of code where block job events are processed "synchronously". qemuBlockJobSyncWait and qemuBlockJobSyncWaitWithTimeout wait for an event generated by a block job. The Wait* functions may be called multiple times while the synchronous block job is active. Any pending block job event will be processed by only when Wait* or End is called. disk->blockJobStatus is reset by these functions, so if it is needed a pointer to a virConnectDomainEventBlockJobStatus variable should be passed as the last argument. It is safe to pass NULL if you do not care about the block job status. All functions assume the VM object is locked. The Wait* functions will unlock the object for as long as they are waiting. They will return -1 and report an error if the domain exits before an event is received. Typical use is as follows: virQEMUDriverPtr driver; virDomainObjPtr vm; /* locked */ virDomainDiskDefPtr disk; virConnectDomainEventBlockJobStatus status; qemuBlockJobSyncBegin(disk); ... start block job ... if (qemuBlockJobSyncWait(driver, vm, disk, &status) < 0) { /* domain died while waiting for event */ ret = -1; goto error; } ... possibly start other block jobs or wait for further events ... qemuBlockJobSyncEnd(driver, vm, disk, NULL); To perform other tasks periodically while waiting for an event: virQEMUDriverPtr driver; virDomainObjPtr vm; /* locked */ virDomainDiskDefPtr disk; virConnectDomainEventBlockJobStatus status; unsigned long long timeout = 500 * 1000ull; /* milliseconds */ qemuBlockJobSyncBegin(disk); ... start block job ... do { ... do other task ... if (qemuBlockJobSyncWaitWithTimeout(driver, vm, disk, timeout, &status) < 0) { /* domain died while waiting for event */ ret = -1; goto error; } } while (status == -1); qemuBlockJobSyncEnd(driver, vm, disk, NULL); Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
We will want to use synchronous block jobs from qemu_migration as well, so split this function out into a new source file. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Peter Krempa 提交于
While qemu would reject the configuration we can check whether it makes sense to plug the device upfront.
-
由 Peter Krempa 提交于
slot id, if specified, has to be less than the slots count.
-
由 Peter Krempa 提交于
If the added memory device would exceed the maximum memory size, reject it. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1216046
-
由 Peter Krempa 提交于
The documentation states that for shallow block copy the image has to have the same guest visible content as backing file of the current image if the file is being reused. This condition can be achieved also with a raw file (or a qcow without a backing file) so remove the condition that would disallow it. (This patch additionally fixes crash described in https://bugzilla.redhat.com/show_bug.cgi?id=1215569 )
-
由 Maxim Nestratov 提交于
New functions utilize previosly added prlsdkDelDisk and prlsdkGetDiskIndex Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>
-
- 28 4月, 2015 25 次提交
-
-
由 Maxim Nestratov 提交于
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NPavel Fedin <p.fedin@samsung.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Zhang Bo 提交于
The free callback should be qemuMonitorChardevInfoFree rather than just 'free' when virHashCreate'ing the chardevInfo hash. ==29959== 24 bytes in 2 blocks are definitely lost in loss record 19 of 53 ==29959== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==29959== by 0xB95C679: strdup (in /lib64/libc-2.20.so) ==29959== by 0x63C6546: virStrdup (virstring.c:709) ==29959== by 0x4805ED: qemuMonitorJSONExtractChardevInfo (qemu_monitor_json.c:3429) ==29959== by 0x4807A5: qemuMonitorJSONGetChardevInfo (qemu_monitor_json.c:3479) ==29959== by 0x434AEC: testQemuMonitorJSONqemuMonitorJSONGetChardevInfo (qemumonitorjsontest.c:1824) ==29959== by 0x436F2F: virtTestRun (testutils.c:211) ==29959== by 0x436932: mymain (qemumonitorjsontest.c:2404) ==29959== by 0x4382EA: virtTestMain (testutils.c:863) ==29959== by 0x436B27: main (qemumonitorjsontest.c:2423) Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com> Signed-off-by: NZhou Yimin <zhouyimin@huawei.com>
-
由 Zhang Bo 提交于
It would be used in qemumonitorjsontest, thus we make it non-static. Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com> Signed-off-by: NZhou Yimin <zhouyimin@huawei.com>
-
由 Cole Robinson 提交于
Trying to use qemu:///session to create a storage pool pointing at /tmp will usually fail with something like: $ virsh pool-start tmp error: Failed to start pool tmp error: cannot open volume '/tmp/systemd-private-c38cf0418d7a4734a66a8175996c384f-colord.service-kEyiTA': Permission denied If any volume in an FS pool can't be opened by the daemon, the refresh fails, and the pool can't be used. This causes pain for virt-install/virt-manager though. Imaging a user downloads a disk image to /tmp. virt-manager wants to import /tmp as a storage pool, so we can detect what disk format it is, and set the XML correctly. However this case will likely fail as explained above. Change the logic here to skip volumes that fail to open. This could conceivably cause user complaints along the lines of 'why doesn't libvirt show $ROOT-OWNED-VOLUME-FOO', but figuring that currently the pool won't even startup, I don't think there are any current users that care about that case. https://bugzilla.redhat.com/show_bug.cgi?id=1103308
-
由 Cole Robinson 提交于
If you end up with a state file for a pool that no longer starts up or refreshes correctly, the state file is never removed and adds noise to the logs everytime libvirtd is started. If the initial state syncing fails, delete the statefile.
-
由 Cole Robinson 提交于
Will simplify a future patch
-
由 Cole Robinson 提交于
After pool startup we call refreshPool(). If that fails, we leave a stale pool state file hanging around. Hit this trying to create a pool with qemu:///session containing root owned files.
-
qemu:///session由 Cole Robinson 提交于
-
由 John Ferlan 提交于
Replace with just VIR_FREE.
-
由 John Ferlan 提交于
If we received zero iothreads from the monitor, but were perhaps expecting to receive something, then the code was skipping the check to ensure what's in the monitor matches our expectations. So invert the checks to check that what we get back matches expectations and then check there are zero iothreads returned.
-
由 John Ferlan 提交于
Rather than have a separate routine to parse the alias of an iothread returned from qemu in order to get the iothread_id value, parse the alias when returning and just return the iothread_id in qemuMonitorIOThreadInfoPtr This set of patches removes the function, changes the "char *name" to "unsigned int" and handles all the fallout.
-
由 John Ferlan 提交于
Resolve some Coverity errors with IOThread changes Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Roman Bogorodskiy 提交于
Build with clang fails with: CC conf/libvirt_conf_la-domain_conf.lo conf/domain_conf.c:13377:9: error: variable 'cpumask' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] if (!(tmp = virXMLPropString(node, "cpuset"))) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and many other similar errors regarding the 'cpuset' variable. Fix by explicitly initializing it with NULL.
-
由 Laine Stump 提交于
If someone has updated a network to change its bridge name, but the network is still active (so that bridge name hasn't taken effect yet), we still want to disallow another network from taking that new name.
-
由 Laine Stump 提交于
Since some people use the same naming convention as libvirt for bridge devices they create outside the context of libvirt, it is much nicer if we check for those devices when looking for a bridge device name to auto-assign to a new network.
-
由 Laine Stump 提交于
We already check that any auto-assigned bridge device name for a virtual network (e.g. "virbr1") doesn't conflict with the bridge name for any existing libvirt network (via virNetworkSetBridgeName() in conf/network_conf.c). We also want to check that the name doesn't conflict with any bridge device created on the host system outside the control of libvirt (history: possibly due to the ploriferation of references to libvirt's bridge devices in HOWTO documents all around the web, it is not uncommon for an admin to manually create a bridge in their host's system network config and name it "virbrX"). To add such a check to virNetworkBridgeInUse() (which is called by virNetworkSetBridgeName()) we would have to call virNetDevExists() (from util/virnetdev.c); this function calls ioctl(SIOCGIFFLAGS), which everyone on the mailing list agreed should not be done from an XML parsing function in the conf directory. To remedy that problem, this patch removes virNetworkSetBridgeName() from conf/network_conf.c and puts an identically functioning networkBridgeNameValidate() in network/bridge_driver.c (because it's reasonable for the bridge driver to call virNetDevExists(), although we don't do that yet because I wanted this patch to have as close to 0 effect on function as possible). There are a couple of inevitable changes though: 1) We no longer check the bridge name during virNetworkLoadConfig(). Close examination of the code shows that this wasn't necessary anyway - the only *correct* way to get XML into the config files is via networkDefine(), and networkDefine() will always call networkValidate(), which previously called virNetworkSetBridgeName() (and now calls networkBridgeNameValidate()). This means that the only way the bridge name can be unset during virNetworkLoadConfig() is if someone edited the config file on disk by hand (which we explicitly prohibit). 2) Just on the off chance that somebody *has* edited the file by hand, rather than crashing when they try to start their malformed network, a check for non-NULL bridge name has been added to networkStartNetworkVirtual(). (For those wondering why I don't instead call networkValidateBridgeName() there to set a bridge name if one wasn't present - the problem is that during networkStartNetworkVirtual(), the lock for the network being started has already been acquired, but the lock for the network list itself *has not* (because we aren't adding/removing a network). But virNetworkBridgeInuse() iterates through *all* networks (including this one) and locks each network as it is checked for a duplicate entry; it is necessary to lock each network even before checking if it is the designated "skip" network because otherwise some other thread might acquire the list lock and delete the very entry we're examining. In the end, permitting a setting of the bridge name during network start would require that we lock the entire network list during any networkStartNetwork(), which eliminates a *lot* of parallelism that we've worked so hard to achieve (it can make a huge difference during libvirtd startup). So rather than try to adjust for someone playing against the rules, I choose to instead give them the error they deserve.) 3) virNetworkAllocateBridge() (now removed) would leak any "template" string set as the bridge name. Its replacement networkFindUnusedBridgeName() doesn't leak the template string - it is properly freed.
-
由 Laine Stump 提交于
Commit ca329299 added a utility function virtTestCompareFiles() to eliminate repetitive code in several test programs. It unfortunately calls virtTestDifference() with the arguments in the wrong order - strcontent is the "actual" output gathered by the test rig, while filecontent is the "expected", and virtTestDifference() wants expected (filecontent) followed by actual (strcontent), but virtTestCompareFiles() does the opposite, which can make the output a bit confusing when there is a failure.
-
由 John Ferlan 提交于
Coverity notes that the switch() used to check 'connected' values has two DEADCODE paths (_DEFAULT & _LAST). Since 'connected' is a boolean it can only be one or the other (CONNECTED or DISCONNECTED), so it just seems pointless to use a switch to get "all" values. Convert to if-else
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1161617 Add command to allow adding and removing IOThreads from the domain including the configuration and live domain. $ virsh iothreadadd --help NAME iothreadadd - add an IOThread to the guest domain SYNOPSIS iothreadadd <domain> <id> [--config] [--live] [--current] DESCRIPTION Add an IOThread to the guest domain. OPTIONS [--domain] <string> domain name, id or uuid [--id] <number> iothread for the new IOThread --config affect next boot --live affect running domain --current affect current domain $ virsh iothreaddel --help NAME iothreaddel - delete an IOThread from the guest domain SYNOPSIS iothreaddel <domain> <id> [--config] [--live] [--current] DESCRIPTION Delete an IOThread from the guest domain. OPTIONS [--domain] <string> domain name, id or uuid [--id] <number> iothread_id for the IOThread to delete --config affect next boot --live affect running domain --current affect current domain Assuming a running $dom with multiple IOThreads assigned and that that the $dom has disks assigned to IOThread 1 and IOThread 2: $ virsh iothreadinfo $dom IOThread ID CPU Affinity --------------------------------------------------- 1 2 2 3 3 0-1 $ virsh iothreadadd $dom 1 error: invalid argument: an IOThread is already using iothread_id '1' in iothreadpids $ virsh iothreadadd $dom 1 --config error: invalid argument: an IOThread is already using iothread_id '1' in persistent iothreadids $ virsh iothreadadd $dom 4 $ virsh iothreadinfo $dom IOThread ID CPU Affinity --------------------------------------------------- 1 2 2 3 3 0-1 4 0-3 $ virsh iothreadinfo $dom --config IOThread ID CPU Affinity --------------------------------------------------- 1 2 2 3 3 0-1 $ virsh iothreadadd $dom 4 --config $ virsh iothreadinfo $dom --config IOThread ID CPU Affinity --------------------------------------------------- 1 2 2 3 3 0-1 4 0-3 Assuming the same original configuration $ virsh iothreaddel $dom 1 error: invalid argument: cannot remove IOThread 1 since it is being used by disk 'vde' $ virsh iothreaddel $dom 3 $ virsh iothreadinfo $dom IOThread ID CPU Affinity --------------------------------------------------- 1 2 2 3 $ virsh iothreadinfo $dom --config IOThread ID CPU Affinity --------------------------------------------------- 1 2 2 3 3 0-1
-
由 John Ferlan 提交于
Add qemuDomainAddIOThread and qemuDomainDelIOThread in order to add or remove an IOThread to/from the host either for live or config optoins The implementation for the 'live' option will use the iothreadpids list in order to make decision, while the 'config' option will use the iothreadids list. Additionally, for deletion each may have to adjust the iothreadpin list. IOThreads are implemented by qmp objects, the code makes use of the existing qemuMonitorAddObject or qemuMonitorDelObject APIs. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
We're about to allow IOThreads to be deleted, but an iothreadid may be included in some domain thread sched, so add a new API to allow removing an iothread from some entry. Then during the writing of the threadsched data and an additional check to determine whether the bitmap is all clear before writing it out.
-
由 John Ferlan 提交于
Add remote support for the add/delete IOThread API's
-
由 John Ferlan 提交于
Add libvirt API's to manage adding and deleting IOThreads to/from the domain
-
由 John Ferlan 提交于
With iothreadid's allowing any 'id' value for an iothread_id, the iothreadsched code needs a slight adjustment to allow for "any" unsigned int value in order to create the bitmap of ids that will have scheduler adjustments. Adjusted the doc description as well.
-