- 15 3月, 2017 5 次提交
-
-
由 Michal Privoznik 提交于
Frankly, this function is one big mess. A lot of arguments, complicated behaviour. It's really surprising that arguments were in random order (input and output arguments were mixed together), the documentation was outdated, the description of return values was bogus. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Even though this variable contains just values from an enum where zero has the usual meaning, it's enum after all and we should check it as such. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This is an input argument. We should not overwrite it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Roman Bogorodskiy 提交于
Introduce config file support for the bhyve driver. The only available setting at present is 'firmware_dir' for specifying a directory with UEFI firmware files.
-
- 14 3月, 2017 9 次提交
-
-
由 Alexander Vasilenko 提交于
The description should be in the target for a volume not a pool.
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The function is now called virQEMUCapsProbeHostCPU. Both the refactoring and the change of the name is done for consistency with a new function which will be introduced in the following commit. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
When creating host CPU definition usable with a given emulator, the CPU should not be defined using an unsupported CPU model. The new @models and @nmodels parameters can be used to limit CPU models which can be used in the result. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The parameter can be used to request either VIR_CPU_TYPE_HOST (which has been assumed so far) or VIR_CPU_TYPE_GUEST definition. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
cpuNodeData has always been followed by cpuDecode as no hypervisor driver is really interested in raw CPUID data for a host CPU. Let's create a new CPU driver API which returns virCPUDefPtr directly. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This element is only allowed for host CPUs. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Roman Bogorodskiy 提交于
Add an entry about virt-host-validate bhyve support and update the driver's page.
-
- 13 3月, 2017 2 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1431112 Yeah, that's right. A mount point doesn't have to be a directory. It can be a file too. However, the code that tries to preserve mount points under /dev for new namespace for qemu does not count with that option. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jiri Denemark 提交于
VIR_CONNECT_LIST_STORAGE_POOLS_VSTORAGE and VIR_CONNECT_LIST_STORAGE_POOLS_ZFS were added to libvirt but the listing API was not properly updated to use them. https://bugzilla.redhat.com/show_bug.cgi?id=1431543Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 12 3月, 2017 7 次提交
-
-
由 Roman Bogorodskiy 提交于
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
-
由 Fabian Freyer 提交于
bhyve supports 'gop' video device that allows clients to connect to VMs using VNC clients. This commit adds support for that to the bhyve driver: - Introducr 'gop' video device type - Add capabilities probing for the 'fbuf' device that's responsible for graphics - Update command builder routines to let users configure domain's VNC via gop graphics. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
-
由 Fabian Freyer 提交于
Extend domain capabilities XML with the information about available UEFI firmware files. It searches in the location that the sysutils/bhyve-firmware FreeBSD port installs files to. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
-
由 Fabian Freyer 提交于
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
-
由 Fabian Freyer 提交于
Allow to boot using UEFI rather than using an external boot loader such as bhyveload or grub-bhyve. Also, make LPC PCI-ISA bridge handling more flexible as now it's needed not only for serial ports, but for bootrom as well. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
-
由 Fabian Freyer 提交于
Implement the BHACE_CAP_LPC_BOOTROM capability by checking the stderr output of 'bhyve -l bootrom'. If the bootrom option is unsupported, this will contain the following output: bhyve: invalid lpc device configuration 'bootrom' On newer bhyve versions that do support specifying a bootrom image, the standard help will be printed.
-
由 Roman Bogorodskiy 提交于
Add bhyve support to virt-host-validate(1). It checks for the essential kernel modules to be available so that user can actually start VMs, have networking and console access. It uses the kldnext(2)/kldstat(2) routines to retrieve modules list. As bhyve is only available on FreeBSD and these routines were available long before bhyve appeared, not adding any specific configure checks for that. Also, update tools/Makefile.am to add virt-host-validate-$driver.[hc] to the build only if the appropriate driver is enabled.
-
- 11 3月, 2017 1 次提交
-
-
由 John Ferlan 提交于
Add a new test to fchosttest in order to test creation of our vHBA via the Storage Pool logic. Unlike the real code, we cannot yet use the virVHBA* API's because they (currently) traverse the file system in order to get the parent vport capable scsi_host. Besides there's no "real" NPIV device here - so we have to take some liberties, at least for now. Instead, we'll follow the node device tests partially in order to create and destroy the vHBA with the test node devices. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 10 3月, 2017 6 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1430634 If a qemu process has died, we get EOF on its monitor. At this point, since qemu process was the only one running in the namespace kernel has already cleaned the namespace up. Any attempt of ours to enter it has to fail. This really happened in the bug linked above. We've tried to attach a disk to qemu and while we were in the monitor talking to qemu it just died. Therefore our code tried to do some roll back (e.g. deny the device in cgroups again, restore labels, etc.). However, during the roll back (esp. when restoring labels) we still thought that domain has a namespace. So we used secdriver's transactions. This failed as there is no namespace to enter. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrange 提交于
This documents the preferred conventions for naming files, structs, enums, typedefs and functions. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Michal Privoznik 提交于
This is a very historic artefact. Back in the old days of 830ba76c when we had macros to add arguments onto qemu command line (!) we thought it was a good idea to let qemu write out the PID file. So we passed -pidfile $stateDir/$domName onto the command line. Thus, in order for tests to work we needed stable stateDir in the qemu driver. Unfortunately, after 16efa11a where stateDir is mkdtemp()-d, this approach lead to a leak of temp dir. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
If the delivery of the DEVICE_DELETED event for the vCPU being deleted would time out, the code would not call 'qemuDomainResetDeviceRemoval'. Since the waiting thread did not unregister itself prior to stopping the waiting the monitor code would try to wake it up instead of dispatching it to the event worker. As a result the unplug process would not be completed and the definition would not be updated. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1428893 https://bugzilla.redhat.com/show_bug.cgi?id=1427801
-
由 Peter Krempa 提交于
Note that the waiting thread is signaled in the debug logs to simplify debugging.
-
由 Pavel Hrdina 提交于
This reverts commit c96bd78e. So our code is one big mess and we modify domain definition while building qemu_command line and our hotplug code share only part of the parsing and command line building code. Let's revert that change because to fix it properly would require refactor and move a lot of things. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1430275
-
- 09 3月, 2017 10 次提交
-
-
由 Roman Bogorodskiy 提交于
Even though scsi storage driver builds fine on non-Linux, it will not work properly because it relies on Linux procfs, so disable that in configure if we're not building for Linux.
-
由 Pavel Hrdina 提交于
We should skip <listen type='socket'/> only if the 'socket' path is specified because if there is no 'socket' path we need to keep that element in migratable XML. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1366088Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
When libvirtd is started we call qemuDomainRecheckInternalPaths to detect whether a domain has VNC socket path generated by libvirt based on option from qemu.conf. However if we are parsing status XML for running domain the existing socket path can be generated also if the config XML uses the new <listen type='socket'/> element without specifying any socket. The current code doesn't make difference how the socket was generated and always marks it as "fromConfig". We need to store the "autoGenerated" value in the status XML in order to preserve that information. The difference between "fromConfig" and "autoGenerated" is important for migration, because if the socket is based on "fromConfig" we don't print it into the migratable XML and we assume that user has properly configured qemu.conf on both hosts. However if the socket is based on "autoGenerated" it means that a new feature was used and therefore we need to leave the socket in migratable XML to make sure that if this feature is not supported on destination the migration will fail. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 John Ferlan 提交于
Rename 'secretUsageType' to 'usageType' since it's superfluous in an API qemu*Secret*
-
由 John Ferlan 提交于
Split apart and rename qemuDomainGetChardevTLSObjects in order to make a more generic API that can create the TLS JSON prop objects (secret and tls-creds-x509) to be used to create the objects Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Move the call to inside the qemuDomainAddChardevTLSObjects in order to further converge the code. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Move the call to inside the qemuDomainAddChardevTLSObjects in order to further converge the code. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Create a qemuDomainAddChardevTLSObjects which will encapsulate the qemuDomainGetChardevTLSObjects and qemuDomainAddTLSObjects so that the callers don't need to worry about the props. Move the dev->type and haveTLS checks in to the Add function to avoid an unnecessary call to qemuDomainAddTLSObjects Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Refactor the TLS object adding code to make two separate API's that will handle the add/remove of the "secret" and "tls-creds-x509" objects including the Enter/Exit monitor commands. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Since qemuDomainObjExitMonitor can also generate error messages, let's move it inside any error message saving code on error paths for various hotplug add activities. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-