- 21 7月, 2016 11 次提交
-
-
由 Ján Tomko 提交于
Automatically assign addresses to USB devices. Just like reserving, this is only done for newly defined domains. https://bugzilla.redhat.com/show_bug.cgi?id=1215968
-
由 Ján Tomko 提交于
Introduce tests with the ich9, xhci and the default (piix3) usb controller to demonstrate the effect of the next patch.
-
由 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.
-
由 Ján Tomko 提交于
Walk through all the usb hubs in the domain definition that have a USB address specified, create the corresponding structures in the virDomainUSBAddressSet and mark the port it occupies as used.
-
由 Ján Tomko 提交于
Walk through all the usb controllers in the domain definition and create the corresponding structures in the virDomainUSBAddressSet.
-
由 Ján Tomko 提交于
A new type to track USB addresses. Every <controller type='usb' index='i'/> is represented by an object of type virDomainUSBAddressHub located at buses[i]. Each of these hubs has up to 'nports' ports. If a port is occupied, it has the corresponding bit set in the 'ports' bitmap, e.g. port 1 would have the 0th bit set. If there is a hub on this port, then hubs[i] will point to this hub.
-
由 Nikolay Shirokovskiy 提交于
Undefine procedure drops domain lock while waiting for detaching disks vz sdk call. Meanwhile vz sdk event domain-config-changed arrives, its handler finds domain and is blocked waiting for job condition. After undefine API call finishes event processing procedes and tries to refreshes domain config thru existing vz sdk domain handle. Domain does not exists anymore and event processing fails. Everything is fine we just don't want to see error message in log for this particular case. Fortunately domain has flag that domain is removed from list. This also imply that vz sdk domain is also undefined. Thus if we check for this flag right after domain is locked again on accuiring job condition we gracefully handle this situation. Actually the race can happen in other situations too. Any time we wait for job condition in mutualy exclusive job in time when we acquire it vz sdk domain can cease to exist. So instead of general internal error we can return domain not found which is easier to handle. We don't need to patch other places in mutually exclusive jobs where domain lock is dropped as if job is started domain can't be undefine by mutually exclusive undefine job. The code of this patch is quite similar to qemu driver checks for is domain is active after acquiring a job. The difference only while qemu domain is operational while process is active vz domain is operational while domain exists.
-
由 Nikolay Shirokovskiy 提交于
Current vz driver implementation is not usable when it comes to long runnig operations. Migration or saving a domain blocks all other operations even query ones which are expecteted to be available. This patch addresses this problem. All vz driver API calls fall into next 3 groups: 1. only query domain cache (virDomainObj, vz cache statistic) examples are vzDomainGetState, vzDomainGetXMLDesc etc. 2. use thread shared sdkdom object examples are vzDomainSetMemoryFlags, vzDomainAttachDevice etc. 3. use no thread shared sdkdom object nor domain cache examples are vzDomainSnapshotListNames, vzDomainSnapshotGetXMLDesc etc API calls from group 1 don't need to be changed as they hold domain lock only for short period of time. These calls [1] are easily distinguished. They query domain object thru libvirt common code or query vz sdk statistics handle thru vz sdk sync operations. vzDomainInterfaceStats is the only exception. It uses sdkdom object to convert interface name to its vz sdk stack index which could not be saved in domain cache. Interface statistics is available thru this stack index as a key rather than name. As a result we can have accidental 'not known interface' errors on quering intrerface stats. The reason is that in the process of updating domain configuration we drop all devices and then recreate them again in sdkdom object and domain lock can be dropped meanwhile (to remove networks for existing bridged interfaces and(or) (re)create new ones). We can fix this by changing the way we support bridged interfaces or by reordering operations and changing bridged networks beforehand. Anyway this is better than moving this API call into 2 group and making it an exclusive job. As to API calls from group 2, first thread shared sdkdom object needs to be explained. vz sdk has only one handle for a given domain, thus threads need exclusive access to operate on it. These calls are fixed to drop and reacquire domain lock on any lengthy operations - namely waiting the result of async vz sdk operation. As lock is dropped we need to take extra reference to domain object if it is not taken already as domain object can be deleted from list while lock is dropped. As this operations use thread shared sdkdom object, the simplest way to make calls from group 2 be consistent to each other is to make them mutually exclusive. This is done by taking/releasing job condition thru calling correspondent job routine. This approach makes group 1 and group 2 calls consistent to each other too. Not all calls of group 2 change the domain cache but those that do update it thru prlsdkUpdateDomain which holds the lock thoughout the update. API calls from group [2] are easily distinguished too. They use beginEdit/commit to change domain configuration (vzDomainSetMemoryFlags) or/and update domain cache from sdkdom at the end of operation (vzDomainSuspend). There is a known issue however. Frankly speaking it was introduced by ealier patch '[PATCH 6/9] vz: cleanup loading domain code' from a different series. The patch significantly reduced amount of time when the driver lock is held when creating domain from API call or as a result of domain added event from vz sdk. The problem is these two paths race on using thread shared sdkdom as we don't have libvirt domain object and can not lock on it. However this don't invalidates the patch as we can't use the former approach of preadding domain into the list as we need name at least and name is not given by event. Anyway i'm against adding half baked object into the list. Eventually this race can be fixed by extra measures. As to current situation races with different configurations are unlikely and race when adding domain thru vz driver and simultaneous event from vz sdk is not dangerous as configuration is the same. The last group [3] is API calls that need only sdkdom object to make vz sdk call and don't change thread shared sdkdom object or domain cache in any way. For now these are mostly domain snapshot API calls. The changes are similar to those of group 2 - they add extra reference and drop/reacquire the lock on waiting vz async call result. One can simply take the immutable sdkdom object from the cache and drop the lock for the rest of operations but the chosen approach makes implementation of these API calls somewhat similar to those of from group 2 and thus a bit futureproof. As calls of group 3 don't need vz driver domain/vz sdk cache in any way, they are consistent with respect to API calls from groups 1 and 3. There is another exception. Calls to make-snapshot/revert-to-snapshot/migrate are moved to group 2. That is they are made mutually exclusive. The reason is that libvirt API supports control/query only for one job per domain and these are jobs that are likely to be queried/aborted. Appendix. [1] API calls that only query domain cache. (marked [*] are included for a different reason) .domainLookupByID = vzDomainLookupByID, /* 0.10.0 */ .domainLookupByUUID = vzDomainLookupByUUID, /* 0.10.0 */ .domainLookupByName = vzDomainLookupByName, /* 0.10.0 */ .domainGetOSType = vzDomainGetOSType, /* 0.10.0 */ .domainGetInfo = vzDomainGetInfo, /* 0.10.0 */ .domainGetState = vzDomainGetState, /* 0.10.0 */ .domainGetXMLDesc = vzDomainGetXMLDesc, /* 0.10.0 */ .domainIsPersistent = vzDomainIsPersistent, /* 0.10.0 */ .domainGetAutostart = vzDomainGetAutostart, /* 0.10.0 */ .domainGetVcpus = vzDomainGetVcpus, /* 1.2.6 */ .domainIsActive = vzDomainIsActive, /* 1.2.10 */ .domainIsUpdated = vzDomainIsUpdated, /* 1.2.21 */ .domainGetVcpusFlags = vzDomainGetVcpusFlags, /* 1.2.21 */ .domainGetMaxVcpus = vzDomainGetMaxVcpus, /* 1.2.21 */ .domainHasManagedSaveImage = vzDomainHasManagedSaveImage, /* 1.2.13 */ .domainGetMaxMemory = vzDomainGetMaxMemory, /* 1.2.15 */ .domainBlockStats = vzDomainBlockStats, /* 1.2.17 */ .domainBlockStatsFlags = vzDomainBlockStatsFlags, /* 1.2.17 */ .domainInterfaceStats = vzDomainInterfaceStats, /* 1.2.17 */ [*] .domainMemoryStats = vzDomainMemoryStats, /* 1.2.17 */ .domainMigrateBegin3Params = vzDomainMigrateBegin3Params, /* 1.3.5 */ .domainMigrateConfirm3Params = vzDomainMigrateConfirm3Params, /* 1.3.5 */ [2] API calls that use thread shared sdkdom object (marked [*] are included for a different reason) .domainSuspend = vzDomainSuspend, /* 0.10.0 */ .domainResume = vzDomainResume, /* 0.10.0 */ .domainDestroy = vzDomainDestroy, /* 0.10.0 */ .domainShutdown = vzDomainShutdown, /* 0.10.0 */ .domainCreate = vzDomainCreate, /* 0.10.0 */ .domainCreateWithFlags = vzDomainCreateWithFlags, /* 1.2.10 */ .domainReboot = vzDomainReboot, /* 1.3.0 */ .domainDefineXML = vzDomainDefineXML, /* 0.10.0 */ .domainDefineXMLFlags = vzDomainDefineXMLFlags, /* 1.2.12 */ (update part) .domainUndefine = vzDomainUndefine, /* 1.2.10 */ .domainAttachDevice = vzDomainAttachDevice, /* 1.2.15 */ .domainAttachDeviceFlags = vzDomainAttachDeviceFlags, /* 1.2.15 */ .domainDetachDevice = vzDomainDetachDevice, /* 1.2.15 */ .domainDetachDeviceFlags = vzDomainDetachDeviceFlags, /* 1.2.15 */ .domainSetUserPassword = vzDomainSetUserPassword, /* 1.3.6 */ .domainManagedSave = vzDomainManagedSave, /* 1.2.14 */ .domainSetMemoryFlags = vzDomainSetMemoryFlags, /* 1.3.4 */ .domainSetMemory = vzDomainSetMemory, /* 1.3.4 */ .domainRevertToSnapshot = vzDomainRevertToSnapshot, /* 1.3.5 */ [*] .domainSnapshotCreateXML = vzDomainSnapshotCreateXML, /* 1.3.5 */ [*] .domainMigratePerform3Params = vzDomainMigratePerform3Params, /* 1.3.5 */ [*] .domainUpdateDeviceFlags = vzDomainUpdateDeviceFlags, /* 2.0.0 */ prlsdkHandleVmConfigEvent [3] API calls that do not use thread shared sdkdom object .domainManagedSaveRemove = vzDomainManagedSaveRemove, /* 1.2.14 */ .domainSnapshotNum = vzDomainSnapshotNum, /* 1.3.5 */ .domainSnapshotListNames = vzDomainSnapshotListNames, /* 1.3.5 */ .domainListAllSnapshots = vzDomainListAllSnapshots, /* 1.3.5 */ .domainSnapshotGetXMLDesc = vzDomainSnapshotGetXMLDesc, /* 1.3.5 */ .domainSnapshotNumChildren = vzDomainSnapshotNumChildren, /* 1.3.5 */ .domainSnapshotListChildrenNames = vzDomainSnapshotListChildrenNames, /* 1.3.5 */ .domainSnapshotListAllChildren = vzDomainSnapshotListAllChildren, /* 1.3.5 */ .domainSnapshotLookupByName = vzDomainSnapshotLookupByName, /* 1.3.5 */ .domainHasCurrentSnapshot = vzDomainHasCurrentSnapshot, /* 1.3.5 */ .domainSnapshotGetParent = vzDomainSnapshotGetParent, /* 1.3.5 */ .domainSnapshotCurrent = vzDomainSnapshotCurrent, /* 1.3.5 */ .domainSnapshotIsCurrent = vzDomainSnapshotIsCurrent, /* 1.3.5 */ .domainSnapshotHasMetadata = vzDomainSnapshotHasMetadata, /* 1.3.5 */ .domainSnapshotDelete = vzDomainSnapshotDelete, /* 1.3.5 */ [4] Known issues. 1. accidental errors on getting network statistics 2. race with simultaneous use of thread shared domain object on paths of adding domain thru API and adding domain on vz sdk domain added event.
-
由 Nikolay Shirokovskiy 提交于
see 4385b868
-
由 Nikolay Shirokovskiy 提交于
-
由 Nikolay Shirokovskiy 提交于
sdk domain handle is unique per connection so there is no sense to query it again if we have it in vzDomObjPtr. Side effect of prlsdkSdkDomainLookupByUUID is refreshing domain config is of no use too as PrlVm_BeginEdit do it too.
-
- 20 7月, 2016 8 次提交
-
-
由 John Ferlan 提交于
Commit id '5e46d7d6' did not take into account that usage of a luks volume will require usage of the master key encrypted passphrase for a QEMU environment. So rather than allow creation of something that won't be usable, just fail the creation.
-
由 John Ferlan 提交于
Resolves a CI test integration failure with a RHEL6/Centos6 environment. In order to use a LUKS encrypted device, the design decision was to generate an encrypted secret based on the master key. However, commit id 'da86c6c2' missed checking for that specifically. When qemuDomainSecretSetup was implemented, a design decision was made to "fall back" to a plain text secret setup if the specific cipher was not available (e.g. virCryptoHaveCipher(VIR_CRYPTO_CIPHER_AES256CBC)) as well as the QEMU_CAPS_OBJECT_SECRET. For the luks encryption setup there is no fall back to the plaintext secret, thus if that gets set up by qemuDomainSecretSetup, then we need to fail. Also, while the qemuxml2argvtest has set the QEMU_CAPS_OBJECT_SECRET bit, it didn't take into account the second requirement that the ability to generate the encrypted secret is possible. So modify the test to not attempt to run the luks-disk if we know we don't have the encryption algorithm.
-
由 John Ferlan 提交于
virStorageBackendCreateQemuImgCheckEncryption didn't return -1 if there were no secrets.
-
由 John Ferlan 提交于
A post push realization that the boolean should be set inside the condition
-
由 John Ferlan 提交于
A post push realization that the setting of the boolean needed to be inside the if condition.
-
由 Ján Tomko 提交于
Most of the lines we look at are not going to match one of the driver types contained in $groups_regex. Move on to the next line if it does not contain any of them early. This speeds up the script execution by 50%, since this simple regex does not have any capture groups.
-
由 Ján Tomko 提交于
The %groups hash contains all the driver types (e.g. virHypervisorDriver or virSecretDriver). When searching for all the APIs that are implemented by a driver of that specific driver type, we keep iterating over the %groups hash on every line we look at, then matching against the driver type. This is inefficient because it prevents perl from caching the regex and it executes the regex once for every driver type, even though one regex matching excludes all the others, since all the driver types are different. Construct the regex containing all the driver types upfront to save about 6.4s (~98%) of the script execution time.
-
由 Ján Tomko 提交于
When generating the hvsupport.html.in file, we parse the -api.xml files generated by apibuild.py to know in which HTML file the API function is. Doing an XPath query for every single 'function' element in the file is inefficient. Since the XML file is generated by another of our build scripts (apibuild.py, using Python's standard 'output.write' XML library), just find the function name->file mapping by a regex upfront. Also add a note about this next to the line that generates it in apibuild.py and do not check if XML::XPath is installed in bootstrap since we no longer use it.
-
- 19 7月, 2016 21 次提交
-
-
由 Cédric Bosdonnat 提交于
Any error happening after the hand shake in the lxc controller will not result in a failure as errors are checked during the handshake. Move the handshake after the last possible error.
-
由 Cédric Bosdonnat 提交于
Better fix replacing c726af2d: introducing an 'R' permission to add read rule, but no explicit deny write rule.
-
由 John Ferlan 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1301021 Generate the luks command line using the AES secret key to encrypt the luks secret. A luks secret object will be in addition to a an AES secret. For hotplug, check if the encinfo exists and if so, add the AES secret for the passphrase for the secret object used to decrypt the device. Modify/augment the fakeSecret* in qemuxml2argvtest in order to handle find a uuid or a volume usage with a specific path prefix in the XML (corresponds to the already generated XML tests). Add error message when the 'usageID' is not 'mycluster_myname'. Commit id '1d632c39' altered the error message generation to rely on the errors from the secret_driver (or it's faked replacement). Add the .args output for adding the LUKS disk to the domain Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Soon we will be adding luks encryption support. Since a volume could require both a luks secret and a secret to give to the server to use of the device, alter the alias generation to create a slightly different alias so that we don't have two objects with the same alias. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Commit id 'a1344f70' added AES secret processing for RBD when starting up a guest. As such, when the hotplug code calls qemuDomainSecretDiskPrepare an AES secret could be added to the disk about to be hotplugged. If an AES secret was added, then the hotplug code would need to generate the secret object because qemuBuildDriveStr would add the "password-secret=" to the returned 'driveStr' rather than the base64 encoded password. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1301021 If the volume xml was looking to create a luks volume take the necessary steps in order to make that happen. The processing will be: 1. create a temporary file (virStorageBackendCreateQemuImgSecretPath) 1a. use the storage driver state dir path that uses the pool and volume name as a base. 2. create a secret object (virStorageBackendCreateQemuImgSecretObject) 2a. use an alias combinding the volume name and "_luks0" 2b. add the file to the object 3. create/add luks options to the commandline (virQEMUBuildLuksOpts) 3a. at the very least a "key-secret=%s" using the secret object alias 3b. if found in the XML the various "cipher" and "ivgen" options Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
The 'res' variable was only being initialized to NULL in the if (!state) path; however, that path never used res and evenutally res is assigned one of two results based on a pair of if then else if conditions. If for some reason neither of those paths was taken and the (!state) path wasn't taken, then 'res' would be indeterminate. Found by Coverity, probably a false positive based on code paths, but better safe than sorry for the future. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
When formatting the graphics data for TYPE_SPICE, check if the glisten is NULL before blindly referencing Found by Coverity Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Cannot assume virGetLastError returns non-NULL value - modify the code to fetch err and check if err && err->code Found by Coverity Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Commit id '740e4d70' altered the logic to fetch the sysconf values and added a new virConfGetValueStringList which returns -1 on failure, 0 if missing, and 1 if the value was present. However, the caller only checked !shargv which caught Coverity's attention since the following VIR_ALLOC_N(*shargv, 2) would be a NULL ptr deref Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Since we VIR_ALLOC_N to *values, the VIR_FREE should be done likewise Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Erik Skultety 提交于
Internally, all the data are represented as unsigned int, it is also documented in the header file that users should use our exported constants that also indicate that the data should be unsigned int. However, when polling for the current server threadpool's configuration, virt-admin uses an incorrect formatting parameter '%d' for printf. Instead, virt-admin should use formatting parameter '%u'. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1356769Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 John Ferlan 提交于
Move to virqemu and rename to virQEMUBuildBufferEscapeComma. This can then be shared by the storage driver when it builds the command line for qemuimg
-
由 John Ferlan 提交于
A recent adjustment to qemuDomainAttachRNGDevice to properly cleanup the props object after a qemuMonitorAddObject also would affect this code. Alter the cleanup to be similar to RNG changes.
-
由 John Ferlan 提交于
Based on recent review comment - rather than have a spate of goto failxxxx, change to a boolean based model. Ensures that the original error can be preserved and cleanup is a bit more orderly if more objects are added.
-
由 John Ferlan 提交于
Based on recent review comment - rather than have a spate of goto failxxxx, change to a boolean based model. Ensures that the original error can be preserved and cleanup is a bit more orderly if more objects are added.
-
由 John Ferlan 提交于
Based on recent review comment - rather than have a spate of goto failxxxx, change to a boolean based model. Ensures that the original error can be preserved and cleanup is a bit more orderly if more objects are added.
-
由 John Ferlan 提交于
Based on recent review comment - rather than have a spate of goto failxxxx, change to a boolean based model. Ensures that the original error can be preserved and cleanup is a bit more orderly if more objects are added.
-
由 John Ferlan 提交于
Based on recent review comment - rather than have a spate of goto failxxxx, change to a boolean based model. Ensures that the original error can be preserved and cleanup is a bit more orderly if more objects are added.
-
由 Erik Skultety 提交于
Commit da665fbd introduced the following condition to virLXCProcessEnsureRootFS and openvzReadFSConf: if (!(<some_var> = virDomainFSDefNew()) < 0) which broke the build on fedora with GCC 5.3.1: "logical not is only applied to the left hand side of comparison". Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Julio Faracco 提交于
The commit da665fbd introduced virStorageSourcePtr inside the structure _virDomainFSDef. This is causing an error when libvirt is being compiled. make[3]: Entering directory `/media/julio/8d65c59c-6ade-4740-9cdc-38016a4cb8ae /home/julio/Desktop/virt/libvirt/src' CC security/virt_aa_helper-virt-aa-helper.o security/virt-aa-helper.c: In function 'get_files': security/virt-aa-helper.c:1087:13: error: passing argument 2 of 'vah_add_path' from incompatible pointer type [-Werror] if (vah_add_path(&buf, fs->src, "rw", true) != 0) ^ security/virt-aa-helper.c:732:1: note: expected 'const char *' but argument is of type 'virStorageSourcePtr' vah_add_path(virBufferPtr buf, const char *path, const char *perms, bool recursive) ^ cc1: all warnings being treated as errors Adding the attribute "path" from virStorageSourcePtr fixes this issue. Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
-