- 06 5月, 2016 5 次提交
-
-
由 John Ferlan 提交于
Create helper API's in order to build the network URI as shortly we will be adding a new SecretInfo type Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than need to call qemuDomainSecretDestroy after any call to qemuProcessLaunch, let's do the destroy in qemuProcessLaunch since that's where command line is eventually generated and processed. Once it's generated, we can clear out the secrets. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Commit id '40d8e2ba' added the function to qemuProcessStart because in order to set up some secrets in the future we will need the master key. However, since the previous patch split the master key creation into two parts (create just the key and create the file), we can now call qemuDomainSecretPrepare from qemuProcessPrepareDomain since the file is not necessary. 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>
-
- 05 5月, 2016 2 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
virQEMUCapsNewForBinary unconditionally loads data from cache and probes using both QMP and -help parsing, which is suboptimal when we want to use it in tests. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 04 5月, 2016 3 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1286709 Now that we have all the pieces in place, we can add the 'iothread=#' to the command line for the (two) controllers that support it (virtio-scsi-pci and virtio-scsi-ccw). Add the tests as well...
-
由 John Ferlan 提交于
Rather than an if statement, use a switch. The switch will also catch the illegal usage of 'iothread' with some other kind of unsupported bus configuration.
-
由 John Ferlan 提交于
An iothread for virtio-scsi is a property of the controller. Add a lookup of the 'virtio-scsi-pci' and 'virtio-scsi-ccw' device properties and parse the output. For both, support for the iothread was added in qemu 2.4 while support for virtio-scsi in general was added in qemu 1.4. Modify the various mock capabilities replies (by hand) to reflect the when virtio-scsi was supported and then specifically when the iothread property was added. For versions prior to 1.4, use the no device error return for virtio-scsi. For versions 1.4 to before 2.4, add some data for virtio-scsi-pci even though it isn't complete we're not looking for anything specific there anyway. For 2.4 to 2.6, add a more complete reply. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 03 5月, 2016 15 次提交
-
-
由 Michal Privoznik 提交于
In majority of our functions we have this variable @ret that is overwritten a lot. In other areas of the code we use 'goto cleanup;' just so that this wouldn't happen. But here. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Cole Robinson 提交于
This adds a ports= attribute to usb controller XML, like <controller type='usb' model='nec-xhci' ports='8'/> This maps to: qemu -device nec-usb-xhci,p2=8,p3=8 Meaning, 8 ports that support both usb2 and usb3 devices. Gerd suggested to just expose them as one knob. https://bugzilla.redhat.com/show_bug.cgi?id=1271408
-
由 Cole Robinson 提交于
Reports whether we support -device nec-usb-xhci,p3=XXX value, which has been available since qemu 1.3.0
-
由 Cole Robinson 提交于
Rather than reimplement it. This will be needed in upcoming patches
-
由 Michal Privoznik 提交于
In these functions I'm fixing here, we do call qemuMonitorJSONCheckError() followed by another check if qemu reply contains 'return' object. If it wouldn't, the former CheckError() function would error out and the flow would not even get to the latter. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Usually, the flow in this area of the code is as follows: qemuMonitorJSONMakeCommand() qemuMonitorJSONCommand() qemuMonitorJSONCheckError() parseReply() But in this function, for some reasons, the last two steps were swapped. This makes no sense. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 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 提交于
It was not indented correctly.
-
由 Ján Tomko 提交于
We do not need to propagate the exact return values and the only possible ones are 0 and -1 anyway. Remove the temporary variable and use the usual pattern: if (f() < 0) return -1;
-
由 Ján Tomko 提交于
This function does not fail and it does not need to return anything.
-
由 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.
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1139766 Thing is, for some reasons you can have your domain's RTC to be in something different than UTC. More weirdly, it's not only time zone what you can shift it of, but an arbitrary value. So, if domain is configured that way, libvirt will correctly put it onto qemu cmd line and moreover track it as this offset changes during domain's life time (e.g. because guest OS decides the best thing to do is set new time to RTC). Anyway, they way in which this tracking is implemented is events. But we've got a problem if change in guest's RTC occurs and the daemon is not running. The event is lost and we end up reporting invalid value in domain XML. Therefore, when the daemon is starting up again and it is reconnecting to all running domains, re-fetch their RTC so the correct offset value can be computed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 02 5月, 2016 15 次提交
-
-
由 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>
-
由 Boris Fiuczynski 提交于
Adding the default bus type ISA to the message. 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>
-
由 Martin Kletzander 提交于
We had both and the only difference was that the latter also included information about multifunction setting. The problem with that was that we couldn't use functions made for only one of the structs (e.g. parsing). To consolidate those two structs, use the one in virpci.h, include that in domain_conf.h and add the multifunction member in it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 John Ferlan 提交于
If we failed to build the aliases or attach the chardev, then the props would be leaked - fix that. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Adjust error path logic to make it clearer how to undo the failed add. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Adjust error path logic to make it clearer how to undo the failed add. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Adjust error path logic to make it clearer how to undo the failed add. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than take username and password as parameters, now take a qemuDomainSecretInfoPtr and decode within the function. NB: Having secinfo implies having the username for a plain type from a successful virSecretGetSecretString Signed-off-by: NJohn Ferlan <jferlan@redhat.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>
-
由 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>
-