- 29 3月, 2016 7 次提交
-
-
由 Maxim Nestratov 提交于
This patch adds support for "vpindex", "runtime", "synic", "stimer", and "vendor_id" features available in qemu 2.5+. - When Hyper-V "vpindex" is on, guest can use MSR HV_X64_MSR_VP_INDEX to get virtual processor ID. - Hyper-V "runtime" enlightement feature allows to use MSR HV_X64_MSR_VP_RUNTIME to get the time the virtual processor consumes running guest code, as well as the time the hypervisor spends running code on behalf of that guest. - Hyper-V "synic" stands for Synthetic Interrupt Controller, which is lapic extension controlled via MSRs. - Hyper-V "stimer" switches on Hyper-V SynIC timers MSR's support. Guest can setup and use fired by host events (SynIC interrupt and appropriate timer expiration message) as guest clock events - Hyper-V "reset" allows guest to reset VM. - Hyper-V "vendor_id" exposes hypervisor vendor id to guest. Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
1. All hyperv features are tristate ones. So make tristate generating part common. 2. Reduce nesting on spinlocks. Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
1. All hyperv features are tristate ones. So make tristate parsing code common. 2. Reindent switch statement. 3. Reduce nesting in spinlocks parsing. Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Laine Stump 提交于
After the patches that added tracking of in-use macvtap names (commit 370608, first appearing in libvirt-1.3.2), if the function to allocate a new macvtap device came to a device name created outside libvirt, it would retry the same device name MACVLAN_MAX_ID (8191) times before finally giving up in failure. The problem was that virBitmapNextClearBit was always being called with "0" rather than the value most recently checked (which would increment each time through the loop), so it would always return the same id (since we dutifully release that id after failing to create a new device using it). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1321546Signed-off-by: NLaine Stump <laine@laine.org>
-
由 Chunyan Liu 提交于
For those VF allocated from a network pool, we need to set its backend to be VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN so that later work can be correct. Signed-off-by: NChunyan Liu <cyliu@suse.com>
-
由 Anatole Denis 提交于
This test was commited 4 years ago, but was never enabled in storagepoolxml2xmltest.c. This patch reactivates it, conditionnaly on RBD storage support being enabled
-
由 Anatole Denis 提交于
This test failed for two reasons: * The uuid was missing from the input file * The output file had the <name> in a different place from the actual output
-
- 27 3月, 2016 2 次提交
-
-
由 Roman Bogorodskiy 提交于
This reverts commit bb5f2dc9. The "if (vol->target.format != VIR_STORAGE_FILE_RAW)" check in the createVol backend. This check is bogus because virStorageVolDefParseXML() in conf/storage_conf.c sets target.format only if volOptions in virStoragePoolTypeInfo has formatFromString set, and that's not the case the zfs backend. So the check always fails and breaks volume creation.
-
由 Roman Bogorodskiy 提交于
This reverts commit 6682d621. The "if (vol->target.format != VIR_STORAGE_FILE_RAW)" check in the createVol backend. This check is bogus because virStorageVolDefParseXML() in conf/storage_conf.c sets target.format only if volOptions in virStoragePoolTypeInfo has formatFromString set, and that's not the case the logical backend. So the check always fails and breaks volume creation.
-
- 26 3月, 2016 5 次提交
-
-
由 Chunyan Liu 提交于
When hostdev parent is network device, should call libxlDomainDetachNetDevice to detach the device from a higher level. Signed-off-by: NChunyan Liu <cyliu@suse.com>
-
由 Chunyan Liu 提交于
Adjust codes to make it cleaner. Signed-off-by: NChunyan Liu <cyliu@suse.com>
-
由 Chunyan Liu 提交于
When AttachNetDevice failed, should call networkReleaseActualDevice to release actual device, and if actual device is hostdev, should remove the hostdev from vm->def->hostdevs. Signed-off-by: NChunyan Liu <cyliu@suse.com>
-
由 Laine Stump 提交于
networkStartNetwork() and networkShutdownNetwork() were calling the wrong type-specific function in the case of networks that were configured for macvtap ("direct") bridge mode - they were instead calling the functions for a tap+bridge network. Currently none of these functions does anything (they just return 0) so it hasn't created any problems, but that could change in the future.
-
由 Laine Stump 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1316465 An attempt to simplify the code for the VIR_NETWORK_FORWARD_BRIDGE case of networkUpdateState in commit b61db335 (first in release 1.2.14) resulted in networks based on macvtap bridge mode being erroneously marked as inactive any time libvirtd was restarted. The problem is that the original code had differentiated between a network using tap devices to connect to an existing host-bridge device (forward mode of VIR_NETWORK_FORWARD_BRIDGE and a non-NULL def->bridge), and one using macvtap bridge mode to connect to any ethernet device (still forward mode VIR_NETWORK_FORWARD_BRIDGE, but null def->bridge), but the changed code assumed that all networks with VIR_NETWORK_FORWARD_BRIDGE were tap + host-bridge networks, so a null def->bridge was interpreted as "inactive". This patch restores the original code in networkUpdateState
-
- 25 3月, 2016 8 次提交
-
-
由 Christophe Fergeau 提交于
This changes __VIT_TEST_UTILS_H__ to __VIR_TEST_UTILS_H__
-
由 Christophe Fergeau 提交于
%zu is for size_t variables, not uint64 ones. This causes a warning when building on a 32 bit linux.
-
由 Michal Privoznik 提交于
If the abs_builddir path already is in PATH and it's in the first position, due to a bug in our code PATH would be cleared out. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
In 68b726b9 we tried to fix a mem leak. However, it wasn't done quite well. Problem is, virNetDaemonGetServers() may fail in which case virObjectListFreeCount() would be called with -1 objects to free. But the number of elements is taken in unsigned rather than signed integer. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jovanka Gulicoska 提交于
qemuStateInitialize uses a mix of VIR_ERROR and standard vir*Error calls. Prefer the standard vir*Error
-
由 Jovanka Gulicoska 提交于
These uses of virGetLastError message are just duplicating virGetLastErrorMessage.
-
由 Michal Privoznik 提交于
Coverity pointed out that getenv("PATH") may return NULL. Well, we check for that in virFindFileInPath() too. If this happens, we will pass NULL into strstr(). Ouch. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The variable is dereferenced prior its check for NULL. The check itself does not make much sense anyway - it's our test, we know we are not passing NULL. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 24 3月, 2016 9 次提交
-
-
由 Erik Skultety 提交于
Patch 0b231195 refactored logging output parser to make it more readable. This patch does similar thing to logging filter parser.
-
由 Erik Skultety 提交于
-
由 Erik Skultety 提交于
The test can return positive value even though it should have failed. It just returns the value parser returned, which should be flipped back to -1 if something went wrong or the result was unexpected, but it isn't.
-
由 Pavel Hrdina 提交于
If caller of adminConnectListServers() pass NULL instead of servers we need to free the list we've received from virNetDaemonGetServers(). Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Michal Privoznik 提交于
The adminDispatchConnectListServers() function is generated by our great perl script. However, it has a tiny flaw: if adminConnectListServers() it calls fails, the control jumps onto cleanup label where we try to free any list of servers built so far. However, in the loop @i is unsigned (size_t) while @nresults is signed (int). Currently, it does no harm because of the check for @result being non-NULL. But if that ever changes in the future, this bug will be hard to chase. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
In an unlikely event of virConnectRegisterCloseCallback failing, the error is ignored. This is an example file and we shouldn't get a bad example. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Like in the rest of our code we tend to prefer 'goto' and 'cleanup' over 'if else' code structure. Do the same here. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
After 9c17d665 the tap device for ethernet network type is automatically precreated before spawning qemu. Problem is, the qemuxml2argvtest wasn't updated and thus is failing. Because of all the APIs that new code is calling, I had to mock a lot. Also, since the tap FDs are labeled separately from the rest of the devices/files I had to enable NOP security driver for the test too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Cole Robinson 提交于
We were printing the wrong MAX value
-
- 23 3月, 2016 8 次提交
-
-
由 Michal Privoznik 提交于
When constructing SCSI hostdev command line for qemu, the /sys/bus/scsi/devices/... dir is scanned. Unfortunately, even in the tests. This is needed to determine the name of SCSI device to passthrough to qemu, because in the domain XML we were given its address instead. Anyway, we should not be touching live system data in our test suite as it produced unpredictable results. The test is regressing from 1e9a0837 on. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Vasiliy Tolstov 提交于
If a user specify network type ethernet, then create it via libvirt and run script if it provided. After this commit user does not need to run external script to create tap device or add root permissions to qemu process. Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>
-
由 Andrea Bolognani 提交于
Ensure the code behaves properly even for situations that were not being considered before, such as simply detaching devices from the host without attaching them to a guest and attaching devices as managed even though they had already been manually detached from the host.
-
由 Andrea Bolognani 提交于
Instead of forcing the values for the unbind_from_stub, remove_slot and reprobe properties, look up the actual device and use that when calling virPCIDeviceReattach(). This ensures the device is restored to its original state after reattach: for example, if it was not bound to any driver before detach, it will not be bound forcefully during reattach.
-
由 Andrea Bolognani 提交于
We would be just fine looking up the information in pcidevs most of the time; however, some corner cases would not be handled properly, so look up the actual device instead.
-
由 Andrea Bolognani 提交于
After this patch, ownership of virPCIDevice instances is very easy to keep track of: for each host PCI device, the only instance that actually matters is the one inside one of the bookkeeping list. Whenever some operation needs to be performed on a PCI device, the actual device is looked up first; when this is not the case, a comment explains the reason.
-
由 Andrea Bolognani 提交于
Unmanaged devices, as the name suggests, are not detached automatically from the host by libvirt before being attached to a guest: it's the user's responsability to detach them manually beforehand. If that preliminary step has not been performed, the attach operation can't complete successfully. Instead of relying on the lower layers to error out with cryptic messages such as error: Failed to attach device from /tmp/hostdev.xml error: Path '/dev/vfio/12' is not accessible: No such file or directory prevent the situation altogether and provide the user with a more useful error message.
-
由 Andrea Bolognani 提交于
Unmanaged devices are attached to guests in two steps: first, the device is detached from the host and marked as inactive; subsequently, it is marked as active and attached to the guest. If the daemon is restarted between these two operations, we lose track of the inactive device. Steps 5 and 6 of virHostdevPreparePCIDevices() already subtly take care of this situation, but some planned changes will make it so that's no longer the case. Plus, explicit is always better than implicit.
-
- 22 3月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
Use qemuProcessCreatePretendCmd instead duplicating required steps from qemuProcessStart. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-