- 18 12月, 2015 2 次提交
-
-
由 John Ferlan 提交于
Rather than continually cut/paste the "pool" option for pool command option structures, generate a macro which will commonly define it for any command. Then of course use that macro.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=830056 Add flags handling to the virStoragePoolCreate and virStoragePoolCreateXML API's which will allow the caller to provide the capability for the storage pool create API's to also perform a pool build during creation rather than requiring the additional buildPool step. This will allow transient pools to be defined, built, and started. The new flags are: * VIR_STORAGE_POOL_CREATE_WITH_BUILD Perform buildPool without any flags passed. * VIR_STORAGE_POOL_CREATE_WITH_BUILD_OVERWRITE Perform buildPool using VIR_STORAGE_POOL_BUILD_OVERWRITE flag. * VIR_STORAGE_POOL_CREATE_WITH_BUILD_NO_OVERWRITE Perform buildPool using VIR_STORAGE_POOL_BUILD_NO_OVERWRITE flag. It is up to the backend to handle the processing of build flags. The overwrite and no-overwrite flags are mutually exclusive. NB: This patch is loosely based upon code originally authored by Osier Yang that were not reviewed and pushed, see: https://www.redhat.com/archives/libvir-list/2012-July/msg01328.html
-
- 17 12月, 2015 19 次提交
-
-
由 Ján Tomko 提交于
This function is no longer used outside domain_addr.c
-
由 Ján Tomko 提交于
This function calls qemuDomainAttachControllerDevice for SCSI controllers and reports an error for all other controllers. Move the error inside qemuDomainAttachControllerDevice and delete this wrapper.
-
由 Cédric Bosdonnat 提交于
Add a configure option to disable virt-login-shell build even if lxc is enabled.
-
由 John Ferlan 提交于
Commit id '71b803ac' assumed that the storage pool source device path was required for a 'logical' pool. This resulted in a failure to start a pool without any device path defined. So, adjust the virStorageBackendLogicalMatchPoolSource logic to return success if at least the pool name matches the vgs output when no pool source device path is/are provided.
-
由 John Ferlan 提交于
A closer review of the code shows that for the transition from paused to running which was supposed to emit the VIR_DOMAIN_EVENT_RESUMED - no event would be generated. Rather the event is generated when going from running to running. Following the 'was_running' boolean shows it is set when the domain obj is active and the domain obj state is VIR_DOMAIN_RUNNING. So rather than using was_running to generate the RESUMED event, use !was_running
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1270709 When a volume wipe is successful, perform a volume refresh afterwards to update any volume data that may be used in future volume commands, such as volume resize. For a raw file volume, a wipe could truncate the file and a followup volume resize the capacity may fail because the volume target allocation isn't updated to reflect the wipe activity.
-
由 Ján Tomko 提交于
It is not used by the caller.
-
由 Ján Tomko 提交于
The only caller always passes 0 for the extent start. Drop the 'extent_start' parameter, as well as the mention of extents from the function name. Change off_t extent_length to unsigned long long wipe_len, as well as the 'remain' variable.
-
由 Ján Tomko 提交于
We do not need to pass a zero-filled buffer as an argument, the function can allocate its own.
-
由 Ján Tomko 提交于
Return -1: * on all failures of fdatasync. Instead of propagating -errno all the way up to the virStorageVolWipe API, which is documented to return 0 or -1. * after a partial wipe. If safewrite failed, we would re-use the non-negative return value of lseek (which should be 0 in this case, because that's the only offset we seek to).
-
由 Andrea Bolognani 提交于
MemLock is already used in other modules and, while still an abbreviation, is not ambiguous.
-
由 Andrea Bolognani 提交于
When the function changes the memory lock limit for the first time, it will retrieve the current value and store it inside the virDomainObj for the domain. When the function is called again, if memory locking is no longer needed, it will be able to restore the memory locking limit to its original value.
-
由 Andrea Bolognani 提交于
We increase the limit before plugging in a PCI hostdev or a memory module because some memory might need to be locked due to eg. VFIO. Of course we should do the opposite after unplugging a device: this was already the case for memory modules, but not for PCI hostdevs.
-
由 Andrea Bolognani 提交于
Replace all uses of the qemuDomainRequiresMlock/virProcessSetMaxMemLock combination with the equivalent qemuDomainAdjustMaxMemLock() call.
-
由 Andrea Bolognani 提交于
This function detects whether a domain needs RLIMIT_MEMLOCK to be set, and if so, uses an appropriate value.
-
由 Andrea Bolognani 提交于
This function can be used to retrieve the current locked memory limit for a process, so that the setting can be later restored. Add a configure check for getrlimit(), which we now use.
-
由 Andrea Bolognani 提交于
The prlimit() function allows both getting and setting limits for a process; expose the same functionality in our wrapper. Add the const modifier for new_limit, in accordance with the prototype for prlimit().
-
由 Eric Blake 提交于
Cygwin cannot build the vbox driver yet: CC vbox/libvirt_driver_vbox_impl_la-vbox_glue.lo In file included from vbox/vbox_glue.c:27:0: vblox/vbox_XPCOMCGlue.c:63:3: error: #error "Port me" # error "Port me" ^ In file included from vbox/vbox_XPCOMCGlue.c:45:0, from vbox/vbox_glue.c:27: vbox/vbox_XPCOMCGlue.c: In function 'tryLoadOne': vbox/vbox_XPCOMCGlue.c:98:46: error: 'DYNLIB_NAME' undeclared (first use in this function) if (virAsprintf(&name, "%s/%s", dir, DYNLIB_NAME) < 0) ^ ./util/virstring.h:245:31: note: in definition of macro 'virAsprintf' strp, __VA_ARGS__) ^ Rather than trying to figure out how to get dynamic loading of vbox to work under cygwin (since I don't even have a working vbox setup to test whether it works), I'm going to be lazy and just default to not even trying vbox on cygwin.
-
- 16 12月, 2015 10 次提交
-
-
由 Martin Kletzander 提交于
In commit 686eb7a2, the break was not considered part of the condition, hence breaking after first node when searching. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Andrea Bolognani 提交于
Instead of replicating the information (domain, bus, slot, function) inside the virPCIDevice structure, use the already-existing virPCIDeviceAddress structure. For users of the module, this means that the object returned by virPCIDeviceGetAddress() can no longer be NULL and must no longer be freed by the caller.
-
由 Ian Campbell 提交于
Upstream Xen is in the process of splitting the (stable API) xtl_* interfaces out from the (unstable API) libxenctrl library and into a new (stable API) libxentoollog. In order to be compatible with Xen both before and after this transition check for xtl_createlogger_stdiostream in a libxentoollog library and use it if present. If it is not present assume it is in libxenctrl. Compile tested on Xen 4.6 and a development tree with the split in place. Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
-
由 Joao Martins 提交于
Introduces support for domainGetJobStats which has the same info as domainGetJobInfo but in a slightly different format. Another difference is that virDomainGetJobStats can also retrieve info on the most recently completed job. Though so far this is only used in the source node to know if the migration has been completed. But because we don't support completed jobs we will deliver an error. Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
-
由 Joao Martins 提交于
Introduce support for domainGetJobInfo to get info about the ongoing job. If the job is active it will update the timeElapsed which is computed with the "started" field added to struct libxlDomainJobObj. For now we support just the very basic info and all jobs have VIR_DOMAIN_JOB_UNBOUNDED (i.e. no completion time estimation) plus timeElapsed computed. Openstack Kilo uses the Job API to monitor live-migration progress which is currently nonexistent in libxl driver and therefore leads to a crash in the nova compute node. Right now, migration doesn't use jobs in the source node and will return VIR_DOMAIN_JOB_NONE. Though nova handles this case and will migrate it properly instead of crashing. Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1025230 Add a new helper virStorageBackendLogicalMatchPoolSource to compare the pool's source name against the output from a 'pvs' command to list all volume group physical volume data on the host. In addition, compare the pool's source device list against the particular volume group's device list to ensure the source device(s) listed for the pool match what the was listed for the volume group. Then for pool startup or check API's we need to call this new API in order to ensure that the pool we're about to start or declare active during checkPool has a valid definition vs. the running host.
-
由 John Ferlan 提交于
Rework virStorageBackendLogicalFindPoolSources a bit to create a helper virStorageBackendLogicalGetPoolSources that will make the pvs call in order to generate a list of associated pv_name and vg_name's. A future patch will make use of this for start/check processing to ensure the storage pool source definition matches expectations.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1025230 When determining whether a FS pool is mounted, rather than assuming that the FS pool is mounted just because the target.path is in the mount list, let's make sure that the FS pool source matches what is mounted
-
由 John Ferlan 提交于
Refactor code to use standard return functioning with respect to setting a ret value and going to cleanup.
-
由 John Ferlan 提交于
Refactor the code that builds the pool source string during the FS storage pool mount to be a separate helper. A future patch will use the helper in order to validate the mounted FS matches the pool's expectation during poolCheck processing
-
- 15 12月, 2015 9 次提交
-
-
由 Laine Stump 提交于
when appropriate, of course. If the config for a domain specifies boot order with <boot dev='blah'/> elements, e.g.: <os> ... <boot dev='hd'/> <boot dev='network'/> </os> Then the first disk device in the config will have ",bootindex=1" appended to its qemu commandline -device options, and the first (and *only* the first) network interface device will get ",bootindex=2". However, if the first network interface device is a "hostdev" device (an SRIOV Virtual Function (VF) being assigned to the domain with vfio), then the bootindex option will *not* be appended. This happens because the bootindex=n option corresponding to the order of "<boot dev='network'/>" is added to the -device for the first network device when network device commandline args are constructed, but if it's a hostdev network device, its commandline arg is instead constructed in the loop for hostdevs. This patch fixes that omission by noticing (in bootHostdevNet) if the first network device was a hostdev, and if so passing on the proper bootindex to the commandline generator for hostdev devices - the result is that ",bootindex=2" will be properly appended to the first "network" device in the config even if it is really a hostdev (including if it is assigned from a libvirt network pool). (note that this is only the case if there is no <bootmenu enabled='yes'/> element in the config ("-boot menu-on" in qemu) , since the two are mutually exclusive - when the bootmenu is enabled, the individual per-device bootindex options can't be used by qemu, and we revert to using "-boot order=xyz" instead). If a greater level of control over boot order is desired (e.g., more than one network device should be tried, or a network device other than the first one encountered in the config), then <boot dev='network'/> in the <os> element should not be used; instead, the individual device elements in the config should be given a "<boot order='n'/> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1278421
-
由 Ján Tomko 提交于
Many of the functions follow the pattern: virSecurity.*Security.*Label Remove the second 'Security' from the names, it should be obvious that the virSecurity* functions deal with security labels even without it.
-
由 Ján Tomko 提交于
Many of the functions follow the pattern: virSecurity.*Security.*Label Remove the second 'Security' from the names, it should be obvious that the virSecurity* functions deal with security labels even without it.
-
由 Ján Tomko 提交于
Many of the functions follow the pattern: virSecurity.*Security.*Label Remove the second 'Security' from the names, it should be obvious that the virSecurity* functions deal with security labels even without it.
-
由 Pavel Hrdina 提交于
Commit 256496e1 introduced a detection if "is locked" in error replay from qemu monitor. Commit c4073657 fixed a memory leak, but it was pointed out by Peter, that this could be done cleaner without stringifing the replay. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Andrea Bolognani 提交于
The name 'dev' is more appropriate for virPCIDevicePtr.
-
由 Michal Privoznik 提交于
The return value of virJSONValueToString() should be freed when no longer needed. This is not the case after 256496e1. ==26902== 138 bytes in 2 blocks are definitely lost in loss record 1,051 of 1,239 ==26902== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26902== by 0xAA5F599: strdup (in /lib64/libc-2.21.so) ==26902== by 0x552BAD9: virStrdup (virstring.c:726) ==26902== by 0x54F60A7: virJSONValueToString (virjson.c:1790) ==26902== by 0x1DF6EBB9: qemuMonitorJSONEjectMedia (qemu_monitor_json.c:2225) ==26902== by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985) ==26902== by 0x1DF1EF2D: qemuDomainChangeEjectableMedia (qemu_hotplug.c:199) ==26902== by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985) ==26902== by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030) ==26902== by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677) ==26902== by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559) ==26902== by 0x134210: remoteDispatchDomainUpdateDeviceFlags (remote_dispatch.h:10966) ==26902== 106 bytes in 1 blocks are definitely lost in loss record 1,033 of 1,239 ==26902== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26902== by 0xAA5F599: strdup (in /lib64/libc-2.21.so) ==26902== by 0x552BAD9: virStrdup (virstring.c:726) ==26902== by 0x54F60A7: virJSONValueToString (virjson.c:1790) ==26902== by 0x1DF6EC0C: qemuMonitorJSONEjectMedia (qemu_monitor_json.c:2227) ==26902== by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985) ==26902== by 0x1DF1EF2D: qemuDomainChangeEjectableMedia (qemu_hotplug.c:199) ==26902== by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985) ==26902== by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030) ==26902== by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677) ==26902== by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559) ==26902== by 0x134210: remoteDispatchDomainUpdateDeviceFlags (remote_dispatch.h:10966) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Henning Schild 提交于
Moving tasks to cgroups implied sched_setaffinity. Changing the cpus in a set implies the same for all tasks in the group. The old code put the the thread into the cpuset inherited from the machine cgroup, which allowed it to run outside of vcpupin for a short while. Signed-off-by: NHenning Schild <henning.schild@siemens.com>
-
由 Henning Schild 提交于
The machine cgroup is a superset, a parent to the emulator and vcpuX cgroups. The parent cgroup should never have any tasks directly in it. In fact the parent cpuset might contain way more cpus than the sum of emulatorpin and vcpupins. So putting tasks in the superset will allow them to run outside of <cputune>. Signed-off-by: NHenning Schild <henning.schild@siemens.com>
-