- 28 10月, 2010 2 次提交
-
-
由 Daniel P. Berrange 提交于
Add audit hooks to report all start and stop events on QEMU guest domains. * src/qemu/qemu_driver.c: Audit start/stop events
-
由 Daniel P. Berrange 提交于
Revert most of commit a8b5f9bd. The audit hooks will be re-added directly in the QEMU driver code in a future commit * daemon/remote.c: Remove all audit logging hooks * src/qemu/qemu_driver.c: Remove all audit logging hooks
-
- 21 10月, 2010 2 次提交
-
-
由 Matthias Bolte 提交于
There is no point in trying to fill params beyond the first error, because when qemuDomainGetMemoryParameters returns -1 then the caller cannot detect which values in params are valid.
-
由 Matthias Bolte 提交于
To get them under the common VIR_DOMAIN_MEMORY_* prefix.
-
- 20 10月, 2010 5 次提交
-
-
由 Miloslav Trmač 提交于
Most operations are audited at the libvirtd level; auditing in src/libvirt.c would result in two audit entries per operation (one in the client, one in libvirtd). The only exception is a domain stopping of its own will (e.g. because the user clicks on "shutdown" inside the interface). There can often be no client connected at the time the domain stops, so libvirtd does not have any virConnectPtr object on which to attach an event watch. This patch therefore adds auditing directly inside the qemu driver (other drivers are not supported).
-
由 Eric Blake 提交于
* src/qemu/qemu_driver.c (qemudDomainSetVcpusFlags) (qemudDomainGetVcpusFlags): Support all feasible flag combinations.
-
由 Eric Blake 提交于
Although this patch adds a distinction between maximum vcpus and current vcpus in the XML, the values should be identical for all drivers at this point. Only in subsequent per-driver patches will a distinction be made. In general, virDomainGetInfo should prefer the current vcpus. * src/conf/domain_conf.h (_virDomainDef): Adjust vcpus to unsigned short, to match virDomainGetInfo limit. Add maxvcpus member. * src/conf/domain_conf.c (virDomainDefParseXML) (virDomainDefFormat): parse and print out vcpu details. * src/xen/xend_internal.c (xenDaemonParseSxpr) (xenDaemonFormatSxpr): Manage both vcpu numbers, and require them to be equal for now. * src/xen/xm_internal.c (xenXMDomainConfigParse) (xenXMDomainConfigFormat): Likewise. * src/phyp/phyp_driver.c (phypDomainDumpXML): Likewise. * src/openvz/openvz_conf.c (openvzLoadDomains): Likewise. * src/openvz/openvz_driver.c (openvzDomainDefineXML) (openvzDomainCreateXML, openvzDomainSetVcpusInternal): Likewise. * src/vbox/vbox_tmpl.c (vboxDomainDumpXML, vboxDomainDefineXML): Likewise. * src/xenapi/xenapi_driver.c (xenapiDomainDumpXML): Likewise. * src/xenapi/xenapi_utils.c (createVMRecordFromXml): Likewise. * src/esx/esx_vmx.c (esxVMX_ParseConfig, esxVMX_FormatConfig): Likewise. * src/qemu/qemu_conf.c (qemuBuildSmpArgStr) (qemuParseCommandLineSmp, qemuParseCommandLine): Likewise. * src/qemu/qemu_driver.c (qemudDomainHotplugVcpus): Likewise. * src/opennebula/one_conf.c (xmlOneTemplate): Likewise.
-
由 Eric Blake 提交于
Note - this wrapping is completely mechanical; the old API will function identically, since the new API validates that the exact same flags are provided by the old API. On a per-driver basis, it may make sense to have the old API pass a different set of flags, but that should be done in the per-driver patch that implements the full range of flag support in the new API. * src/esx/esx_driver.c (esxDomainSetVcpus, escDomainGetMaxVpcus): Move guts... (esxDomainSetVcpusFlags, esxDomainGetVcpusFlags): ...to new functions. (esxDriver): Trivially support the new API. * src/openvz/openvz_driver.c (openvzDomainSetVcpus) (openvzDomainSetVcpusFlags, openvzDomainGetMaxVcpus) (openvzDomainGetVcpusFlags, openvzDriver): Likewise. * src/phyp/phyp_driver.c (phypDomainSetCPU) (phypDomainSetVcpusFlags, phypGetLparCPUMAX) (phypDomainGetVcpusFlags, phypDriver): Likewise. * src/qemu/qemu_driver.c (qemudDomainSetVcpus) (qemudDomainSetVcpusFlags, qemudDomainGetMaxVcpus) (qemudDomainGetVcpusFlags, qemuDriver): Likewise. * src/test/test_driver.c (testSetVcpus, testDomainSetVcpusFlags) (testDomainGetMaxVcpus, testDomainGetVcpusFlags, testDriver): Likewise. * src/vbox/vbox_tmpl.c (vboxDomainSetVcpus) (vboxDomainSetVcpusFlags, virDomainGetMaxVcpus) (virDomainGetVcpusFlags, virDriver): Likewise. * src/xen/xen_driver.c (xenUnifiedDomainSetVcpus) (xenUnifiedDomainSetVcpusFlags, xenUnifiedDomainGetMaxVcpus) (xenUnifiedDomainGetVcpusFlags, xenUnifiedDriver): Likewise. * src/xenapi/xenapi_driver.c (xenapiDomainSetVcpus) (xenapiDomainSetVcpusFlags, xenapiDomainGetMaxVcpus) (xenapiDomainGetVcpusFlags, xenapiDriver): Likewise. (xenapiError): New helper macro.
-
由 Eric Blake 提交于
* src/driver.h (virDrvDomainSetVcpusFlags) (virDrvDomainGetVcpusFlags): New typedefs. (_virDriver): New callback members. * src/esx/esx_driver.c (esxDriver): Add stub for driver. * src/lxc/lxc_driver.c (lxcDriver): Likewise. * src/opennebula/one_driver.c (oneDriver): Likewise. * src/openvz/openvz_driver.c (openvzDriver): Likewise. * src/phyp/phyp_driver.c (phypDriver): Likewise. * src/qemu/qemu_driver.c (qemuDriver): Likewise. * src/remote/remote_driver.c (remote_driver): Likewise. * src/test/test_driver.c (testDriver): Likewise. * src/uml/uml_driver.c (umlDriver): Likewise. * src/vbox/vbox_tmpl.c (Driver): Likewise. * src/xen/xen_driver.c (xenUnifiedDriver): Likewise. * src/xenapi/xenapi_driver.c (xenapiDriver): Likewise.
-
- 19 10月, 2010 2 次提交
-
-
由 Dan Kenigsberg 提交于
Over root-squashing nfs, when virFileOperation() is called as uid==0, it may fail with EACCES, but also with EPERM, due to virFileOperationNoFork()'s failed attemp to chown a writable file. qemudDomainSaveFlag() should expect this case, too.
-
由 Dan Kenigsberg 提交于
qemudOpenAsUID is intended to open a file with the credentials of a specified uid. Current implementation fails if the file is accessible to one of uid's groups but not owned by uid. This patch replaces the supplementary group list that the child process inherited from libvirtd with the default group list of uid.
-
- 15 10月, 2010 1 次提交
-
-
由 Laine Stump 提交于
-
- 14 10月, 2010 1 次提交
-
-
由 Jiri Denemark 提交于
Explicitly raising a nice error in the case user tries to migrate a guest with assigned host devices is much better than waiting for a mysterious error with no clue for the reason.
-
- 13 10月, 2010 6 次提交
-
-
由 Stefan Berger 提交于
This is from a bug report and conversation on IRC where Soren reported that while a filter update is occurring on one or more VMs (due to a rule having been edited for example), a deadlock can occur when a VM referencing a filter is started. The problem is caused by the two locking sequences of qemu driver, qemu domain, filter # for the VM start operation filter, qemu_driver, qemu_domain # for the filter update operation that obviously don't lock in the same order. The problem is the 2nd lock sequence. Here the qemu_driver lock is being grabbed in qemu_driver:qemudVMFilterRebuild() The following solution is based on the idea of trying to re-arrange the 2nd sequence of locks as follows: qemu_driver, filter, qemu_driver, qemu_domain and making the qemu driver recursively lockable so that a second lock can occur, this would then lead to the following net-locking sequence qemu_driver, filter, qemu_domain where the 2nd qemu_driver lock has been ( logically ) eliminated. The 2nd part of the idea is that the sequence of locks (filter, qemu_domain) and (qemu_domain, filter) becomes interchangeable if all code paths where filter AND qemu_domain are locked have a preceding qemu_domain lock that basically blocks their concurrent execution So, the following code paths exist towards qemu_driver:qemudVMFilterRebuild where we now want to put a qemu_driver lock in front of the filter lock. -> nwfilterUndefine() [ locks the filter ] -> virNWFilterTestUnassignDef() -> virNWFilterTriggerVMFilterRebuild() -> qemudVMFilterRebuild() -> nwfilterDefine() -> virNWFilterPoolAssignDef() [ locks the filter ] -> virNWFilterTriggerVMFilterRebuild() -> qemudVMFilterRebuild() -> nwfilterDriverReload() -> virNWFilterPoolLoadAllConfigs() ->virNWFilterPoolObjLoad() -> virNWFilterPoolAssignDef() [ locks the filter ] -> virNWFilterTriggerVMFilterRebuild() -> qemudVMFilterRebuild() -> nwfilterDriverStartup() -> virNWFilterPoolLoadAllConfigs() ->virNWFilterPoolObjLoad() -> virNWFilterPoolAssignDef() [ locks the filter ] -> virNWFilterTriggerVMFilterRebuild() -> qemudVMFilterRebuild() Qemu is not the only driver using the nwfilter driver, but also the UML driver calls into it. Therefore qemuVMFilterRebuild() can be exchanged with umlVMFilterRebuild() along with the driver lock of qemu_driver that can now be a uml_driver. Further, since UML and Qemu domains can be running on the same machine, the triggering of a rebuild of the filter can touch both types of drivers and their domains. In the patch below I am now extending each nwfilter callback driver with functions for locking and unlocking the (VM) driver (UML, QEMU) and introduce new functions for locking all registered callback drivers and unlocking them. Then I am distributing the lock-all-cbdrivers/unlock-all-cbdrivers call into the above call paths. The last shown callpath starting with nwfilterDriverStart() is problematic since it is initialize before the Qemu and UML drives are and thus a lock in the path would result in a NULL pointer attempted to be locked -- the call to virNWFilterTriggerVMFilterRebuild() is never called, so we never lock either the qemu_driver or the uml_driver in that path. Therefore, only the first 3 paths now receive calls to lock and unlock all callback drivers. Now that the locks are distributed where it matters I can remove the qemu_driver and uml_driver lock from qemudVMFilterRebuild() and umlVMFilterRebuild() and not requiring the recursive locks. For now I want to put this out as an RFC patch. I have tested it by 'stretching' the critical section after the define/undefine functions each lock the filter so I can (easily) concurrently execute another VM operation (suspend,start). That code is in this patch and if you want you can de-activate it. It seems to work ok and operations are being blocked while the update is being done. I still also want to verify the other assumption above that locking filter and qemu_domain always has a preceding qemu_driver lock.
-
由 Nikunj A. Dadhania 提交于
QEmu startup will pick up the memory tunables specified in the domain configuration file
-
由 Nikunj A. Dadhania 提交于
Driver interface for getting memory parameters, eg. hard_limit, soft_limit and swap_hard_limit based on cgroup support
-
由 Nikunj A. Dadhania 提交于
Driver interface for setting memory hard_limit, soft_limit and swap hard_limit based on cgroup support
-
由 Nikunj A. Dadhania 提交于
Adding parsing code for memory tunables in the domain xml file also change the internal define structures used for domain memory informations Adds a new specific test
-
由 Nikunj A. Dadhania 提交于
Public api to set/get memory tunables supported by the hypervisors. dv: * some cleanups in libvirt.c * adding extra checks in libvirt.c new entry points v4: * Move exporting public API to this patch * Add unsigned int flags to the public api for future extensions v3: * Add domainGetMemoryParamters and NULL in all the driver interface v2: * Initialize domainSetMemoryParameters to NULL in all the driver interface structure.
-
- 25 8月, 2010 1 次提交
-
-
由 Soren Hansen 提交于
Other drivers will need this same functionality, so move it to up to conf/domain_conf.c and give it a more general name. Signed-off-by: NSoren Hansen <soren@linux2go.dk>
-
- 20 8月, 2010 1 次提交
-
-
由 Eric Blake 提交于
* src/qemu/qemu_driver.c (qemudGetProcessInfo): Clean up. * src/uml/uml_driver.c (umlGetProcessInfo): Likewise. * src/xen/sexpr.c (_string2sexpr): Likewise.
-
- 18 8月, 2010 1 次提交
-
-
由 Chris Lalancette 提交于
The current version of the qemu managed save implementation is subject to a race where the domain shuts down between the time that we start the command and the time that we actually try to do the save. Close this race by making qemuDomainSaveFlags() expect both the driver and the passed-in vm object to be locked before executing. Signed-off-by: NChris Lalancette <clalance@redhat.com>
-
- 17 8月, 2010 4 次提交
-
-
由 Jiri Denemark 提交于
This also makes the message consistent with the message used in error path of qemudDomainAttachHostPciDevice.
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
When reconnecting to existing VMs, we re-reserved only those PCI addresses which were explicitly mentioned in domain XML. Since some addresses are always reserved (e.g., 0:0:0 and 0:0:1), we need to handle those too. Also all this should only be done if device flag is supported by qemu.
-
由 Stefan Berger 提交于
In this patch I am extending and fixing the nwfilter module's reload support to stop all ongoing threads (for learning IP addresses of interfaces) and rebuild the filtering rules of all interfaces of all VMs when libvirt is started. Now libvirtd rebuilds the filters upon the SIGHUP signal and libvirtd restart. About the patch: The nwfilter functions require a virConnectPtr. Therefore I am opening a connection in qemudStartup, which later on needs to be closed outside where the driver lock is held since otherwise it ends up in a deadlock due to virConnectClose() trying to lock the driver as well. I have tested this now for a while with several machines running and needing the IP address learner thread(s). The rebuilding of the firewall rules seems to work fine following libvirtd restart or a SIGHUP. Also the termination of libvirtd worked fine.
-
- 13 8月, 2010 3 次提交
-
-
由 Chris Lalancette 提交于
Since the qemu process is running as qemu:qemu, it can't actually look at the unix socket in /var/run/libvirt/qemu which is owned by root and has permission 700. Move the unix socket to /var/lib/libvirt/qemu, which is already owned by qemu:qemu. Thanks to Justin Clift for test this out for me. Signed-off-by: NChris Lalancette <clalance@redhat.com>
-
由 Chris Lalancette 提交于
The problem is that on the source of the migration, libvirtd is responsible for creating the unix socket over which the data will flow. Since libvirtd is running as root, this file will be created as root. When the qemu process running as qemu:qemu goes to access the unix file to write data to it, it will get permission denied and fail. Make sure to change the owner of the unix file to qemu:qemu. Thanks to Justin Clift for testing this patch out for me. Signed-off-by: NChris Lalancette <clalance@redhat.com>
-
由 Daniel Veillard 提交于
Basically a followup of the previous patch about balloon desactivation if desactivated, to not ask for balloon information to qemu as we will just get an error back. This can make a huge difference in the time needed for domain information or list when a machine is loaded, and balloon has been desactivated in the guests. * src/qemu/qemu_driver.c: do not get the balloon info if the balloon suppor is disabled
-
- 10 8月, 2010 1 次提交
-
-
由 Jiri Denemark 提交于
device_del command is not synchronous for PCI devices, it merely asks the guest to release the device and returns. If the host wants to use that device before the guest actually releases it, we are in big trouble. To avoid this, we already added a loop which waits up to 10 seconds until the device is actually released before we do anything else with that device. But we only added this loop for managed PCI devices before we try reattach them back to the host. However, we need to wait even for non-managed devices. We don't reattach them automatically, but we still want to prevent the host from using it. This was revealed thanks to sVirt: when we relabel sysfs files corresponding to the PCI device before the guest finished releasing the device, qemu is no longer allowed to access those files and if it wants (as a result of guest's request) to write anything to them, it just exits, which kills the guest. This is not a proper fix and needs some further work both on libvirt and qemu side in the future.
-
- 03 8月, 2010 1 次提交
-
-
由 Eric Blake 提交于
Spotted by clang. Regression introduced in commit e72cc3c1. * src/qemu/qemu_driver.c (qemuConnectMonitor): Don't lose error status.
-
- 31 7月, 2010 1 次提交
-
-
由 Eric Blake 提交于
Spotted by clang. * src/qemu/qemu_monitor.c (qemuMonitorClose): Kill dead store. * src/qemu/qemu_driver.c (qemudDomainSaveImageStartVM): Likewise.
-
- 29 7月, 2010 3 次提交
-
-
由 Chris Lalancette 提交于
If detecting the FLR flag of a pci device fails, then we could run into the situation of trying to close a file descriptor twice, once in pciInitDevice() and once in pciFreeDevice(). Fix that by removing the pciCloseConfig() in pciInitDevice() and just letting pciFreeDevice() handle it. Thanks to Chris Wright for pointing out this problem. While we are at it, fix an error check. While it would actually work as-is (since success returns 0), it's still more clear to check for < 0 (as the rest of the code does). Signed-off-by: NChris Lalancette <clalance@redhat.com>
-
由 Cole Robinson 提交于
Enable specifying a virtio console device with: <console type='pty'> <target type='virtio'/> </console>
-
由 Cole Robinson 提交于
There is actually a difference between the character device type (serial, parallel, channel, ...) and the target type (virtio, guestfwd). Currently they are awkwardly conflated. Start to pull them apart by renaming targetType -> deviceType. This is an entirely mechanical change. Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
- 28 7月, 2010 1 次提交
-
-
由 Chris Lalancette 提交于
Signed-off-by: NChris Lalancette <clalance@redhat.com>
-
- 27 7月, 2010 4 次提交
-
-
由 Chris Wright 提交于
When doing a PCI secondary bus reset, we must be sure that there are no active devices on the same bus segment. The active device tracking is designed to only track host devices that are active in use by guests. This ignores host devices that are actively in use by the host. So the current logic will reset host devices. Switch this logic around and allow sbus reset when we are assigning all devices behind a bridge to the same guest at guest startup or as a result of a single attach-device command. * src/util/pci.h: change signature of pciResetDevice to add an inactive devices list * src/qemu/qemu_driver.c src/xen/xen_driver.c: use (or not) the new functionality of pciResetDevice() depending on the place of use * src/util/pci.c: implement the interface and logic changes
-
由 Chris Wright 提交于
- src/qemu/qemu_driver.c: Eliminate code duplication by using the new helpers qemuPrepareHostdevPCIDevices and qemuDomainReAttachHostdevDevices. This reduces the number of open coded calls to pciResetDevice.
-
由 Chris Wright 提交于
- src/qemu/qemu_driver.c: These new helpers take hostdev list and count directly rather than getting them indirectly from domain definition. This will allow reuse for the attach-device case.
-
由 Chris Wright 提交于
- src/qemu/qemu_driver.c: Update qemuGetPciHostDeviceList to take a hostdev list and count directly, rather than getting this indirectly from domain definition. This will allow reuse for the attach-device case.
-