- 15 12月, 2015 10 次提交
-
-
由 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>
-
由 Henning Schild 提交于
virCgroupNewMachine used to add the pidleader to the newly created machine cgroup. Do not do this implicit anymore. Signed-off-by: NHenning Schild <henning.schild@siemens.com>
-
- 14 12月, 2015 2 次提交
-
-
由 Michal Privoznik 提交于
Firstly, there's a bug (or typo) in the only place where we call this function: @multiqueue is set whenever @tapfdSize is greater than zero, while in fact the condition should have been 'greater than one'. Then, secondly, since the condition depends on just one variable, that we are even passing down to the function, we can move the condition into the function and drop useless argument. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Martin Kletzander 提交于
When user configures vhost-user interface and forgets to also configure any shared memory, the search for the root cause of non-operational interface might take unpleasantly long time. Let's enhance user experience by emitting a warning in the logs. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1266982Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 13 12月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
Some older systems, e.g. RHEL-6 do not have IFF_MULTI_QUEUE flag which we use to enable multiqueue feature. Therefore one gets the following compile error there: CC util/libvirt_util_la-virnetdevmacvlan.lo util/virnetdevmacvlan.c: In function 'virNetDevMacVLanTapSetup': util/virnetdevmacvlan.c:338: error: 'IFF_MULTI_QUEUE' undeclared (first use in this function) util/virnetdevmacvlan.c:338: error: (Each undeclared identifier is reported only once util/virnetdevmacvlan.c:338: error: for each function it appears in.) make[3]: *** [util/libvirt_util_la-virnetdevmacvlan.lo] Error 1 So, whenever user wants us to enable the feature on such systems, we will just throw a runtime error instead. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 12月, 2015 1 次提交
-
-
由 Eric Blake 提交于
The libvirt file system storage driver determines what file to act on by concatenating the pool location with the volume name. If a user is able to pick names like "../../../etc/passwd", then they can escape the bounds of the pool. For that matter, virStoragePoolListVolumes() doesn't descend into subdirectories, so a user really shouldn't use a name with a slash. Normally, only privileged users can coerce libvirt into creating or opening existing files using the virStorageVol APIs; and such users already have full privilege to create any domain XML (so it is not an escalation of privilege). But in the case of fine-grained ACLs, it is feasible that a user can be granted storage_vol:create but not domain:write, and it violates assumptions if such a user can abuse libvirt to access files outside of the storage pool. Therefore, prevent all use of volume names that contain "/", whether or not such a name is actually attempting to escape the pool. This changes things from: $ virsh vol-create-as default ../../../../../../etc/haha --capacity 128 Vol ../../../../../../etc/haha created $ rm /etc/haha to: $ virsh vol-create-as default ../../../../../../etc/haha --capacity 128 error: Failed to create vol ../../../../../../etc/haha error: Requested operation is not valid: volume name '../../../../../../etc/haha' cannot contain '/' Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 11 12月, 2015 10 次提交
-
-
由 John Ferlan 提交于
Commit id '56e2171c' removed a variable from the argument list, but neglected to update the ATTRIBUTE_NONNULL values, so when commit id '08da97bf' added a couple of arguments, the values were off.
-
由 Peter Krempa 提交于
Always return LLONG_MAX even on 32 bit systems. The limitation originates from our use of "unsigned long" in several APIs. The internal data type is unsigned long long. Make the test suite deterministic by removing the architecture difference. Flaw was introduced in 64588113 where I've added a test that uses too large numbers.
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1240439 Ta-da! Now that we know how to open a macvtap device multiple times, we can finally enable the multiqueue feature. Everything else is already prepared (e.g. command line generation) from the previous iteration where the feature was implemented for TUN/TAP devices. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
For the multiqueue on macvtaps we are going to need to open the device multiple times. Currently, this is not supported. Rework the function, so that upper layers can be reworked too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Like we are doing for TUN/TAP devices, we should do the same for macvtaps. Although, it's not as critical as in that case, we should do it for the consistency. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
For the multiqueue on macvtaps we are going to need to open the device multiple times. Currently, this is not supported. Rework the function, so that upper layers can be reworked too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
For the multiqueue on macvtaps we are going to need to open the device multiple times. Currently, this is not supported. Rework the function, so that upper layers can be reworked too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
There are few outdated things. Firstly, we don't need to undergo the torture of fopen, fscanf and fclose just to get the interface index when we have nice wrapper over that: virNetDevGetIndex. Secondly, we don't need to have statically allocated buffer for the path we are opening. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So yet again one of integer arguments that we use as a boolean. Since the argument count of the function is unbearably long enough, lets turn those booleans into flags. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrange 提交于
On the very first log message we send to any output, we include the libvirt version number and package string. In some bug reports we have been given libvirtd.log files that came from a different host than the corresponding /var/log/libvirt/qemu log files. So extend the initial log message to include the hostname too. eg on first log message we would now see: $ libvirtd 2015-12-04 17:35:36.610+0000: 20917: info : libvirt version: 1.3.0 2015-12-04 17:35:36.610+0000: 20917: info : hostname: dhcp-1-180.lcy.redhat.com 2015-12-04 17:35:36.610+0000: 20917: error : qemuMonitorIO:687 : internal error: End of file from monitor Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 10 12月, 2015 6 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1276198 Prior to commit id '98322052' failure to saferead the block device would cause an error to be logged and the device to be skipped while attempting to discover/create a stable target path for a new LUN (NPIV). This was because virStorageBackendSCSIFindLUs ignored errors from processLU and virStorageBackendSCSINewLun. Ignoring the failure allowed a multipath device with an "active" and "ghost" to be present on the host with the "ghost" block device being ignored. This patch will return a -2 to the caller indicating the desire to ignore the block device since it cannot be used directly rather than fail the pool startup.
-
由 John Ferlan 提交于
I found this useful while processing a volume that wouldn't end up showing up in the resulting list of block volumes. In this case, the partition type wasn't found in the disk_types table.
-
由 John Ferlan 提交于
Similar to the openflags VIR_STORAGE_VOL_OPEN_NOERROR processing, if some read processing operation fails, check the readflags for the corresponding error flag being set. If so, rather then causing an error - use VIR_WARN to flag the error, but return -2 which some callers can use to perform specific actions. Use a new VIR_STORAGE_VOL_READ_NOERROR flag in a new VolReadErrorMode enum.
-
由 John Ferlan 提交于
While processing the volume for lseek, virFileReadHeaderFD, and virStorageFileGetMetadataFromBuf - failure would cause an error, but ret would not be set. That would result in an error message being sent, but successful status being returned.
-
由 John Ferlan 提交于
Just so it's clearer what to expect upon input and what types of return values could be generated. These were loosely copied from existing virStorageBackendUpdateVolTargetInfoFD.
-
由 John Ferlan 提交于
Similar to the openflags which allow VIR_STORAGE_VOL_OPEN_NOERROR to be passed to avoid open errors, add a 'readflags' variable so that in the future read failures could also be ignored.
-
- 09 12月, 2015 10 次提交
-
-
由 Peter Krempa 提交于
Use the proper data structures for the iteration since ncpupids will be made private later.
-
由 Peter Krempa 提交于
Change some of the control structures and switch to using the new vcpu structure.
-
由 Peter Krempa 提交于
Instead of directly accessing the array add a helper to do this.
-
由 Peter Krempa 提交于
Add qemuDomainHasVCpuPids to do the checking and replace in place checks with it. We no longer need checking whether the thread contains fake data (vcpupids[0] == vm->pid) as in b07f3d82 and 65686e5a this was removed.
-
由 Peter Krempa 提交于
The vCPU threads make sense in the counterparts that set the vCPU bandwidth/quota, not in the emulator one. The emulator tunables are set all the time anyways. Drop the extra check and remove the now unneeded vm argument.
-
由 Peter Krempa 提交于
Since commit 0c04906f the check for priv->cgroup doesn't make sense as the calls to virCgroupHasController return the same information. Remove it and move it's comment partially to the new check. The already spurious check was also later copied to the iothreads code.
-
由 Peter Krempa 提交于
Once more stuff will be moved into the vCPU data structure it will be necessary to get a specific one in some ocasions. Add a helper that will simplify this task.
-
由 Peter Krempa 提交于
Extract the checking code into a separate function and prepare the infrastructure for checking the new structure type.
-
由 Peter Krempa 提交于
To allow collecting all relevant data at one place let's make def->vcpus a structure and then we can start moving stuff into it.
-
由 Peter Krempa 提交于
Refactor the code flow so that 'exit_monitor:' can be removed. This patch moves the auditing functions into places where it's certain that hotunplug was or was not successful and reports errors from qemuMonitorGetCPUInfo properly.
-