- 09 2月, 2017 8 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
virCPUDefStealModel is called with keepVendor == true which means the cpu structure will keep its original vendor/vendor_id values. Thus it makes no sense to copy them to the translated definition as they won't be used there anyway. Except that the translated->vendor pointer might get lost in x86Decode. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Maxim Nestratov 提交于
PARALLELS_STATISTICS_DROP_COUNT isn't used anymore Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
When we happen to lose a domain but still get a performance event for it, we should also free the event handle. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
Every successful call of PrlEvent_GetParamByName allocates a handle, which has to be freed. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.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>
-
由 Jim Fehlig 提交于
The typical pattern when calling libxl functions that populate a structure is libxl_foo foo; libxl_foo_init(&foo); libxl_get_foo(ctx, &foo); ... libxl_foo_dispose(&foo); Fix several instances of libxl_physinfo missing the init and dispose calls. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jim Fehlig 提交于
libxlGetAutoballoonConf is supposed to honor user-specified autoballoon setting in libxl.conf. As written, the user-specified setting could be overwritten by the subsequent logic to check dom0_mem parameter. If user-specified setting is present and correct, accept it. Only fallback to checking Xen dom0_mem command line parameter if user-specfied setting is not present. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
- 08 2月, 2017 14 次提交
-
-
由 Joao Martins 提交于
If no graphics element is in XML xenFormatXLSpice will access graphics without checking it has one in the first place, leading to a segmentation fault. Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
-
由 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 提交于
This resolves: https://bugzilla.redhat.com/1224348
-
由 Laine Stump 提交于
Example: <network> ... <mtu size='9000'/> ... If mtu is unset, it's assumed that we want the default for whatever is the underlying transport (usually this is 1500). This setting isn't yet wired in, so it will have no effect. This partially resolves: https://bugzilla.redhat.com/1224348
-
由 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 13 次提交
-
-
由 Roman Bogorodskiy 提交于
-
由 Roman Bogorodskiy 提交于
Like it usually happens, I fixed one thing and broke another: in 803966c7 address allocation was fixed for SATA disks, but broke that for virtio disks, because it dropped disk address assignment completely. It's not needed for SATA disks anymore, but still needed for the virtio ones. Bring that back and add a couple of tests to make sure it won't happen again.
-
由 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>
-
由 Michal Privoznik 提交于
We will need to traverse the symlinks one step at the time. Therefore we need to see where a symlink is pointing to. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The comment to the function states that the errors from the child process are reported. Well, the error buffer is filled with possible error messages. But then it is thrown away. Among with important error message from the child process. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
==11260== 1,006 bytes in 1 blocks are definitely lost in loss record 106 of 111 ==11260== at 0x4C2AE5F: malloc (vg_replace_malloc.c:297) ==11260== by 0x4C2BDFF: realloc (vg_replace_malloc.c:693) ==11260== by 0x4EA430B: virReallocN (viralloc.c:245) ==11260== by 0x4EA7C52: virBufferGrow (virbuffer.c:130) ==11260== by 0x4EA7D28: virBufferAdd (virbuffer.c:165) ==11260== by 0x4EA8E10: virBufferStrcat (virbuffer.c:718) ==11260== by 0x42D263: xenFormatXLDiskSrcNet (xen_xl.c:960) ==11260== by 0x42D4EB: xenFormatXLDiskSrc (xen_xl.c:1015) ==11260== by 0x42D870: xenFormatXLDisk (xen_xl.c:1101) ==11260== by 0x42DA89: xenFormatXLDomainDisks (xen_xl.c:1148) ==11260== by 0x42EAF8: xenFormatXL (xen_xl.c:1558) ==11260== by 0x40E85F: testCompareParseXML (xlconfigtest.c:105) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 04 2月, 2017 2 次提交
-
-
由 John Ferlan 提交于
Originally/discovered proposed by "Wang King <king.wang@huawei.com>" When the virCloseCallbacksSet is first called, it increments the refcnt on the domain object to ensure it doesn't get deleted before the callback is called. The refcnt would be decremented in virCloseCallbacksUnset once the entry is removed from the closeCallbacks has table. When (mostly) normal shutdown occurs, the qemuProcessStop will end up calling qemuProcessAutoDestroyRemove and will remove the callback from the list and hash table normally and decrement the refcnt. However, when qemuConnectClose calls virCloseCallbacksRun, it will scan the (locked) closeCallbacks list for matching domain and callback function. If an entry is found, it will be removed from the closeCallbacks list and placed into a lookaside list to be processed when the closeCallbacks lock is dropped. The callback function (e.g. qemuProcessAutoDestroy) is called and will run qemuProcessStop. That code will fail to find the callback in the list when qemuProcessAutoDestroyRemove is called and thus not decrement the domain refcnt. Instead since the entry isn't found the code will just return (mostly) harmlessly. This patch will resolve the issue by taking another ref during the search UUID process during virCloseCallackRun, decrementing the refcnt taken by virCloseCallbacksSet, calling the callback routine and returning overwriting the vm (since it could return NULL). Finally, it will call the virDomainObjEndAPI to lower the refcnt and remove the lock taken during the search UUID processing. This may cause the vm to be destroyed.
-
由 Daniel P. Berrange 提交于
After deploying virtlogd by default we identified a number of mistakes in the systemd unit file. virtlockd's relationship to libvirtd is the same as virtlogd, so we must apply the same unit file fixes to virtlockd Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 03 2月, 2017 3 次提交
-
-
由 Peter Krempa 提交于
-
由 Andrea Bolognani 提交于
Updating docs/news.xml in the same commit that performs the documented change makes backports needlessly complicated, both for mainteinance branches and downstream distributions, because it introduces additional potential for merge conflicts. Document in the contributor guidelines that the release notes should be updated in a separate commit instead, so that it's easy to backport just the code change.
-
由 Jim Fehlig 提交于
xen.git commit 57f8b13c changed several of the libxl memory get/set functions to take 64 bit parameters. The libvirt libxl driver still uses uint32_t variables for these various parameters, which is particularly problematic for the libxl_set_memory_target() function. When dom0 autoballooning is enabled, libvirt (like xl) determines the memory needed to start a domain and the memory available. If memory available is less than memory needed, dom0 is ballooned down by passing a negative value to libxl_set_memory_target() 'target_memkb' parameter. Prior to xen.git commit 57f8b13c, 'target_memkb' was an int32_t. Subtracting a larger uint32 from a smaller uint32 and assigning it to int32 resulted in a negative number. After commit 57f8b13c, the same subtraction is widened to a int64, resulting in a large positive number. The simple fix taken by this patch is to assign the difference of the uint32 values to a temporary int32 variable, which is then passed to 'target_memkb' parameter of libxl_set_memory_target(). Note that it is undesirable to change libvirt to use 64 bit variables since it requires setting LIBXL_API_VERSION to 0x040800. Currently libvirt supports LIBXL_API_VERSION >= 0x040400, essentially Xen >= 4.4.
-