- 27 3月, 2017 30 次提交
-
-
由 Peter Krempa 提交于
The hyperv panic notifier reports additional data in form of 5 registers that are reported in the crash event from qemu. Log them into the VM log file and report them as a warning so that admins can see the cause of crash of their windows VMs. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1426176
-
由 Peter Krempa 提交于
For certain kinds of panic notifiers (notably hyper-v) qemu is able to report some data regarding the crash passed from the guest. Make the data accessible to the callback in qemu so that it can be processed further.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Erik Skultety 提交于
Format the mediated devices on the qemu command line as -device vfio-pci,sysfsdev='/path/to/device/in/syfs'. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
Since mdevs are just another type of VFIO devices, we should increase the memory locking limit the same way we do for VFIO PCI devices. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
As goes for all the other hostdev device types, grant the qemu process access to /dev/vfio/<mediated_device_iommu_group>. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
Keep track of the assigned mediated devices the same way we do it for the rest of hostdevs. Methods like 'Prepare', 'Update', and 'ReAttach' are introduced by this patch. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
So far, the official support is for x86_64 arch guests so unless a different device API than vfio-pci is available let's only turn on support for PCI address assignment. Once a different device API is introduced, we can enable another address type easily. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
A mediated device will be identified by a UUID (with 'model' now being a mandatory <hostdev> attribute to represent the mediated device API) of the user pre-created mediated device. We also need to make sure that if user explicitly provides a guest address for a mdev device, the address type will be matching the device API supported on that specific mediated device and error out with an incorrect XML message. The resulting device XML: <devices> <hostdev mode='subsystem' type='mdev' model='vfio-pci'> <source> <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'> </source> </hostdev> </devices> Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Martin Kletzander 提交于
This way more drivers can utilize the functionality without copying the code. And we can therefore test it in one place for all of them. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
That file has only two exported files and each one of them has different naming. virNode is what all the other files use, so let's use it. It wasn't used before because the clash with public API naming, so let's fix that by shortening the name (there is no other private variant of it anyway). Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
There is no "node driver" as there was before, drivers have to do their own ACL checking anyway, so they all specify their functions and nodeinfo is basically just extending conf/capablities. Hence moving the code to src/conf/ is the right way to go. Also that way we can de-duplicate some code that is in virsysfs and/or virhostcpu that got duplicated during the virhostcpu.c split. And Some cleanup is done throughout the changes, like adding the vir* prefix etc. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
There is no reason for it not to be in the utils, all global symbols under that file already have prefix vir* and there is no reason for it to be part of DRIVER_SOURCES because that is just a leftover from older days (pre-driver modules era, I believe). Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Both QEMU and bhyve are using the same function for setting up the CPU in virCapabilities, so de-duplicate it, save code and time, and help other drivers adopt it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Peter Krempa 提交于
Management tools may want to check whether the threshold is still set if they missed an event. Add the data to the bulk stats API where they can also query the current backing size at the same time.
-
由 Peter Krempa 提交于
To allow updating stats based on the node name, add a helper function that will fetch the required data from 'query-named-block-nodes' and return it in hash table for easy lookup.
-
由 Peter Krempa 提交于
Move the helper that frees JSON entries put into hash tables into the JSON module so that it does not have to be reimplemented.
-
由 Peter Krempa 提交于
Detect the node names when setting block threshold and when reconnecting or when they are cleared when a block job finishes. This operation will become a no-op once we fully support node names.
-
由 Peter Krempa 提交于
To allow matching the node names gathered via 'query-named-block-nodes' we need to query and then use the top level nodes from 'query-block'. Add the data to the structure returned by qemuMonitorGetBlockInfo.
-
由 Peter Krempa 提交于
qemu for some time already sets node names automatically for the block nodes. This patch adds code that attempts a best-effort detection of the node names for the backing chain from the output of 'query-named-block-nodes'. The only drawback is that the data provided by qemu needs to be matched by the filename as seen by qemu and thus if two disks share a single backing store file the detection won't work. This will allow us to use qemu commands such as 'block-set-write-threshold' which only accepts node names. In this patch only the detection code is added, it will be used later.
-
由 Peter Krempa 提交于
Add monitor tooling for calling query-named-block-nodes. The monitor returns the data as the raw JSON array that is returned from the monitor. Unfortunately the logic to extract the node names for a complete backing chain will be so complex that I won't be able to extract any meaningful subset of the data in the monitor code.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Add code to call the appropriate monitor command and code to lookup the given disk backing chain member.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Bind it to qemu's BLOCK_WRITE_THRESHOLD event. Look up the disk by nodename and construct the string to return.
-
由 Peter Krempa 提交于
The code is currently simple, but if we later add node names, it will be necessary to generate the names based on the node name. Add a helper so that there's a central point to fix once we add self-generated node names.
-
由 Peter Krempa 提交于
Looks up a disk and its corresponding backing chain element by node name.
-
由 Peter Krempa 提交于
The event is fired when a given block backend node (identified by the node name) experiences a write beyond the bound set via block-set-write-threshold QMP command. This wires up the monitor code to extract the data and allow us receiving the events and the capability.
-
由 Peter Krempa 提交于
Our code calls it when starting or re-starting the domain or when hotplugging the disk so there's nothing to be detected.
-
- 26 3月, 2017 1 次提交
-
-
由 Roman Bogorodskiy 提交于
qemuMigrationResetTLS() does not initialize 'ret' by default, so when it jumps to 'cleanup' on error, the 'ret' variable will be uninitialized, which clang complains about. Set it to '-1' by default.
-
- 25 3月, 2017 9 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1300769 If the migration flags indicate this migration will be using TLS, then while we have connection in the Begin phase check and setup the TLS environment that will be used by virMigrationRun during the Perform phase for the source to configure TLS. Processing adds an "-object tls-creds-x509,endpoint=client,..." and possibly an "-object secret,..." to handle the passphrase response. Then it sets the 'tls-creds' and possibly 'tls-hostname' migration parameters. The qemuMigrateCancel will clean up and reset the environment as it was originally found. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
If the migration flags indicate this migration will be using TLS, then set up the destination during the prepare phase once the target domain has been started to add the TLS objects to perform the migration. This will create at least an "-object tls-creds-x509,endpoint=server,..." for TLS credentials and potentially an "-object secret,..." to handle the passphrase response to access the TLS credentials. The alias/id used for the TLS objects will contain "libvirt_migrate". Once the objects are created, the code will set the "tls-creds" and "tls-hostname" migration parameters to signify usage of TLS. During the Finish phase we'll be sure to attempt to clear the migration parameters and delete those objects (whether or not they were created). We'll also perform the same reset during recovery if we've reached FINISH3. If the migration isn't using TLS, then be sure to check if the migration parameters exist and clear them if so.
-
由 John Ferlan 提交于
Add an asyncJob argument for add/delete TLS Objects. A future patch will add/delete TLS objects from a migration which may have a job to join. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Add the fields to support setting tls-creds and tls-hostname during a migration (either source or target). Modify the query migration function to check for the presence and set the field for future consumers to determine which of 3 conditions is being met (NULL, present and set to "", or present and sent to something). These correspond to qemu commit id '4af245dc3' which added support to default the value to "" and allow setting (or resetting) to "" in order to disable. This reset option allows libvirt to properly use the tls-creds and tls-hostname parameters. Modify code paths that either allocate or use stack space in order to call qemuMigrationParamsClear or qemuMigrationParamsFree for cleanup. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Update the descriptions to match the migrate option. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Add a new TLS X.509 certificate type - "migrate". This will handle the creation of a TLS certificate capability (and possibly repository) to be used for migrations. Similar to chardev's, credentials will be handled via a libvirt secrets; however, unlike chardev's enablement and usage will be via a CLI flag instead of a conf flag and a domain XML attribute. The migrations using the *x509_verify flag require the client-cert.pem and client-key.pem files to be present in the TLS directory - so let's also be sure to note that in the qemu.conf file. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Create GET_CONFIG_TLS_CERT to set up the TLS for 'chardev' TLS setting. Soon to be reused. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-