- 18 9月, 2014 7 次提交
-
-
由 Peter Krempa 提交于
Live definition was used to look up the disk index while persistent one was indexed leading to a crash in qemuDomainGetBlockIoTune. Use the correct def and report a nice error. Unfortunately it's accessible via read-only connection, though it can only crash libvirtd in the cases where the guest is hot-plugging disks without reflecting those changes to the persistent definition. So avoiding hotplug, or doing hotplug where persistent is always modified alongside live definition, will avoid the out-of-bounds access. Introduced in: eca96694a (v0.9.8) Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1140724Reported-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Francesco Romani 提交于
This patch implements the VIR_DOMAIN_STATS_BLOCK group of statistics. To do so, a helper function to get the block stats of all the disks of a domain is added. Signed-off-by: NFrancesco Romani <fromani@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Francesco Romani 提交于
This patch implements the VIR_DOMAIN_STATS_INTERFACE group of statistics. Signed-off-by: NFrancesco Romani <fromani@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Francesco Romani 提交于
This patch implements the VIR_DOMAIN_STATS_VCPU group of statistics. To do so, this patch also extracts a helper to gather the vCPU information. Signed-off-by: NFrancesco Romani <fromani@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Francesco Romani 提交于
This patch implements the VIR_DOMAIN_STATS_BALLOON group of statistics. Signed-off-by: NFrancesco Romani <fromani@redhat.com>
-
由 Francesco Romani 提交于
This patch implements the VIR_DOMAIN_STATS_CPU_TOTAL group of statistics. Signed-off-by: NFrancesco Romani <fromani@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Francesco Romani 提交于
Future patches which will implement more bulk stats groups for QEMU will need to access the connection object. To accommodate that, a few changes are needed: * enrich internal prototype to pass qemu driver object * add per-group flag to mark if one collector needs monitor access or not * If at least one collector of the requested stats needs monitor access we must start a query job for each domain. The specific collectors will run nested monitor jobs inside that. * If the job can't be acquired we pass flags to the collector so specific collectors that need monitor access can be skipped in order to gather as much data as is possible. Signed-off-by: NFrancesco Romani <fromani@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
- 17 9月, 2014 2 次提交
-
-
由 Michal Privoznik 提交于
Check to see if the UEFI binary mentioned in qemu.conf actually exists, and if so expose it in domcapabilities like <loader ...> <value>/path/to/ovmf</value> </loader> We introduce some generic domcaps infrastructure for handling a dynamic list of string values, it may be of use for future bits. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 16 9月, 2014 3 次提交
-
-
由 Peter Krempa 提交于
Commit b606bbb4 broke reporting of errors when setting of guest time fails via the guest agent as the return value is not checked and later overwritten by the return value qemuMonitorRTCResetReinjection(); Fix this by checking the return value before resetting the RTC reinjection. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1142294
-
由 John Ferlan 提交于
Found by inspection of the "i+1" change. IOThreads are numbered 1..n thus the virCgroupNewIOThread needs to create a 1..n value not 0 based.
-
由 John Ferlan 提交于
Modify qemuProcessStart() in order to allowing setting affinity to specific CPU's for IOThreads. The process followed is similar to that for the vCPU's. This involves adding a function to fetch the IOThread id's via qemuMonitorGetIOThreads() and adding them to iothreadpids[] list. Then making sure all the cgroup data has been properly set up and finally assigning affinity.
-
- 12 9月, 2014 6 次提交
-
-
由 Eric Blake 提交于
We stupidly modeled block job bandwidth after migration bandwidth, which in turn was an 'unsigned long' and therefore subject to 32-bit vs. 64-bit interpretations. To work around the fact that 10-gigabit interfaces are possible but don't fit within 32 bits, the original interface took the number scaled as MiB/sec. But this scaling is rather coarse, and it might be nice to tune bandwidth finer than in megabyte chunks. Several of the block job calls that can set speed are fed through a common interface, so it was easier to adjust them all at once. Note that there is intentionally no flag for the new virDomainBlockCopy; there, since the API already uses a 64-bit type always, instead of a possible 32-bit type, and is brand new, it was easier to just avoid scaling issues. As with the previous patch that adjusted the query side (commit db33cc24), omitting the new flag preserves old behavior, and the documentation now mentions limits of what happens when a 32-bit machine is on either client or server side. * include/libvirt/libvirt.h.in (virDomainBlockJobSetSpeedFlags) (virDomainBlockPullFlags) (VIR_DOMAIN_BLOCK_REBASE_BANDWIDTH_BYTES) (VIR_DOMAIN_BLOCK_COMMIT_BANDWIDTH_BYTES): New enums. * src/libvirt.c (virDomainBlockJobSetSpeed, virDomainBlockPull) (virDomainBlockRebase, virDomainBlockCommit): Document them. * src/qemu/qemu_driver.c (qemuDomainBlockJobSetSpeed) (qemuDomainBlockPull, qemuDomainBlockRebase) (qemuDomainBlockCommit, qemuDomainBlockJobImpl): Support new flag. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Upstream qemu 1.4 added some drive-mirror tunables not present when it was first introduced in 1.3. Management apps may want to set these in some cases (for example, without tuning granularity down to sector size, a copy may end up occupying more bytes than the original because an entire cluster is copied even when only a sector within the cluster is dirty, although tuning it down results in more CPU time to do the copy). I haven't personally needed to use the parameters, but since they exist, and since the new API supports virTypedParams, we might as well expose them. Since the tuning parameters aren't often used, and omitted from the QMP command when unspecified, I think it is safe to rely on qemu 1.3 to issue an error about them being unsupported, rather than trying to create a new capability bit in libvirt. Meanwhile, all versions of qemu from 1.4 to 2.1 have a bug where a bad granularity (such as non-power-of-2) gives a poor message: error: internal error: unable to execute QEMU command 'drive-mirror': Invalid parameter 'drive-virtio-disk0' because of abuse of QERR_INVALID_PARAMETER (which is supposed to name the parameter that was given a bad value, rather than the value passed to some other parameter). I don't see that a capability check will help, so we'll just live with it (and it has since been improved in upstream qemu). * src/qemu/qemu_monitor.h (qemuMonitorDriveMirror): Add parameters. * src/qemu/qemu_monitor.c (qemuMonitorDriveMirror): Likewise. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONDriveMirror): Likewise. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONDriveMirror): Likewise. * src/qemu/qemu_driver.c (qemuDomainBlockCopyCommon): Likewise. (qemuDomainBlockRebase, qemuDomainBlockCopy): Adjust callers. * src/qemu/qemu_migration.c (qemuMigrationDriveMirror): Likewise. * tests/qemumonitorjsontest.c (qemuMonitorJSONDriveMirror): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
The hard part of managing the disk copy is already coded; all this had to do was convert the XML and virTypedParameters into the internal representation. With this patch, all blockcopy operations that used the old API should also work via the new API. Additional extensions, such as supporting the granularity tunable or a network rather than file destination, will be added as later patches. * src/qemu/qemu_driver.c (qemuDomainBlockCopy): New function. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
In order to implement the new virDomainBlockCopy, the existing block copy internal implementation needs to be adjusted. The new function will parse XML into a storage source, and parse typed parameters into integers, then call into the same common backend. For now, it's easier to keep the same implementation limits that only local file destinations are suported, but now the check needs to be explicit. Similar to qemuDomainBlockJobImpl consuming 'vm', this code also consumes the caller's 'mirror' description of the destination. * src/qemu/qemu_driver.c (qemuDomainBlockCopy): Rename... (qemuDomainBlockCopyCommon): ...and adjust parameters. (qemuDomainBlockRebase): Adjust caller. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Michal Privoznik 提交于
When a domain is undefined, there are options to remove it's managed save state or snapshots. However, there's another file that libvirt creates per domain: the NVRAM variable store file. Make sure that the file is not left behind if the domain is undefined. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrange 提交于
Test suites using the port allocator don't want to have different behaviour depending on whether a port is in use on the host. Add a VIR_PORT_ALLOCATOR_SKIP_BIND_CHECK which test suites can use to skip the bind() test. The port allocator will thus only track ports in use by the test suite process itself. This is fine when using the port allocator to generate guest configs which won't actually be launched Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
- 11 9月, 2014 4 次提交
-
-
由 John Ferlan 提交于
Coverity notes that if the virConnectListAllDomains returns a negative value then the loop at the cleanup label that ends on numDomains will have issues. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
If we jump to cleanup before allocating the 'result', then the call to virBlkioDeviceArrayClear will deref result causing a problem. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Coverity complains that checking for !domlist after setting doms = domlist and making a deref of doms just above It seems the call in question was intended to me made in the case that 'doms' was passed in and not when the virDomainObjListExport() call allocated domlist and already called virConnectGetAllDomainStatsCheckACL(). Thus rather than check for !domlist - check that "doms != domlist" in order to avoid the Coverity message. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
In qemuDomainSetBlkioParameters(), Coverity points out that the calls to qemuDomainParseBlkioDeviceStr() are slightly different and points out there may be a cut-n-paste error. In the first call (AFFECT_LIVE), the second parameter is "param->field"; however, for the second call (AFFECT_CONFIG), the second parameter is "params->field". It seems the "param->field" is correct especially since each path as a setting of "param" to "¶ms[i]". Furthermore, there were a few more instances of using "params[i]" instead of "param->" which I cleaned up. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 10 9月, 2014 4 次提交
-
-
由 Peter Krempa 提交于
Check if the VM is alive after we possibly called into monitor to reset the guest.
-
由 Peter Krempa 提交于
Also drop a comment with obvious content.
-
由 Jiri Denemark 提交于
virDomainGetJobStats gains new VIR_DOMAIN_JOB_STATS_COMPLETED flag that can be used to fetch statistics of a completed job rather than a currently running job. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Job statistics data were tracked in several structures and variables. Let's make a new qemuDomainJobInfo structure which can be used as a single source of statistics data as a preparation for storing data about completed a job. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 08 9月, 2014 5 次提交
-
-
由 Peter Krempa 提交于
Return failure right away when the domain object can't be looked up instead of jumping to cleanup. This allows to remove the condition before unlocking the domain object.
-
由 Peter Krempa 提交于
-
由 Jincheng Miao 提交于
The code would lookup the snapshot object before acquiring the job. This could lead to a crash as one thread could delete the snapshot object, while a second thread already had the reference. Signed-off-by: NJincheng Miao <jmiao@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
Creating snapshots modifies the domain state. Currently we wouldn't enter the job for certain operations although they would modify the state. Refactor job handling so that everything is covered by an async job.
-
由 Peter Krempa 提交于
Be consistent with naming of private defines. Also line up code correctly in few places where the macro is used.
-
- 06 9月, 2014 4 次提交
-
-
由 Eric Blake 提交于
To date, anyone performing a block copy and pivot ends up with the destination being treated as <disk type='file'>. While this works for data access for a block device, it has at least one noticeable shortcoming: virDomainGetBlockInfo() reports allocation differently for block devices visited as files (the size of the device) than for block devices visited as <disk type='block'> (the maximum sector used, as reported by qemu); and this difference is significant when trying to manage qcow2 format on block devices that can be grown as needed. Of course, the more powerful virDomainBlockCopy() API can already express the ability to set the <disk> type. But a new API can't be backported, while a new flag to an existing API can; and it is also rather inconvenient to have to resort to the full power of generating XML when just adding a flag to the older call will do the trick. So this patch enhances blockcopy to let the user flag when the resulting XML after the copy must list the device as type='block'. * include/libvirt/libvirt.h.in (VIR_DOMAIN_BLOCK_REBASE_COPY_DEV): New flag. * src/libvirt.c (virDomainBlockRebase): Document it. * tools/virsh-domain.c (opts_block_copy, blockJobImpl): Add --blockdev option. * tools/virsh.pod (blockcopy): Document it. * src/qemu/qemu_driver.c (qemuDomainBlockRebase): Allow new flag. (qemuDomainBlockCopy): Remember the flag, and make sure it is only used on actual block devices. * tests/qemuxml2argvdata/qemuxml2argv-disk-mirror.xml: Test it. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
While reviewing the new virDomainBlockCopy API, Peter Krempa pointed out that our existing design of using MiB/s for block job bandwidth is rather coarse, especially since qemu tracks it in bytes/s; so virDomainBlockCopy only accepts bytes/s. But once the new API is implemented for qemu, we will be in the situation where it is possible to set a value that cannot be accurately reflected back to the user, because the existing virDomainGetBlockJobInfo defaults to the coarser units. Fortunately, we have an escape hatch; and one that has already served us well in the past: we can use the flags argument to specify which scale to use (see virDomainBlockResize for prior art). This patch fixes the query side of the API; made easier by previous patches that split the query side out from the modification code. Later patches will address the virsh interface, as well retrofitting all other blockjob APIs to also accept a flag for toggling bandwidth units. * include/libvirt/libvirt.h.in (_virDomainBlockJobInfo) (VIR_DOMAIN_BLOCK_COPY_BANDWIDTH): Document sizing issues. (virDomainBlockJobInfoFlags): New enum. * src/libvirt.c (virDomainGetBlockJobInfo): Document new flag. * src/qemu/qemu_monitor.h (qemuMonitorBlockJobInfo): Add parameter. * src/qemu/qemu_monitor.c (qemuMonitorBlockJobInfo): Likewise. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockJobInfo): Likewise. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockJobInfo) (qemuMonitorJSONGetBlockJobInfoOne): Likewise. Don't scale here. * src/qemu/qemu_migration.c (qemuMigrationDriveMirror): Update callers. * src/qemu/qemu_driver.c (qemuDomainBlockPivot) (qemuDomainBlockJobImpl): Likewise. (qemuDomainGetBlockJobInfo): Likewise, and support new flag. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
qemu treats blockjob bandwidth as a 64-bit number, in the units of bytes/second. But we stupidly modeled block job bandwidth after migration bandwidth, which in turn was an 'unsigned long' and therefore subject to 32-bit vs. 64-bit interpretations, and with a scale of MiB/s. Our code already has to convert between the two scales, and report overflow as appropriate; although this conversion currently lives in the monitor code. In fact, our conversion code limited things to 63 bits, because we checked against LLONG_MAX and reject what would be negative bandwidth if treated as signed. On the bright side, our use of MiB/s means that even with a 32-bit unsigned long, we still have no problem representing a bandwidth of 2GiB/s, which is starting to be more feasible as 10-gigabit or even faster interfaces are used. And once you get past the physical speeds of existing interfaces, any larger bandwidth number behaves the same - effectively unlimited. But on the low side, the granularity of 1MiB/s tuning is rather coarse. So the new virDomainBlockJob API decided to go with a direct 64-bit bytes/sec number instead of the scaled number that prior blockjob APIs had used. But there is no point in rounding this number to MiB/s just to scale it back to bytes/s for handing to qemu. In order to make future code sharing possible between the old virDomainBlockRebase and the new virDomainBlockCopy, this patch moves the scaling and overflow detection into the driver code. Several of the block job calls that can set speed are fed through a common interface, so it was easier to adjust all block jobs at once, for consistency. This patch is just code motion; there should be no user-visible change in behavior. * src/qemu/qemu_monitor.h (qemuMonitorBlockJob) (qemuMonitorBlockCommit, qemuMonitorDriveMirror): Change parameter type and scale. * src/qemu/qemu_monitor.c (qemuMonitorBlockJob) (qemuMonitorBlockCommit, qemuMonitorDriveMirror): Move scaling and overflow detection... * src/qemu/qemu_driver.c (qemuDomainBlockJobImpl) (qemuDomainBlockRebase, qemuDomainBlockCommit): ...here. (qemuDomainBlockCopy): Use bytes/sec. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Another layer of overly-multiplexed code that deserves to be split into obviously separate paths for query vs. modify. This continues the cleanup started in commit cefe0ba3. In the process, make some tweaks to simplify the logic when parsing the JSON reply. There should be no user-visible semantic changes. * src/qemu/qemu_monitor.h (qemuMonitorBlockJob): Drop parameter. (qemuMonitorBlockJobInfo): New prototype. (BLOCK_JOB_INFO): Drop enum. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockJob) (qemuMonitorJSONBlockJobInfo): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorBlockJob): Split... (qemuMonitorBlockJobInfo): ...into second function. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockJob): Move block info portions... (qemuMonitorJSONGetBlockJobInfo): ...here, and rename... (qemuMonitorJSONBlockJobInfo): ...and export. (qemuMonitorJSONGetBlockJobInfoOne): Alter return semantics. * src/qemu/qemu_driver.c (qemuDomainBlockPivot) (qemuDomainBlockJobImpl, qemuDomainGetBlockJobInfo): Adjust callers. * src/qemu/qemu_migration.c (qemuMigrationDriveMirror) (qemuMigrationCancelDriveMirror): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 05 9月, 2014 2 次提交
-
-
由 Eric Blake 提交于
The qemu implementation for virDomainGetBlockJobInfo() has a minor bug: it grabs the qemu job with intent to QEMU_JOB_MODIFY, which means it cannot be run in parallel with any other domain-modifying command. Among others, virDomainBlockJobAbort() is such a modifying command, and it defaults to being synchronous, and can wait as long as several seconds to ensure that the job has actually finished. Due to the job rules, this means a user cannot obtain status about the job during that timeframe, even though we know that some client management code exists which is using a polling loop on status to see when a job finishes. This bug has been present ever since blockpull support was first introduced (commit b976165c, v0.9.4 in Jul 2011), all because we stupidly tried to cram too much multiplexing through a single helper routine, but was made worse in 97c59b9c (v1.2.7) when BlockJobAbort was fixed to wait longer. It's time to disentangle some of the mess in qemuDomainBlockJobImpl, and in the process relax block job query to use QEMU_JOB_QUERY, since it can safely be used in parallel with any long running modify command. Technically, there is one case where getting block job info can modify domain XML - we do snooping to see if a 2-phase job has transitioned into the second phase, for an optimization in the case of old qemu that lacked an event for the transition. I claim this optimization is safe (the jobs are all about modifying qemu state, not necessarily xml state); but if it proves to be a problem, we could use the difference between the capabilities QEMU_CAPS_BLOCKJOB_{ASYNC,SYNC} to determine whether we even need snooping, and only request a modifying job in the case of older qemu. * src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Move info handling... (qemuDomainGetBlockJobInfo): ...here, and relax job type. (qemuDomainBlockJobAbort, qemuDomainBlockJobSetSpeed) (qemuDomainBlockRebase, qemuDomainBlockPull): Adjust callers. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
The existing virDomainBlockRebase code rejected the combination of _RELATIVE and _COPY flags, but only by accident. It makes sense to add support for the combination someday, at least for the case of _SHALLOW and not _REUSE_EXT; but to implement it, libvirt would have to pre-create the file with a relative backing name, and I'm not ready to code that in yet. Meanwhile, the code to forward on to the block copy code is getting longer, and reorganizing the function to have the block pull done early makes it easier to add even more block copy prep code. This patch should have no semantic difference other than the quality of the error message on the unsupported flag combination. Pre-patch: error: unsupported flags (0x10) in function qemuDomainBlockCopy Post-patch: error: argument unsupported: Relative backing during copy not supported yet * src/qemu/qemu_driver.c (qemuDomainBlockRebase): Reorder code, and improve error message of relative copy. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 04 9月, 2014 1 次提交
-
-
由 Eric Blake 提交于
I'm about to add a syntax check that enforces our documented HACKING style of always using matching {} on if-else statements. This commit focuses on the qemu driver. * src/qemu/qemu_command.c (qemuParseISCSIString) (qemuParseCommandLineDisk, qemuParseCommandLine) (qemuBuildSmpArgStr, qemuBuildCommandLine) (qemuParseCommandLineDisk, qemuParseCommandLineSmp): Correct use of {}. * src/qemu/qemu_capabilities.c (virQEMUCapsProbeCPUModels): Likewise. * src/qemu/qemu_driver.c (qemuDomainCoreDumpWithFormat) (qemuDomainRestoreFlags, qemuDomainGetInfo) (qemuDomainMergeBlkioDevice): Likewise. * src/qemu/qemu_hotplug.c (qemuDomainAttachNetDevice): Likewise. * src/qemu/qemu_monitor_text.c (qemuMonitorTextCreateSnapshot) (qemuMonitorTextLoadSnapshot, qemuMonitorTextDeleteSnapshot): Likewise. * src/qemu/qemu_process.c (qemuProcessStop): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 29 8月, 2014 1 次提交
-
-
由 John Ferlan 提交于
In qemuDomainSnapshotCreateDiskActive() if we jumped to cleanup from a failed actions = virJSONValueNewArray(), then 'cfg' would be NULL. So just return -1, which in turn removes the need for cleanup:
-
- 28 8月, 2014 1 次提交
-
-
由 Peter Krempa 提交于
Implement the API function for virDomainListGetStats and virConnectGetAllDomainStats in a modular way and implement the VIR_DOMAIN_STATS_STATE group of statistics. Although it may look like the function looks universal I'd rather not expose it to other drivers as the coming stats groups are likely to do qemu specific stuff to obtain the stats.
-