- 17 6月, 2016 3 次提交
-
-
由 Peter Krempa 提交于
While we need to know the difference between the total memory stored in <memory> and the actual size not included in the possible memory modules we can't pre-calculate it reliably. This is due to the fact that libvirt's XML is copied via formatting and parsing the XML and the initial memory size can be reliably calculated only when certain conditions are met due to backwards compatibility. This patch removes the storage of 'initial_memory' and fixes the helpers to recalculate the initial memory size all the time from the total memory size. This conversion is possible when we also make sure that memory hotplug accounts properly for the update of the total memory size and thus the helpers for inserting and removing memory devices need to be tweaked too. This fixes a bug where a cold-plug and cold-remove of a memory device would increase the size reported in <memory> in the XML by the size of the memory device. This would happen as the persistent definition is copied before attaching the device and this would lead to the loss of data in 'initial_memory'. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1344892
-
由 Laine Stump 提交于
Until now, a Q35 domain (or arm/virt, or any other domain that has a pcie-root bus) would always have a pci-bridge added, so that there would be a hotpluggable standard PCI slot available to plug in any PCI devices that might be added. This patch removes the explicit add, instead relying on the pci-bridge being auto-added during PCI address assignment (it will add a pci-bridge if there are no free slots). This doesn't eliminate the dmi-to-pci-bridge controller that is explicitly added whether or not a standard PCI slot is required (and that is almost never used as anything other than a converter between pcie.0's PCIe slots and standard PCI). That will be done separately.
-
由 Laine Stump 提交于
Previously there was no way to have a Q35 domain that didn't have these two controllers. This patch skips their creation as long as there are some other kinds of pci controllers at index 1 and 2 (e.g. some pcie-root-port controllers). I'm hoping that soon we won't add them at all, plugging all devices into auto-added pcie-*-port ports instead, but in the meantime this makes it easier to experiment with alternative bus hierarchies.
-
- 09 6月, 2016 3 次提交
-
-
由 Pavel Hrdina 提交于
VNC graphics already supports sockets but only via 'socket' attribute. This patch coverts that attribute into listen type 'socket'. For backward compatibility we need to handle listen type 'socket' and 'socket' attribute properly to support old XMLs and new XMLs. If both are provided they have to match, if only one of them is provided we need to be able to parse that configuration too. To not break migration back to old libvirt if the socket is provided by user we need to generate migratable XML without the listen element and use only 'socket' attribute. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Even though it's auto-generated it's based on qemu.conf option and listen type address already uses "fromConfig" to carry this information. Following commits will convert the socket to listen element so this rename is required because there will be also an option to get socket auto-generated independently on the qemu.conf option. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 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 2 次提交
-
-
由 Peter Krempa 提交于
One of the functions is returning always 0 and the second one uses unnecessary labels.
-
由 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.
-
- 07 6月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
Introduce a validation callback for qemu and move checking of min_guarantee to the new callback.
-
由 Peter Krempa 提交于
Until now we weren't able to add checks that would reject configuration once accepted by the parser. This patch adds a new callback and infrastructure to add such checks. In this patch all the places where rejecting a now-invalid configuration wouldn't be a good idea are marked with a new parser flag.
-
- 23 5月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Remove more checks that are no longer necessary.
-
- 20 5月, 2016 4 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1182074 If they're available and we need to pass secrets to qemu, then use the qemu domain secret object in order to pass the secrets for RBD volumes instead of passing the base64 encoded secret on the command line. The goal is to make AES secrets the default and have no user interaction required in order to allow using the AES mechanism. If the mechanism is not available, then fall back to the current plain mechanism using a base64 encoded secret. New APIs: qemu_domain.c: qemuDomainGetSecretAESAlias: Generate/return the secret object alias for an AES Secret Info type. This will be called from qemuDomainSecretAESSetup. qemuDomainSecretAESSetup: (private) This API handles the details of the generation of the AES secret and saves the pieces that need to be passed to qemu in order for the secret to be decrypted. The encrypted secret based upon the domain master key, an initialization vector (16 byte random value), and the stored secret. Finally, the requirement from qemu is the IV and encrypted secret are to be base64 encoded. qemu_command.c: qemuBuildSecretInfoProps: (private) Generate/return a JSON properties object for the AES secret to be used by both the command building and eventually the hotplug code in order to add the secret object. Code was designed so that in the future perhaps hotplug could use it if it made sense. qemuBuildObjectSecretCommandLine (private) Generate and add to the command line the -object secret for the secret. This will be required for the subsequent RBD reference to the object. qemuBuildDiskSecinfoCommandLine (private) Handle adding the AES secret object. Adjustments: qemu_domain.c: The qemuDomainSecretSetup was altered to call either the AES or Plain Setup functions based upon whether AES secrets are possible (we have the encryption API) or not, we have secrets, and of course if the protocol source is RBD. qemu_command.c: Adjust the qemuBuildRBDSecinfoURI API's in order to generate the specific command options for an AES secret, such as: -object secret,id=$alias,keyid=$masterKey,data=$base64encodedencrypted, format=base64 -drive file=rbd:pool/image:id=myname:auth_supported=cephx\;none:\ mon_host=mon1.example.org\:6321,password-secret=$alias,... where the 'id=' value is the secret object alias generated by concatenating the disk alias and "-aesKey0". The 'keyid= $masterKey' is the master key shared with qemu, and the -drive syntax will reference that alias as the 'password-secret'. For the -drive syntax, the 'id=myname' is kept to define the username, while the 'key=$base64 encoded secret' is removed. While according to the syntax described for qemu commit '60390a21' or as seen in the email archive: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04083.html it is possible to pass a plaintext password via a file, the qemu commit 'ac1d8878' describes the more feature rich 'keyid=' option based upon the shared masterKey. Add tests for checking/comparing output. NB: For hotplug, since the hotplug code doesn't add command line arguments, passing the encoded secret directly to the monitor will suffice.
-
由 John Ferlan 提交于
Currently just a shim to call qemuDomainSecretPlainSetup, but soon to be more
-
由 John Ferlan 提交于
Move the logic from qemuDomainGenerateRandomKey into this new function, altering the comments, variable names, and error messages to keep things more generic. NB: Although perhaps more reasonable to add soemthing to virrandom.c. The virrandom.c was included in the setuid_rpc_client, so I chose placement in vircrypto.
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 19 5月, 2016 1 次提交
-
-
由 Cole Robinson 提交于
This wires up qemuDomainAssignAddresses into the new virDomainDefAssignAddressesCallback, so it's always triggered via virDomainDefPostParse. We are essentially doing this already with open coded calls sprinkled about. qemu argv parse output changes slightly since previously it wasn't hitting qemuDomainAssignAddresses.
-
- 18 5月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
When the <gic/> element in not present in the domain XML, use the domain capabilities to figure out what GIC version is usable and choose that one automatically. This allows guests to be created on hardware that only supports GIC v3 without having to update virt-manager and similar tools. Keep using the default GIC version if the <gic/> element has been added to the domain XML but no version has been specified, as not to break existing guests.
-
- 16 5月, 2016 3 次提交
-
-
由 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>
-
由 Peter Krempa 提交于
They don't free the structure itself so they should be called *Clear rather than *Free.
-
由 Peter Krempa 提交于
Call the internal driver callbacks rather than the public APIs to avoid calling unnecessarily the error dispatching code and don't overwrite the error messages provided by the APIs. They are good enough to describe which secret is missing either by UUID or the usage (basically name).
-
- 13 5月, 2016 1 次提交
-
-
由 Shivaprasad G Bhat 提交于
Further followup discussions in list on commit 192a53e0 concluded that we should be leaving out the USB controller only for i440fx machines as default USB can be used by someone on q35 at random slots. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
-
- 12 5月, 2016 1 次提交
-
-
由 John Ferlan 提交于
The preferred name will be AES not IV, change current references Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 11 5月, 2016 2 次提交
-
-
由 Laine Stump 提交于
libvirt may automatically add a pci-root or pcie-root controller to a domain, depending on the arch/machinetype, and it hopefully always makes the right decision about which to add (since in all cases these controllers are an implicit part of the virtual machine). But it's always possible that someone will create a config that explicitly supplies the wrong type of PCI controller for the selected machinetype. In the past that would lead to an error later when libvirt was trying to assign addresses to other devices, for example: XML error: PCI bus is not compatible with the device at 0000:00:02.0. Device requires a PCI Express slot, which is not provided by bus 0000:00 (that's the error message that appears if you replace the pcie-root controller in a Q35 domain with a pci-root controller). This patch adds a check at the same place that the implicit controllers are added (to ensure that the same logic is used to check which type of pci root is correct). If a pci controller with index='0' is already present, we verify that it is of the model that we would have otherwise added automatically; if not, an error is logged: The PCI controller with index='0' must be " model='pcie-root' for this machine type, " but model='pci-root' was found instead. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004602
-
由 John Ferlan 提交于
Remove the possibility that a NULL hostdev->privateData or a disk->privateData could crash libvirtd by checking for NULL before dereferencing for the secinfo structure in the qemuDomainSecret{Disk|Hostdev}Destroy functions. The hostdevPriv could be NULL if qemuProcessNetworkPrepareDevices adds a new hostdev during virDomainNetGetActualHostdev that then gets inserted via virDomainHostdevInsert. The hostdevPriv was added by commit id '27726d8c' and is currently only used by scsi hostdev.
-
- 09 5月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
qemuDomainCheckDiskPresence has short-circuit code to skip the determination of the disk backing chain for storage formats that can't have backing volumes. The code treats VIR_STORAGE_FILE_NONE as not having backing chain and skips the call to qemuDomainDetermineDiskChain. This is wrong as qemuDomainDetermineDiskChain is responsible for storage format detection and has logic to determine the default type if format detection is disabled. This allows to storage passed via <disk type="volume"> to circumvent the enforcement to have correct storage format or that we shall default to format='raw', since we don't set the default type via the post parse callback for "volume" backed disks as the translation code could come up with a better guess. This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1328003
-
由 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 4 次提交
-
-
由 Ján Tomko 提交于
In qemuDomainDefAddDefaultDevices we check for a non-NULL def->os.machine for x86 archs, but not the others. Moreover, the only caller - qemuDomainDefPostParse already checks for it and even then it can happen only if /etc/libvirt contains an XML without a machine type.
-
由 Ján Tomko 提交于
Use it everywhere except for virQEMUCapsFillDomainFeatureGICCaps.
-
由 Ján Tomko 提交于
For all the other machine types, we use a positive condition. Be more positive and use it for i440fx too.
-
由 Ján Tomko 提交于
Do not duplicate the string comparisons by writing them twice.
-
- 02 5月, 2016 7 次提交
-
-
由 Boris Fiuczynski 提交于
This patch adds by default a panic device with model s390 to S390 guests. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
由 Boris Fiuczynski 提交于
If a panic device is being defined without a model in a domain the default value is always overwritten with model ISA. An ISA bus does not exist on S390 and therefore specifying a panic device results in an unsupported configuration. Since the S390 architecture inherently provides a crash detection capability the panic device should be defined in the domain xml. This patch adds an s390 panic device model and prevents setting a device address on it. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
-
由 Boris Fiuczynski 提交于
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
由 Shivaprasad G Bhat 提交于
The default USB controller is not sent to destination as the older versions of libvirt(0.9.4 or earlier as I see in commit log of 409b5f54) didn't support them. For some archs where the support started much later can safely send the USB controllers without this worry. So, send the controller to destination for all archs except x86. Moreover this is not very applicable to x86 as the USB controller has model ich9_ehci1 on q35 and for pc-i440fx, there cant be any slots before USB as it is fixed on slot 1. The patch fixes a bug that, if the USB controller happens to occupy a slot after disks/interfaces and one of them is hot-unplugged, then the default USB controller added on destination takes the smallest slot number and that would lead to savestate mismatch and migration failure. Seen and verified on PPC64. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
-
由 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>
-