- 04 5月, 2016 6 次提交
-
-
由 Erik Skultety 提交于
Since nparams can be technically negative, it is a good practice throughout our code to check if nparams actually has a non-negative value. The same effect would be achieved by converting our internal typed params serializer argument to 'unsigned' type, but it definitely would not be the path of least resistance. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 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 提交于
Add the ability to add an 'iothread' to the controller which will be how virtio-scsi-pci and virtio-scsi-ccw iothreads have been implemented in qemu. Describe the new functionality and add tests to parse/validate that the new attribute can be added.
-
由 John Ferlan 提交于
Move virDomainControllerModelTypeToString closer to it's counterpart virDomainControllerModelTypeFromString. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 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 28 次提交
-
-
由 Erik Skultety 提交于
Expose a public API to retrieve some identity and connection information about a client connected to the specified server on daemon. The identity info retrieved is mostly connection transport dependent, i.e. there won't be any socket address returned for a local (UNIX socket) connection, while on the other hand, when connected through TLS or unencrypted TCP, obviously no UNIX process identification will be present in the returned data. All supported values that can be returned in typed params are exposed and documented in include/libvirt/libvirt-admin.h Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
This method just aggregates various client object attributes, like socket address, connection type (RO/RW), and some TCP/TLS/UNIX identity in an atomic manner. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
We do have a similar method, serving the same purpose, for TLS, but we lack one for SASL. So introduce one, in order for other modules to be able to find out, if a SASL session is active, or better said, that a SASL session exists at all. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
Our socket address format is in a rather non-standard format and that is because sasl library requires the IP address and service to be delimited by a semicolon. The string form is a completely internal matter, however once the admin interfaces to retrieve client identity information are merged, we should return the socket address string in a common format, e.g. format defined by URI rfc-3986, i.e. the IP address and service are delimited by a colon and in case of an IPv6 address, square brackets are added: Examples: 127.0.0.1:1234 [::1]:1234 This patch changes our default format to the one described above, while adding separate methods to request the non-standard SASL format using semicolon as a delimiter. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
Just like with server-related APIs, before any of client-based APIs can be called, a reference to a client-side client object needs to be obtained. For this purpose, a lookup method should exist. Apart from the client retrieval logic, a new error code for non-existent client had to be added as well. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 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>
-
由 Nikolay Shirokovskiy 提交于
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.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>
-
由 Erik Skultety 提交于
Finally add public method to retrieve the list of currently connected clients to a given server. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
Although we document 6 types of transport that we support, internally we can only differentiate between TCP, TLS, and UNIX transports only, since both SSH and libssh2 transports, due to using netcat, behave in the exactly the same way as a UNIX socket. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
For now, the list copy is done simply by locking the whole server, walking the original and increasing the refcount on each object. We may want to change the list to a lockable object (like list of domains) later in the future if we discover some performance issues related to locking the whole server in order to walk the whole list of clients, possibly issuing some 'ForEach' callback. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
Now that libvirt-admin supports another client-side object and provided that we want to generate as many both client-side and server-side RPC dispatchers, support for this needs to be added to gendispatch. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
Besides ID, the object also stores static data like connection transport and connection timestamp, since once obtained a list of all clients connected to a server, from user's perspective, it would be nice to know whether a given client is remote or local only and when did it connect to the daemon. Along with the object introduction, all necessary client-side methods necessary to work with the object are added as well. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
Besides ID, libvirt should provide several parameters to help the user distinguish two clients from each other. One of them is the connection timestamp. This patch also adds a testcase for proper JSON formatting of the new attribute too (proper formatting of older clients that did not support this attribute yet is included in the existing tests) - in order to testGenerateJSON to work, a mock of time_t time(time_t *timer) needed to be created. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 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 6 次提交
-
-
由 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>
-
由 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 提交于
The described protocol semantics really only apply to server initiated stream messages. Document the semantics for client messages.
-