- 09 12月, 2019 15 次提交
-
-
由 Daniel P. Berrangé 提交于
As part of a goal to eliminate the need to use virCapsPtr for anything other than the virConnectGetCapabilies() API impl, cache the host arch against the QEMU driver struct and use that field directly. In the tests we move virArchFromHost() globally in testutils.c so that every test runs with a fixed default architecture reported. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
The functions for converting migration typed parameters to QEMU migration parameters and back were only implemented for integer types. This patch adds support for string parameters. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Peter Krempa 提交于
With blockdev we need to refer to the nodename of the disk source image as the source argument for the blockdev-mirror operation while still keeping the old job name. With blockdev we must also persist the job in qemu. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Separate out allocation of the virStorageSource corresponding to the target NBD export of the migration. As part of the splitout we allocate the export name explicitly as that one must not change regardless whether blockdev is used or not to provide compatibility. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
The non-shared-storage migration tracks the storage source used explicitly in the migration data so we must allow for processing of the block job which has NULL mirror as the mirror will not be populated. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Now that the cleanup section does not exist remove the label. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
qemuMigrationSrcNBDCopyCancelOne uses the block job data structure but generated it's own job name rather than taking it from the block job data. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
With -blockdev we must use the nodename as the export but we must keep the name of the export as it was before to ensure compatiblity. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Declare the variable inside the loop with automatic clearing. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
qemuDomainBlockJobSetSpeed was not converted to get the job name from the block job data. This means that after enabling blockdev the API call would fail as we wouldn't use the appropriate name. https://bugzilla.redhat.com/show_bug.cgi?id=1780497Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Where appropriate replace the open coded call with the qemu wrapper which already reports the error. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Mention the argument used if the disk can't be located. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Jidong Xia 提交于
With this patch users can cold unplug some sound devices. use "virsh detach-device vm sound.xml --config" command. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NJidong Xia <xiajidong@cmss.chinamobile.com>
-
- 06 12月, 2019 2 次提交
-
-
由 Pavel Mores 提交于
This is a follow-up to patch series posted in https://www.redhat.com/archives/libvir-list/2019-November/msg01180.html It implements a suggestion made by Cole in https://www.redhat.com/archives/libvir-list/2019-November/msg01207.html and discussed in follow-up messages as there were no objections to the change. The aim is to make the code more readable by replacing nested branching with a flat structure. Signed-off-by: NPavel Mores <pmores@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
In v5.8.0-rc1~122 we've removed the only use of @safename in qemuMonitorTextLoadSnapshot(). What we are left with is an declared but not initialized variable that is passed to VIR_FREE(). Caught by libvirt-php test suite. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 05 12月, 2019 3 次提交
-
-
由 Michal Privoznik 提交于
In v5.9.0-370-g8fa0374c I've tried to fix a bug by removing some stale XATTRs in qemuProcessStop(). However, I forgot to do nothing when the VIR_QEMU_PROCESS_STOP_NO_RELABEL flag was specified. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
Until now we only really aborted migration via qemuDomainAbortJob. This will change with the upcoming addition of the backup job. Additionally there were a bunch of if statements checking various aspects of the current job. To make it more obvious convert qemuDomainAbortJob to use a switch statement and move the individual conditions to the appropriate job type. Every job type has now it's own case despite multiple job types just plainly cancelling the job for clarity and future extension. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Peter Krempa 提交于
Following patch will refactor qemuDomainAbortJob to use a per-job-type switch where we will need to abort a migration job in various branches. Save some code duplication by introducing a helper. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
- 03 12月, 2019 12 次提交
-
-
由 Peter Krempa 提交于
We clear some capabilities here so the lockouts need to be re-evaluated. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Peter Krempa 提交于
Blockdev is required to do incremental backups properly. Add a helper function for locking out capabilities and export it to allow re-doing the processing if a different code path modifies capabilities. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Peter Krempa 提交于
Checking whether a qemu capability set right before clearing it without any other logic doesn't make sense. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Peter Krempa 提交于
Do all post-processing of capabilities in qemuProcessPrepareQEMUCaps. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Peter Krempa 提交于
Move the post-processing of the QEMU_CAPS_CHARDEV_FD_PASS flag to the new function. The clearing of the capability is based on the presence of VIR_QEMU_PROCESS_START_STANDALONE so we must also pass in the process start flags. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Peter Krempa 提交于
Start aggregating all capability post-processing code in one place. The comment was modified while moving it as it was mentioning floppies which are no longer clearing the blockdev capability. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
The function is now used only in qemu_process.c so move it there and name it 'qemuProcessPrepareQEMUCaps' which is more appropriate to what it's doing. The reworded comment now mentions that it will also post-process the caps for VM startup. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
The redetection was originally added in 43c01d38 as a way to recover from libvirtd upgrade from the time when we didn't persist the qemu capabilities in the status XML. Also this the oldest supported qemu by more than two years. Even if somebody would have a running VM running at least qemu 1.5 with such an old libvirt we certainly wouldn't do the right thing by redetecting the capabilities and then trying to communicate with qemu. For now it will be the best to just stop considering this scenario any more and error out for such VM. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Commit c90fb5a8 added explicit use of the private copy of the qemu capabilities to various places. The change to qemuProcessInit was bogus though as at the point where we re-initiate the post parse callbacks priv->qemuCaps is still NULL as we clear it after shutdown of the VM and don't initiate it until a later point. Using the value from priv->qemuCaps might mislead readers of the code into thinking that something useful is being passed at that point so go with an explicit NULL instead. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
qemuDomainGetJobInfo didn't always reset the return data in @info. Thankfully this wouldn't be a problem as the RPC layer does it but we should do it anyways. Since we reset the struct we don't have to set the type to VIR_DOMAIN_JOB_NONE as the value is 0. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrangé 提交于
For managed save we can choose between various compression methods. I randomly tested the 'xz' program on a 8 GB guest and was surprised to have to wait > 50 minutes for it to finish compressing, with 'xz' burning 100% cpu for the entire time. Despite the impressive compression, this is completely useless in the real world as it is far too long to wait to save the VM. The 'xz' binary defaults to '-6' optimization level which aims for high compression, with moderate memory usage, at the expense of speed. This change switches it to use the '-3' optimization level which is documented as being the one that optimizes speed at expense of compression. Even with this, it will still outperform all the other options in terms of compression level. It is a little less than x4 faster than '-6' which means it starts to be a viable choice to use 'xz' for people who really want best compression. The test results on a 1 GB, fairly freshly booted VM are as follows format | save | restore size =======+=======+============= raw | 05s | 1s | 428 MB lzop | 05s | 3s | 160 MB gzip | 29s | 5s | 118 MB bz2 | 54s | 22s | 114 MB xz | 4m37s | 13s | 86 MB xz -3 | 1m20s | 12s | 95 MB Based on this we can say * For moderate compression with no noticable loss in speed => use lzop * For high compression with moderate loss in speed => use gzip * For best compression with significant loss in speed => use xz Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 02 12月, 2019 2 次提交
-
-
由 Peter Krempa 提交于
Commit 4b58fdf2 which enabled block copy also for network destinations needed to limit when the 'mirror' storage source is initialized in cases when we e.g. don't have an appropriate backend. Limiting it just to virStorageFileSupportsCreate is too restrictive as for example we can't precreate block devices and thus wouldn't initialize the 'mirror' but since it's a local source we'd try to examine it. This would fail since it wouldn't be initialized. Fix it by introducing a more granular check whether certain operations are supported and fix the check interlocks. https://bugzilla.redhat.com/show_bug.cgi?id=1778058Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
We tolerate image format detection during block copy in very specific circumstances, but the code didn't error out on failure of the format detection. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 29 11月, 2019 1 次提交
-
-
由 Peter Krempa 提交于
In commit 2ccb5335 I've refactored how we fill the typed parameters for domain statistics. The commit introduced a regression in the formating of stats for IOthreads by using the array index to label the entries as it's common for all other types of statistics rather than the iothread IDs used for iothreads. Since only the design of iothread deviates from the common approach used in all other statistic types this was not caught. https://bugzilla.redhat.com/show_bug.cgi?id=1778014Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 27 11月, 2019 5 次提交
-
-
由 Peter Krempa 提交于
Now that we have a separate job type which will not trigger normal code paths for terminating job we can remove the ad-hoc handling. This possibly fixes the issue of a broken job inheriting the disk and then finishing in which case we'd not detach the backing chain. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Peter Krempa 提交于
To better track jobs we couldn't parse let's introduce a new job type which will clarify semantics internally in few places. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Peter Krempa 提交于
We will need to clear per-job type data when we will be marking a blockjob as broken in the new way. Extract the code for future reuse. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Peter Krempa 提交于
Both failure to refresh and to dismiss the job are very unlikely but if they happen there's not much we can do about the blockjob. The concluded job handlers treat it as if the job failed if we don't update the state to 'QEMU_BLOCKJOB_STATE_COMPLETED' which is probably the safest thing to do here. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Peter Krempa 提交于
Otherwise it would get dropped later on as untracked despite us knowing about it. Additionally since we cancelled it we must wait to dismiss it which would not be possible if we unregister it. This also opened a window for a race condition since the job state change event of the just-cancelled job might be delivered prior to us unregistering the job in which case everything would work properly. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-