- 15 2月, 2017 2 次提交
-
-
由 Jiri Denemark 提交于
Commit 2a8d40f4 refactored qemuMonitorJSONGetCPUx86Data and replaced virJSONValueObjectGet(reply, "return") with virJSONValueObjectGetArray. While the former is guaranteed to always return non-NULL pointer the latter may return NULL if the returned JSON object is not an array. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
mknod() is affected my the current umask, so we're not guaranteed the newly-created device node will have the right permissions. Call chmod(), which is not affected by the current umask, immediately afterwards to solve the issue. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1421036
-
- 13 2月, 2017 2 次提交
-
-
由 Ján Tomko 提交于
This controller only allows up to 15 ports. https://bugzilla.redhat.com/show_bug.cgi?id=1375417
-
由 Ján Tomko 提交于
Due to a logic error, the autofilling of USB port when a bus is specified: <address type='usb' bus='0'/> does not work for non-hub devices on domain startup. Fix the logic in qemuDomainAssignUSBPortsIterator to also assign ports for USB addresses that do not yet have one. https://bugzilla.redhat.com/show_bug.cgi?id=1374128
-
- 10 2月, 2017 3 次提交
-
-
由 Michal Privoznik 提交于
==11846== 240 bytes in 1 blocks are definitely lost in loss record 81 of 107 ==11846== at 0x4C2BC75: calloc (vg_replace_malloc.c:624) ==11846== by 0x18C74242: virAllocN (viralloc.c:191) ==11846== by 0x4A05E8: qemuMonitorCPUModelInfoCopy (qemu_monitor.c:3677) ==11846== by 0x446E3C: virQEMUCapsNewCopy (qemu_capabilities.c:2171) ==11846== by 0x437335: testQemuCapsCopy (qemucapabilitiestest.c:108) ==11846== by 0x437CD2: virTestRun (testutils.c:180) ==11846== by 0x437AD8: mymain (qemucapabilitiestest.c:176) ==11846== by 0x4397B6: virTestMain (testutils.c:992) ==11846== by 0x437B44: main (qemucapabilitiestest.c:188) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc Hartmayer 提交于
Check if virQEMUCapsNewCopy(...) has failed, thus a segmentation fault in virQEMUCapsFilterByMachineType(...) will be avoided. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
-
由 David Dai 提交于
Using libvirt to do live migration over RDMA via IPv6 address failed. For example: rhel73_host1_guest1 qemu+ssh://[deba::2222]/system --verbose root@deba::2222's password: error: internal error: unable to execute QEMU command 'migrate': RDMA ERROR: could not rdma_getaddrinfo address deba As we can see, the IPv6 address used by rdma_getaddrinfo() has only "deba" part because we didn't properly enclose the IPv6 address in [] and passed rdma:deba::2222:49152 as the migration URI in qemuMonitorMigrateToHost. Signed-off-by: NDavid Dai <zdai@linux.vnet.ibm.com>
-
- 09 2月, 2017 6 次提交
-
-
由 Jaroslav Safka 提交于
This patch add support for file memory backing on numa topology. The specified access mode in memoryBacking can be overriden by specifying token memAccess in numa cell.
-
由 Jaroslav Safka 提交于
Add new parameter memory_backing_dir where files will be stored when memoryBacking source is selected as file. Value is stored inside char* memoryBackingDir
-
由 Jaroslav Safka 提交于
Rename to avoid duplicate code. Because virDomainMemoryAccess will be used in memorybacking for setting default behaviour. NOTE: The enum cannot be moved to qemu/domain_conf because of headers dependency
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Michal Privoznik 提交于
Just like we need wrappers over other virSecurityManager APIs, we need one for virSecurityManagerSetImageLabel and virSecurityManagerRestoreImageLabel. Otherwise we might end up relabelling device in wrong namespace. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 08 2月, 2017 11 次提交
-
-
由 Michal Privoznik 提交于
Firstly, instead of checking for next->path the virStorageSourceIsEmpty() function should be used which also takes disk type into account. Secondly, not every disk source passed has the correct type set (due to our laziness). Therefore, instead of checking for virStorageSourceIsBlockLocal() and also S_ISBLK() the former can be refined to just virStorageSourceIsLocalStorage(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Again, one missed bit. This time without this commit there is no /dev entry in the namespace of the qemu process when doing disk snapshots or block-copy. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
These functions do not need to see the whole virDomainDiskDef. Moreover, they are going to be called from places where we don't have access to the full disk definition. Sticking with virStorageSource is more than enough. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Since its introduction in 81df2150 this variable was never used. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
There is no need for this. None of the namespace helpers uses it. Historically it was used when calling secdriver APIs, but we don't to that anymore. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This struct is unused after 095f042e. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Again, one missed bit. This time without this commit there is no /dev entry in the namespace of the qemu process when attaching vhost SCSI device. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Since we have qemuSecurity wrappers over virSecurityManagerSetHostdevLabel and virSecurityManagerRestoreHostdevLabel we ought to use them instead of calling secdriver APIs directly. Without those wrappers the labelling won't be done in the correct namespace and thus won't apply to the nodes seen by qemu itself. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
libvirt was able to set the host_mtu option when an MTU was explicitly given in the interface config (with <mtu size='n'/>), set the MTU of a libvirt network in the network config (with the same named subelement), and would automatically set the MTU of any tap device to the MTU of the network. This patch ties that all together (for networks based on tap devices and either Linux host bridges or OVS bridges) by learning the MTU of the network (i.e. the bridge) during qemuInterfaceBridgeConnect(), and returning that value so that it can then be passed to qemuBuildNicDevStr(); qemuBuildNicDevStr() then sets host_mtu in the interface's commandline options. The result is that a higher MTU for all guests connecting to a particular network will be plumbed top to bottom by simply changing the MTU of the network (in libvirt's config for libvirt-managed networks, or directly on the bridge device for simple host bridges or OVS bridges managed outside of libvirt). One question I have about this - it occurred to me that in the case of migrating a guest from a host with an older libvirt to one with a newer libvirt, the guest may have *not* had the host_mtu option on the older machine, but *will* have it on the newer machine. I'm curious if this could lead to incompatibilities between source and destination (I guess it all depends on whether or not the setting of host_mtu has a practical effect on a guest that is already running - Maxime?) Likewise, we could run into problems when migrating from a newer libvirt to older libvirt - The guest would have been told of the higher MTU on the newer libvirt, then migrated to a host that didn't understand <mtu size='blah'/>. (If this really is a problem, it would be a problem with or without the current patch).
-
由 Laine Stump 提交于
virNetDevTapCreateInBridgePort() has always set the new tap device to the current MTU of the bridge it's being attached to. There is one case where we will want to set the new tap device to a different (usually larger) MTU - if that's done with the very first device added to the bridge, the bridge's MTU will be set to the device's MTU. This patch allows for that possibility by adding "int mtu" to the arg list for virNetDevTapCreateInBridgePort(), but all callers are sending -1, so it doesn't yet have any effect. Since the requested MTU isn't necessarily what is used in the end (for example, if there is no MTU requested, the tap device will be set to the current MTU of the bridge), and the hypervisor may want to know the actual MTU used, we also return the actual MTU to the caller (if actualMTU is non-NULL).
-
由 Andrea Bolognani 提交于
In order for memory locking to work, the hard limit on memory locking (and usage) has to be set appropriately by the user. The documentation mentions the requirement already: with this patch, it's going to be enforced by runtime checks as well, by forbidding a non-compliant guest from being defined as well as edited and started. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1316774
-
- 07 2月, 2017 8 次提交
-
-
由 Michal Privoznik 提交于
When working with symlinks it is fairly easy to get into a loop. Don't. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Similarly to one of the previous commits, we need to deal properly with symlinks in hotplug case too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When working with symlinks it is fairly easy to get into a loop. Don't. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Imagine you have a disk with the following source set up: /dev/disk/by-uuid/$uuid (symlink to) -> /dev/sda After cbc45525 the transitive end of the symlink chain is created (/dev/sda), but we need to create any item in chain too. Others might rely on that. In this case, /dev/disk/by-uuid/$uuid comes from domain XML thus it is this path that secdriver tries to relabel. Not the resolved one. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
After previous commit this has become redundant step. Also setting up devices in namespace and setting their label later on are two different steps and should be not done at once. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The idea is to move all the seclabel setting to security driver. Having the relabel code spread all over the place looks very messy. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Because of the nature of security driver transactions, it is impossible to use them properly. The thing is, transactions enter the domain namespace and commit all the seclabel changes. However, in RestoreAllLabel() this is impossible - the qemu process, the only process running in the namespace, is gone. And thus is the namespace. Therefore we shouldn't use the transactions as there is no namespace to enter. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The current ordering is as follows: 1) set label 2) create the device in namespace 3) allow device in the cgroup While this might work for now, it will definitely not work if the security driver would use transactions as in that case there would be no device to relabel in the domain namespace as the device is created in the second step. Swap steps 1) and 2) to allow security driver to use more transactions. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 01 2月, 2017 2 次提交
-
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 Martin Kletzander 提交于
Now that we have a function for properly assigning the blockdeviotune info, let's use it instead of dropping the group name on every assignment. Otherwise it will not work with both --live and --config options. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 31 1月, 2017 2 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Ján Tomko 提交于
Commit 815d98ac started auto-adding one hub if there are more USB devices than available USB ports. This was a strange choice, since there might be even more devices. Before USB address allocation was implemented in libvirt, QEMU automatically added a new USB hub if the old one was full. Adjust the logic to try adding as many hubs as will be needed to plug in all the specified devices. https://bugzilla.redhat.com/show_bug.cgi?id=1410188
-
- 30 1月, 2017 4 次提交
-
-
-
由 Michal Privoznik 提交于
==12618== 110 bytes in 10 blocks are definitely lost in loss record 269 of 295 ==12618== at 0x4C2AE5F: malloc (vg_replace_malloc.c:297) ==12618== by 0x1CFC6DD7: vasprintf (vasprintf.c:73) ==12618== by 0x1912B2FC: virVasprintfInternal (virstring.c:551) ==12618== by 0x1912B411: virAsprintfInternal (virstring.c:572) ==12618== by 0x50B1FF: qemuAliasChardevFromDevAlias (qemu_alias.c:638) ==12618== by 0x518CCE: qemuBuildChrChardevStr (qemu_command.c:4973) ==12618== by 0x522DA0: qemuBuildShmemBackendChrStr (qemu_command.c:8674) ==12618== by 0x523209: qemuBuildShmemCommandLine (qemu_command.c:8789) ==12618== by 0x526135: qemuBuildCommandLine (qemu_command.c:9843) ==12618== by 0x48B4BA: qemuProcessCreatePretendCmd (qemu_process.c:5897) ==12618== by 0x4378C9: testCompareXMLToArgv (qemuxml2argvtest.c:498) ==12618== by 0x44D5A6: virTestRun (testutils.c:180) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Martin Kletzander 提交于
For example when both total_bytes_sec and total_bytes_sec_max are set, but the former gets cleaned due to new call setting, let's say, read_bytes_sec, we end up with this weird message for the command: $ virsh blkdeviotune fedora vda --read-bytes-sec 3000 error: Unable to change block I/O throttle error: unsupported configuration: value 'total_bytes_sec_max' cannot be set if 'total_bytes_sec' is not set So let's make it more descriptive. This is how it looks after the change: $ virsh blkdeviotune fedora vda --read-bytes-sec 3000 error: Unable to change block I/O throttle error: unsupported configuration: cannot reset 'total_bytes_sec' when 'total_bytes_sec_max' is set Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1344897Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Well, just two. One indentation and the usage of 'ret'. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-