- 06 9月, 2019 24 次提交
-
-
由 Peter Krempa 提交于
When blockdev is used we always should use the blockdev mode for non-shared storage migration. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Use VIR_AUTOUNREF and remove the cleanup label. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Use VIR_AUTOFREE and remove the cleanup label. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Remove the cleanup label as it's empty. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Remove libvirt's support check for the target of an external snapshot to the blockdev code or qemu. This will potentially require a more complex cleanup but removes a level of hardcoded feature checks. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Use the code for creating or attaching new storage source in the snapshot code and switch to 'blockdev-snapshot' for creating the snapshot itself. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
With blockdev we'll be able to support protocols which are not supported by the storage backends in libvirt. This means that we have to be able to skip the creation and relative storage path reading if it's not supported. This will make it impossible to use relative backing for network protocols but that would be almost insane anyways. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
After we always assume support for the 'transaction' command (c358adc5) and follow-up cleanups qemuDomainSnapshotCreateSingleDiskActive lost its value. Move the code into appropriate helpers and remove the function. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Fix and unify the naming of external snapshot preparation functions. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Make qemuDomainSnapshotDiskDataCleanup cleanup section friendly by moving the error preservation code inside it. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
We changed to always saving the status and config XMLs to simplify code. After a few more refactors it's now possible to move it to the appropriate place and save the XMLs only on success again. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
When we take a snapshot we must properly remove our locking infrastructure locks. This was broken by commit 3817fa10 which attempted to properly track the readonly state for the image as the locking code was executed after this change. Since we forced the image which was locked as read-write to read-only prior to unlocking it the write lock was not dropped. Fix it by moving the locking code prior to modifying the readonly flag. https://bugzilla.redhat.com/show_bug.cgi?id=1745618Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
The code preparing data for creating/attaching the target image of block copy didn't use the correct reference to the existing backing chain in case when the copy should inherit it. This meant that qemu actually opened a second copy of the chain and operated on that. This would de-sync qemu from libvirt's view of node names. Luckily this is only hypothetical at this point since it happens only when -blockdev is enabled. Fix it by passing 'mirrorBacking' which has the proper data as the backing store when calling qemuBuildStorageSourceChainAttachPrepareBlockdevTop. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
In some cases we'll need to pass in a backing store which is not recorded as the backing store of @src. Export backingStore as variable and fix all callers to pass in the backing store. No semantic changes for now. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Pass backing store as an argument rather than extracting it locally and fix the callers. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Extract the loop and supporting infrastructure to the caller as only one of the two callers actually cares about looping and rename the helper to qemuBuildStorageSourceChainAttachPrepareBlockdevOne. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Pass in backing store explicitly to qemuBlockStorageSourceGetBlockdevProps and fix the callers. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Move all bits of the formatting of the 'backing' attribute to a single condition and make it use a single extracted copy of the backing store. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Since libvirt stores the backing chain into the XML in a nested way it is the prime possibility to hit libxml2's parsing limit of 256 layers. Introduce code which will crawl the backing chain and verify that it's not too deep. The maximum nesting is set to 200 layers so that there's still some space left for additional properties or nesting into snapshot XMLs. The check is applied to all disk use cases (starting, hotplug, media change) as well as block copy which changes image and snapshots. We simply report an error and refuse the operation. Without this check a restart of libvirtd would result in the status XML failing to be parsed and thus losing the VM. https://bugzilla.redhat.com/show_bug.cgi?id=1524278Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Use VIR_AUTOUNREF and get rid of the cleanup label. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
With blockdev we must issue the block_set_io_throttle QMP command to setup disk throttling as we currently can't do it with the 'throttle' layer. Unfortunately there's nothing we can do if it fails. https://bugzilla.redhat.com/show_bug.cgi?id=1733163Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Get rid of the last manually freed var. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Switch to using VIR_AUTOFREE and remove the cleanup label. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 05 9月, 2019 2 次提交
-
-
由 Jiri Denemark 提交于
When virtlogd is used to capture QEMU's stdout, qemuDomainObjTaint would always fail to write the message to the log file when QEMU is already running (i.e., outside qemuProcessLaunch). This can happen during device hotplug or by sending a custom QEMU guest agent command: warning : qemuDomainObjTaint:8757 : Domain id=9 name='blaf' uuid=9cfa4e37-2930-405b-bcb4-faac1829dad8 is tainted: custom-ga-command error : virLogHandlerDomainOpenLogFile:388 : Cannot open log file: '/var/log/libvirt/qemu/blaf.log': Device or resource busy error : virNetClientProgramDispatchError:172 : Cannot open log file: '/var/log/libvirt/qemu/blaf.log': Device or resource busy The fix is easy, we just need to use the right API for appending a message to QEMU log file instead of creating a new log context. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Cole Robinson 提交于
The attribute is named 'secret', not 'uuid' Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
- 04 9月, 2019 3 次提交
-
-
由 Peter Krempa 提交于
The offset is unsigned long long thus 'U' must be used. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
The 'u' modifier creates an unsigned int JSON attribute but the disk size and capacity fields are unsigned long long. If the size of the created image would be more than 4GiB we'd overflow and create sub-4G image. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jim Fehlig 提交于
The xenapi driver has not seen any development since its initial contribution 9 years ago. There have been no bug reports, no patches, and no queries about the driver on the developer or user mailing lists. Remove the driver from the libvirt sources. Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 03 9月, 2019 1 次提交
-
-
由 Peter Krempa 提交于
A specially crafted XML which would reference a non-existing disk but request the mirror to be registered with the blockjob could potentially make the parser dereference NULL. Fix it by moving the code slightly and just treat it as a wrong job XML. Found by Coverity. Reported-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 31 8月, 2019 5 次提交
-
-
由 Michal Privoznik 提交于
If a block job reaches failed/cancelled state, or is completed without pivot then we must remove security driver metadata associated to the backing chain so that we don't leave any metadata behind. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1741456Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Michal Privoznik 提交于
When a block job is completed, the security image metadata are moved to the new image. If this fails an warning is printed, but the message contains only domain name and lacks image paths. Put them both into the warning message. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Michal Privoznik 提交于
Currently, there are only a few lines of code so a separate function was not necessary, but this will change. So instead of putting all the new code under 'case QEMU_BLOCKJOB_TYPE_ACTIVE_COMMIT' create a separate function. Just like every other case has one. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Martin Kletzander 提交于
I guess the reason for that was the automatic interpretation/stringification of setfilecon_errno, but the code was not nice to read and it was a bit confusing. Also, the logs and error states get cleaner this way. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Jonathon Jongsma 提交于
Coverity noted that 'reply' can be NULL after calling qemuAgentCommand(). Avoid dereferencing reply in qemuAgentErrorComandUnsupported() in that case. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
-
- 30 8月, 2019 5 次提交
-
-
由 Pavel Hrdina 提交于
Introduced by commit <c854e0bd> that tried to fix an issue where we would fail to parse values from files. We cannot change the original pointer that is going to be used by VIR_AUTOFREE. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1747440Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Daniel Henrique Barboza 提交于
'virQEMUDriverConfigPtr cfg' is declared, initiated, but never used in virQEMUDriverCreateCapabilities(). Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com>
-
由 Michal Privoznik 提交于
There are some network file systems that do support XATTRs (e.g. gluster via FUSE). And they appear to support SELinux too. However, not really. Problem is, that it is impossible to change SELinux label of a file stored there, and yet we claim success (rightfully - hypervisor succeeds in opening the file). But this creates a problem for us - from XATTR bookkeeping POV, we haven't changed the label and thus if we remembered any label, we must roll back and remove it. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1740506Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Michal Privoznik 提交于
This function is no longer needed because after previous commits it's just an alias to virSecuritySELinuxSetFilecon. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Michal Privoznik 提交于
Now, that we don't need to remember if setting context is 'optional' (the argument only made virSecuritySELinuxSetFileconImpl() return a different success code), we can drop it from the _virSecuritySELinuxContextItem structure as we don't need to remember it in transactions. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
-