- 20 9月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
Put it into qemuDomainPrepareShmemChardev() so it can be used later. Also don't fill in the path unless the server option is enabled. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 12 9月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
When migration fails, we need to poke QEMU monitor to check for a reason of the failure. We did this using query-migrate QMP command, which is not supposed to return any meaningful result on the destination side. Thus if the monitor was still functional when we detected the migration failure, parsing the answer from query-migrate always failed with the following error message: "info migration reply was missing return status" This irrelevant message was then used as the reason for the migration failure replacing any message we might have had. Let's use harmless query-status for poking the monitor to make sure we only get an error if the monitor connection is broken. https://bugzilla.redhat.com/show_bug.cgi?id=1374613Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 25 8月, 2016 4 次提交
-
-
由 Peter Krempa 提交于
The vcpu order information is extracted only for hotpluggable entities, while vcpu definitions belonging to the same hotpluggable entity need to all share the order information. We also can't overwrite it right away in the vcpu info detection code as the order is necessary to add the hotpluggable vcpus enabled on boot in the correct order. The helper will store the order information in places where we are certain that it's necessary.
-
由 Peter Krempa 提交于
Introduce a new migration cookie flag that will be used for any configurations that are not compatible with libvirt that would not support the specific vcpu hotplug approach. This will make sure that old libvirt does not fail to reproduce the configuration correctly.
-
由 Peter Krempa 提交于
Similarly to devices the guest may allow unplug of the VCPU if libvirt is down. To avoid problems, refresh the vcpu state on reconnect. Don't mess with the vcpu state otherwise.
-
由 Peter Krempa 提交于
Now that the monitor code gathers all the data we can extract it to relevant places either in the definition or the private data of a vcpu. As only thread id is broken for TCG guests we may extract the rest of the data and just skip assigning of the thread id. In case where qemu would allow cpu hotplug in TCG mode this will make it work eventually.
-
- 04 8月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
Validate the presence of the thread id according to state of the vCPU rather than just checking the vCPU count. Additionally put the new validation code into a separate function so that the information retrieval can be split from the validation.
-
由 Peter Krempa 提交于
The function will eventually do more useful stuff than just detection of thread ids.
-
- 02 8月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
Until now we simply errored out when the translation from pool+volume failed. However, we should instead check whether that disk is needed or not since there is an option for that. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1168453Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 26 7月, 2016 2 次提交
-
-
由 Tomasz Flendrich 提交于
Dropping the caching of ccw address set. The cached set is not required anymore, because the set is now being recalculated from the domain definition on demand, so the cache can be deleted.
-
由 Tomasz Flendrich 提交于
Dropping the caching of virtio serial address set. The cached set is not required anymore, because the set is now being recalculated from the domain definition on demand, so the cache can be deleted. Credit goes to Cole Robinson.
-
- 21 7月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Check if they fit on the USB controllers the domain has, and error out if two devices try to use the same address.
-
- 11 7月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
Rather than storing them in an external array store them directly.
-
由 Peter Krempa 提交于
Members will be added in follow-up patches.
-
- 02 7月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Introduce a helper to help determine if a disk src could be possibly used for a disk secret... Going to need this for hot unplug. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 24 6月, 2016 2 次提交
-
-
由 Andrea Bolognani 提交于
This new function checks for both the architecture and the machine type, so we can use it instead of writing the same checks over and over again.
-
由 John Ferlan 提交于
Add 'encinfo' to the extended disk structure. This will contain the encryption secret (if present). Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 09 6月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
Put it into separate function called qemuDomainPrepareChannel() and call it from the new qemuProcessPrepareDomain(). Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 08 6月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
Along with the virtlogd addition of the log file appending API implement a helper for logging one-shot entries to the log file including the fallback approach of using direct file access. This will be used for noting the shutdown of the qemu proces and possibly other actions such as VM migration and other critical VM lifecycle events.
-
- 25 5月, 2016 4 次提交
-
-
由 John Ferlan 提交于
Based on some digital archaeology performed by jtomko, it's been determined that the persistentAddrs variable is no longer necessary... The variable was added by: commit 141dea6b CommitDate: 2010-02-12 17:25:52 +0000 Add persistence of PCI addresses to QEMU Where it was set to 0 on domain startup if qemu did not support the QEMUD_CMD_FLAG_DEVICE capability, to clear the addresses at shutdown, because QEMU might make up different ones next time. As of commit f5dd58a6 CommitDate: 2012-07-11 11:19:05 +0200 qemu: Extended qemuDomainAssignAddresses to be callable from everywhere. this was broken, when the persistentAddrs = 0 assignment was moved inside qemuDomainAssignPCIAddresses and while it pretends to check for !QEMU_CAPS_DEVICE, its parent qemuDomainAssignAddresses is only called if QEMU_CAPS_DEVICE is present.
-
由 Peter Krempa 提交于
Extract information for all disks and update tray state and source only for removable drives. Additionally store whether a drive is removable and whether it has a tray.
-
由 Peter Krempa 提交于
Extract whether a given drive has a tray and whether there is no image inserted. Negative logic for the image insertion is chosen so that the flag is set only if we are certain of the fact.
-
由 Peter Krempa 提交于
-
- 23 5月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Remove more checks that are no longer necessary.
-
- 16 5月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Rather than returning a "char *" indicating perhaps some sized set of characters that is NUL terminated, alter the function to return 0 or -1 for success/failure and add two parameters to handle returning the buffer and it's size. The function no longer encodes the returned secret, rather it returns the unencoded secret forcing callers to make the necessary adjustments. Alter the callers to handle the adjusted model. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 12 5月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
The initialization vector is a technical term by itself different from the key.
-
由 John Ferlan 提交于
The preferred name will be AES not IV, change current references Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 09 5月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
Extract the relevant parts of the existing checker and reuse them for blockcopy since copying to a non-block device creates an invalid configuration. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1209802
-
- 06 5月, 2016 3 次提交
-
-
由 John Ferlan 提交于
Add the data structure and infrastructure to support an initialization vector (IV) secrets. The IV secret generation will need to have access to the domain private master key, so let's make sure the prepare disk and hostdev functions can accept that now. Anywhere that needs to make a decision over which secret type to use in order to fill in or use the IV secret has a switch added. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
A recent review of related changes noted that we should split the creation (or generation) of the master key into the qemuProcessPrepareDomain and leave the writing of the master key for qemuProcessPrepareHost. Made the adjustment and modified some comments to functions that have changed calling parameters, but didn't change the intro doc. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
From a review after push, add the "_TYPE" into the name. Also use qemuDomainSecretInfoType in the struct rather than int with the comment field containing the struct name Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 03 5月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Use it everywhere except for virQEMUCapsFillDomainFeatureGICCaps.
-
- 02 5月, 2016 4 次提交
-
-
由 John Ferlan 提交于
Similar to the qemuDomainSecretDiskPrepare, generate the secret for the Hostdev's prior to call qemuProcessLaunch which calls qemuBuildCommandLine. Additionally, since the secret is not longer added as part of building the command, the hotplug code will need to make the call to add the secret in the hostdevPriv. Since this then is the last requirement to pass a virConnectPtr to qemuBuildCommandLine, we now can remove that as part of these changes. That removal has cascading effects through various callers. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Modeled after the qemuDomainDiskPrivatePtr logic, create a privateData pointer in the _virDomainHostdevDef to allow storage of private data for a hypervisor in order to at least temporarily store auth/secrets data for usage during qemuBuildCommandLine. NB: Since the qemu_parse_command (qemuParseCommandLine) code is not expecting to restore the auth/secret data, there's no need to add code to handle this new structure there. Updated copyrights for modules touched. Some didn't have updates in a couple years even though changes have been made. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than needing to pass the conn parameter to various command line building API's, add qemuDomainSecretPrepare just prior to the qemuProcessLaunch which calls qemuBuilCommandLine. The function must be called after qemuProcessPrepareHost since it's expected to eventually need the domain masterKey generated during the prepare host call. Additionally, future patches may require device aliases (assigned during the prepare domain call) in order to associate the secret objects. The qemuDomainSecretDestroy is called after the qemuProcessLaunch finishes in order to clear and free memory used by the secrets that were recently prepared, so they are not kept around in memory too long. Placing the setup here is beneficial for future patches which will need the domain masterKey in order to generate an encrypted secret along with an initialization vector to be saved and passed (since the masterKey shouldn't be passed around). Finally, since the secret is not added during command line build, the hotplug code will need to get the secret into the private disk data. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Introduce a new private structure to hold qemu domain auth/secret data. This will be stored in the qemuDomainDiskPrivate as a means to store the auth and fetched secret data rather than generating during building of the command line. The initial changes will handle the current username and secret values for rbd and iscsi disks (in their various forms). The rbd secret is stored as a base64 encoded value, while the iscsi secret is stored as a plain text value. Future changes will store encoded/encrypted secret data as well as an initialization vector needed to be given to qemu in order to decrypt the encoded password along with the domain masterKey. The inital assumption will be that VIR_DOMAIN_SECRET_INFO_PLAIN is being used. Although it's expected that the cleanup of the secret data will be done immediately after command line generation, reintroduce the object dispose function qemuDomainDiskPrivateDispose to handle removing memory associated with the structure for "normal" cleanup paths. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 16 4月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
When creating the master key, we used mode 0600 (which we should) but because we were creating it as root, the file is not readable by any qemu running as non-root. Fortunately, it's just a matter of labelling the file. We are generating the file path few times already, so let's label it in the same function that has access to the path already. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 13 4月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
Similarly to the DEVICE_DELETED event we will be able to tell when unplug of certain device types will be rejected by the guest OS. Wire up the device deletion signalling code to allow handling this.
-
由 Peter Krempa 提交于
No need to keep two separate conditions. A slight juggling of return values is needed to accomodate virDomainObjWaitUntil.
-
- 07 4月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Add a masterKey and masterKeyLen to _qemuDomainObjPrivate to store a random domain master key and its length in order to support the ability to encrypt/decrypt sensitive data shared between libvirt and qemu. The key will be base64 encoded and written to a file to be used by the command line building code to share with qemu. New API's from this patch: qemuDomainGetMasterKeyFilePath: Return a path to where the key is located qemuDomainWriteMasterKeyFile: (private) Open (create/trunc) the masterKey path and write the masterKey qemuDomainMasterKeyReadFile: Using the master key path, open/read the file, and store the masterKey and masterKeyLen. Expected use only from qemuProcessReconnect qemuDomainGenerateRandomKey: (private) Generate a random key using available algorithms The key is generated either from the gnutls_rnd function if it exists or a less cryptographically strong mechanism using virGenerateRandomBytes qemuDomainMasterKeyRemove: Remove traces of the master key, remove the *KeyFilePath qemuDomainMasterKeyCreate: Generate the domain master key and save the key in the location returned by qemuDomainGetMasterKeyFilePath. This API will first ensure the QEMU_CAPS_OBJECT_SECRET is set in the capabilities. If not, then there's no need to generate the secret or file. The creation of the key will be attempted from qemuProcessPrepareHost once the libDir directory structure exists. The removal of the key will handled from qemuProcessStop just prior to deleting the libDir tree. Since the key will not be written out to the domain object XML file, the qemuProcessReconnect will read the saved file and restore the masterKey and masterKeyLen.
-