- 03 5月, 2016 1 次提交
-
-
由 Erik Skultety 提交于
Admin API needs a way of addressing specific clients. Unlike servers, which we are happy to address by names both because its name reflects its purpose (to some extent) and we only have two of them (so far), naming clients doesn't make any sense, since a) each client is an anonymous, i.e. not recognized after a disconnect followed by a reconnect, b) we can't predict what kind of requests it's going to send to daemon, and c) the are loads of them comming and going, so the only viable option is to use an ID which is of a reasonably wide data type. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 02 5月, 2016 39 次提交
-
-
由 Andrea Bolognani 提交于
Move the code dealing with init scripts to a separate file so configure.ac itself can be a little bit smaller.
-
由 Andrea Bolognani 提交于
Most distributions, including RHEL, have switched to systemd, so we should detect it and act accordingly. This also means that 'systemd+redhat' should be preferred to legacy 'redhat'. Our witness for the check is the availability of the systemctl command on the host.
-
由 Andrea Bolognani 提交于
If we didn't find a match, either because we're cross compiling or because we're not building on RHEL, we won't install any init script. Make sure this is reported correctly in the configure summary.
-
由 Boris Fiuczynski 提交于
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
由 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>
-
由 Boris Fiuczynski 提交于
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
由 Cole Robinson 提交于
The iohelper dies on SIGPIPE if the stream is closed before all data is processed. IMO this should be an error condition for virStreamFinish according to docs like: * This method is a synchronization point for all asynchronous * errors, so if this returns a success code the application can * be sure that all data has been successfully processed. However for virStreamAbort, not so much: * Request that the in progress data transfer be cancelled * abnormally before the end of the stream has been reached. * For output streams this can be used to inform the driver * that the stream is being terminated early. For input * streams this can be used to inform the driver that it * should stop sending data. Without this, virStreamAbort will realistically always error for active streams like domain console. So, treat the SIGPIPE case as non-fatal if abort is requested. Note, this will only affect an explicit user requested abort. An abnormal abort, like from a server error, always raises an error in the daemon.
-
由 Cole Robinson 提交于
Every time a client aborts a stream via the virStreamAbort API, the daemon always logs an error like: error : daemonStreamHandleAbort:617 : stream aborted at client request and that same error is returned to the client. Meaning virStreamAbort always returns -1, which seems strange. This reworks the error handling to only raise an error on virStreamAbort if the actual server side abort call raises an error. This is similar to how virStreamFinish works. If the abort code path is triggered by an unexpected message type then we continue to raise an unconditional error. Also drop a redundant VIR_WARN call there, since virReportError will raise a VIR_ERROR anyways
-
由 Cole Robinson 提交于
The described protocol semantics really only apply to server initiated stream messages. Document the semantics for client messages.
-
由 Cole Robinson 提交于
These are the only places where we don't set stream->closed when aborting the stream. This leads to spurious errors when the client hangs up unexpectedly: error : virFDStreamUpdateCallback:127 : internal error: stream is not open
-
由 Cole Robinson 提交于
Calling virStreamFinish prematurely seems to trigger this code path even after the stream is closed, which ends up hitting this error message later: error : virFDStreamUpdateCallback:127 : internal error: stream is not open Skip this function if stream->closed, which is used in many other places like read/write handlers
-
由 Cole Robinson 提交于
This is the only place in daemon/stream.c that sets 'stream->closed = true' but neglects to actually abort the stream and remove the callback, which seems wrong.
-
由 Cole Robinson 提交于
This happens when virStreamFinish/Abort are called, but iohelper still has data to process.
-
由 Cole Robinson 提交于
Rather than poorly duplicate it
-
由 Cole Robinson 提交于
Let's us de-nest some of the logic, and will simplify upcoming patches
-
由 Cole Robinson 提交于
libvirt-daemon-config-nwfilter will put a bunch of xml configs into /etc/libvirt/nwfilter. These configs don't hardcode a UUID and depends on libvirt to generate one. However the generated UUID is never saved to disk, unless the user manually calls Define. This makes daemon reload quite noisy with many errors like: error : virNWFilterObjAssignDef:3101 : operation failed: filter 'allow-incoming-ipv4' already exists with uuid 50def3b5-48d6-46a3-b005-cc22df4e5c5c Because a new UUID is generated every time the config is read from disk, so libvirt constantly thinks it's finding a new nwfilter. Detect if we generated a UUID when the config file is loaded; if so, resave the new contents to disk to ensure the UUID is persisteny. This is similar to what was done in commit a47ae7c0 with virtual networks and generated MAC addresses
-
由 Cole Robinson 提交于
This matches the pattern used for network object APIs, and we want configDir in LoadConfig for upcoming patches
-
由 Cole Robinson 提交于
In virNWFilterObjLoad we can still fail after virNWFilterObjAssignDef, but we don't unlock and free the created virNWFilterObjPtr in the cleanup path. The bit we are trying to do after AssignDef is just STRDUP in the configFile path. However caching the configFile in the NWFilterObj is largely redundant and doesn't follow the same pattern we use for domain and network objects. So just remove all the configFile caching which fixes the latent bug as a side effect.
-
由 Cole Robinson 提交于
We will segfault of a daemon reload picks up a new network config that needs to be autostarted. We shouldn't be passing NULL for network_driver here. This seems like it was missed in the larger rework in commit 1009a61e
-
由 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>
-
由 Cole Robinson 提交于
We historically format runtime seclabel selinux/apparmor values, however we skip formatting runtime DAC values. This was added in commit 990e46c4 Author: Marcelo Cerri <mhcerri@linux.vnet.ibm.com> Date: Fri Aug 31 13:40:41 2012 +0200 conf: Avoid formatting auto-generated DAC labels to maintain migration compatibility with libvirt < 0.10.0. However the formatting was skipped unconditionally. Instead only skip formatting in the VIR_DOMAIN_DEF_FORMAT_MIGRATABLE case. https://bugzilla.redhat.com/show_bug.cgi?id=1215833
-
由 Cole Robinson 提交于
Trying to define a pool name containing an embedded '/' will immediately fail when trying to write the XML to disk. This patch explicitly rejects names containing a '/' Besides our stateful driver, there are two other storage impls: esx and phyp. esx doesn't support pool creation, so this should doesn't apply. phyp does support pool creation, and the name is passed to the 'mksp' tool, which google doesn't reveal whether it accepts '/' or not. IMO the likeliness of this impacting any users is near zero
-
由 Cole Robinson 提交于
Trying to define a network name containing an embedded '/' will immediately fail when trying to write the XML to disk. This patch explicitly rejects names containing a '/' Besides the network bridge driver, the only other network implementation is a very thin one for virtualbox, which seems to use the network name as a host interface name, which won't accept '/' anyways, so I think this is fine to do unconitionally. https://bugzilla.redhat.com/show_bug.cgi?id=787604
-
由 Cole Robinson 提交于
Trying to define a domain name containing an embedded '/' will immediately fail when trying to write the XML to disk for our stateful drivers. This patch explicitly rejects names containing a '/', and provides an xmlopt feature for drivers to avoid this validation check, which is enabled in every non-stateful driver that already has xmlopt handling wired up. (Technically this could reject a previously accepted vmname like '/foo', however at least for the qemu driver that falls over later when starting qemu) https://bugzilla.redhat.com/show_bug.cgi?id=639923
-
由 Martin Kletzander 提交于
We were lacking tests that are checking for the completeness of our nodedev XMLs and also whether we output properly formatted ones. This patch adds parsing for the capability elements inside the <capability type='pci'> element. Also bunch of tests are added to show everything works properly. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
There were few things done in the nodedev code but we were lacking tests for it. And because of that we missed that the schema was not updated either. Fix the schema and add various test files to show the schema is correct. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
All sub-PCI capabilities should be next to each other for clarity. Signed-off-by: NMartin Kletzander <mkletzan@redhat.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>
-