aboutsummaryrefslogtreecommitdiff
path: root/blockdev.c
AgeCommit message (Collapse)Author
2016-06-08blockdev: clean up error handling in do_open_trayColin Lord
Returns negative error codes and accompanying error messages in cases where the device has no tray or the tray is locked and isn't forced open. This extra information should result in better flexibility in functions that call do_open_tray. Suggested by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Colin Lord <clord@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-06-07blockdev-backup: Don't move target AioContext if it's attachedFam Zheng
If the BDS is attached, it will want to stay on the AioContext where its BlockBackend is. Don't call bdrv_set_aio_context in this case. Signed-off-by: Fam Zheng <famz@redhat.com> Message-id: 1463969978-24970-3-git-send-email-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-06-07blockdev-backup: Use bdrv_lookup_bs on targetFam Zheng
This allows backing up to a BDS that has not been attached to any BB. Signed-off-by: Fam Zheng <famz@redhat.com> Message-id: 1463969978-24970-2-git-send-email-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-05-25backup: Use BlockBackend for I/OKevin Wolf
This changes the backup block job to use the job's BlockBackend for performing its I/O. job->bs isn't used by the backup code any more afterwards. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-05-25mirror: Use BlockBackend for I/OKevin Wolf
This changes the mirror block job to use the job's BlockBackend for performing its I/O. job->bs isn't used by the mirroring code any more afterwards. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-05-25mirror: Allow target that already has a BlockBackendKevin Wolf
We had to forbid mirroring to a target BDS that already had a BB attached because the node swapping at job completion would add a second BB and we didn't support multiple BBs on a single BDS at the time. Now we do, so we can lift the restriction. As we allow additional BlockBackends for the target, we must expect other users to be sending requests. There may no requests be in flight during the graph modification, so we have to drain those users now. The core part of this patch is a revert of commit 40365552. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-05-25block: Drop errp parameter from blk_new()Max Reitz
blk_new() cannot fail so its Error ** parameter has become superfluous. Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-05-25block: Make bdrv_open() return a BDSMax Reitz
There are no callers to bdrv_open() or bdrv_open_inherit() left that pass a pointer to a non-NULL BDS pointer as the first argument of these functions, so we can finally drop that parameter and just make them return the new BDS. Generally, the following pattern is applied: bs = NULL; ret = bdrv_open(&bs, ..., &local_err); if (ret < 0) { error_propagate(errp, local_err); ... } by bs = bdrv_open(..., errp); if (!bs) { ret = -EINVAL; ... } Of course, there are only a few instances where the pattern is really pure. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-05-25block: Fix bdrv_next() memory leakKevin Wolf
The bdrv_next() users all leaked the BdrvNextIterator after completing the iteration. Simply changing bdrv_next() to free the iterator before returning NULL at the end of list doesn't work because some callers exit the loop before looking at all BDSes. This patch moves the BdrvNextIterator from the heap to the stack of the caller and switches to a bdrv_first()/bdrv_next() interface for initialising the iterator. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com>
2016-05-19block: clarify error message for qmp-ejectJohn Snow
If you use HMP's eject but the CDROM tray is locked, you may get a confusing error message informing you that the "tray isn't open." As this is the point of eject, we can do a little better and help clarify that the tray was locked and that it (might) open up later, so try again. It's not ideal, but it makes the semantics of the (legacy) eject command more understandable to end users when they try to use it. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-05-19block: Remove BlockDriverState.blkKevin Wolf
This patch removes the remaining users of bs->blk, which will allow us to have multiple BBs on top of a single BDS. In the meantime, all checks that are currently in place to prevent the user from creating such setups can be switched to bdrv_has_blk() instead of accessing BDS.blk. Future patches can allow them and e.g. enable users to mirror to a block device that already has a BlockBackend on it. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-05-19block: Avoid bs->blk in bdrv_next()Kevin Wolf
We need to introduce a separate BdrvNextIterator struct that can keep more state than just the current BDS in order to avoid using the bs->blk pointer. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-05-19Revert "block: Forbid I/O throttling on nodes with multiple parents for 2.6"Kevin Wolf
This reverts commit 76b223200ef4fb09dd87f0e213159795eb68e7a5. Now that I/O throttling is fully done on the BlockBackend level, there is no reason any more to block I/O throttling for nodes with multiple parents as the parents don't influence each other any more. Conflicts: block.c Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-05-19block: Decouple throttling from BlockDriverStateKevin Wolf
This moves the throttling related part of the BDS life cycle management to BlockBackend. The throttling group reference is now kept even when no medium is inserted. With this commit, throttling isn't disabled and then re-enabled any more during graph reconfiguration. This fixes the temporary breakage of I/O throttling when used with live snapshots or block jobs that manipulate the graph. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-05-19block: Move I/O throttling configuration functions to BlockBackendKevin Wolf
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-05-19block: Move throttling fields from BDS to BBKevin Wolf
This patch changes where the throttling state is stored (used to be the BlockDriverState, now it is the BlockBackend), but it doesn't actually make it a BB level feature yet. For example, throttling is still disabled when the BDS is detached from the BB. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-05-19block: Make sure throttled BDSes always have a BBKevin Wolf
It was already true in principle that a throttled BDS always has a BB attached, except that the order of operations while attaching or detaching a BDS to/from a BB wasn't careful enough. This commit breaks graph manipulations while I/O throttling is enabled. It would have been possible to keep things working with some temporary hacks, but quite cumbersome, so it's not worth the hassle. We'll fix things again in a minute. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-05-12qmp: add monitor command to add/remove a childWen Congyang
The new QMP command name is x-blockdev-change. It's just for adding/removing quorum's child now, and doesn't support all kinds of children, all kinds of operations, nor all block drivers. So it is experimental now. Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Changlong Xie <xiecl.fnst@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Message-id: 1462865799-19402-4-git-send-email-xiecl.fnst@cn.fujitsu.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2016-05-12block: Fix typo in commentWei Jiangang
s/imlement/implement/ Signed-off-by: Wei Jiangang <weijg.fnst@cn.fujitsu.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-04-05block: Forbid I/O throttling on nodes with multiple parents for 2.6Kevin Wolf
As the patches to move I/O throttling to BlockBackend didn't make it in time for the 2.6 release, but the release adds new ways of configuring VMs whose behaviour would change once the move is done, we need to outlaw such configurations temporarily. The problem exists whenever a BDS has more users than just its BB, for example it is used as a backing file for another node. (This wasn't possible in 2.5 yet as we introduced node references to specify a backing file only recently.) In these cases, the throttling would apply to these other users now, but after moving throttling to the BlockBackend the other users wouldn't be throttled any more. This patch prevents making new references to a throttled node as well as using monitor commands to throttle a node with multiple parents. Compared to 2.5 this changes behaviour in some corner cases where references were allowed before, like bs->file or Quorum children. It seems reasonable to assume that users didn't use I/O throttling on such low level nodes. With the upcoming move of throttling into BlockBackend, such configurations won't be possible anyway. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-04-05block: forbid x-blockdev-del from acting on DriveInfoPaolo Bonzini
Failing on -drive/drive_add created BlockBackends was a requirement for x-blockdev-del, but it sneaked through the patch review. Let's fix it now. Example: $ x86_64-softmmu/qemu-system-x86_64 -drive if=none,file=null-co://,id=null -qmp stdio >> {'execute':'qmp_capabilities'} << {"return": {}} >> {'execute':'x-blockdev-del','arguments':{'id':'null'}} << {"error": {"class": "GenericError", "desc": "Deleting block backend added with drive-add is not supported"}} And without a DriveInfo: >> { "execute": "blockdev-add", "arguments": { "options": { "driver":"null-co", "id":"null2"}}} << {"return": {}} >> {'execute':'x-blockdev-del','arguments':{'id':'null2'}} << {"return": {}} Suggested-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-03-30block: Remove BDRV_O_CACHE_WBKevin Wolf
The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-30block: Use bdrv_parse_cache_mode() in drive_init()Kevin Wolf
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-30block: Always set writeback mode in blk_new_open()Kevin Wolf
All callers of blk_new_open() either don't rely on the WCE bit set after blk_new_open() because they explicitly set it anyway, or they pass BDRV_O_CACHE_WB unconditionally. This patch changes blk_new_open() so that it always enables writeback mode and asserts that BDRV_O_CACHE_WB is clear. For those callers that used to pass BDRV_O_CACHE_WB unconditionally, the flag is removed now. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-30block: blockdev_init(): Call blk_set_enable_write_cache() explicitlyKevin Wolf
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-30block: Reject writethrough mode except at the rootKevin Wolf
Writethrough mode is going to become a BlockBackend feature rather than a BDS one, so forbid it in places where we won't be able to support it when the code finally matches the envisioned design. We only allowed setting the cache mode of non-root nodes after the 2.5 release, so we're still free to make this change. The target of block jobs is now always opened in a writeback mode because it doesn't have a BlockBackend attached. This makes more sense anyway because block jobs know when to flush. If the graph is modified on job completion, the original cache mode moves to the new root, so for the guest device writethough always stays enabled if it was configured this way. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-30block: Remove copy-on-read from bdrv_move_feature_fields()Kevin Wolf
Ever since we first introduced bdrv_append() in commit 8802d1fd ('qapi: Introduce blockdev-group-snapshot-sync command'), the copy-on-read flag was moved to the new top layer when taking a snapshot. The only problem is that it doesn't make a whole lot of sense. The use case for manually enabled CoR is to avoid reading data twice from a slow remote image, so we want to save it to a local overlay, say an ISO image accessed via HTTP to a local qcow2 overlay. When taking a snapshot, we end up with a backing chain like this: http <- local.qcow2 <- snap_overlay.qcow2 There is no point in doing CoR from local.qcow2 into snap_overlay.qcow2, we just want to keep copying data from the remote source into local.qcow2. The other use case of CoR is in the context of streaming, which isn't very interesting for bdrv_move_feature_fields() because op blockers prevent this combination. This patch makes the copy-on-read flag stay on the image for which it was originally set and prevents it from being propagated to the new overlay. It is no longer intended to move CoR to the BlockBackend level. In order for this to make sense, we also need to keep the respective image read-write. As a side effect of these changes, creating a live snapshot image (as opposed to using an existing externally created one) on top of a COR block device works now. It used to fail because it tried to open its backing file both read-only and with COR. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-30block: Remove bdrv_make_anon()Kevin Wolf
The call in hmp_drive_del() is dead code because blk_remove_bs() is called a few lines above. The only other remaining user is bdrv_delete(), which only abuses bdrv_make_anon() to remove it from the named nodes list. This path inlines the list entry removal into bdrv_delete() and removes bdrv_make_anon(). Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-22util: move declarations out of qemu-common.hVeronia Bahaa
Move declarations out of qemu-common.h for functions declared in utils/ files: e.g. include/qemu/path.h for utils/path.c. Move inline functions out of qemu-common.h and into new files (e.g. include/qemu/bcd.h) Signed-off-by: Veronia Bahaa <veroniabahaa@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-18qapi: Don't special-case simple union wrappersEric Blake
Simple unions were carrying a special case that hid their 'data' QMP member from the resulting C struct, via the hack method QAPISchemaObjectTypeVariant.simple_union_type(). But by using the work we started by unboxing flat union and alternate branches, coupled with the ability to visit the members of an implicit type, we can now expose the simple union's implicit type in qapi-types.h: | struct q_obj_ImageInfoSpecificQCow2_wrapper { | ImageInfoSpecificQCow2 *data; | }; | | struct q_obj_ImageInfoSpecificVmdk_wrapper { | ImageInfoSpecificVmdk *data; | }; ... | struct ImageInfoSpecific { | ImageInfoSpecificKind type; | union { /* union tag is @type */ | void *data; |- ImageInfoSpecificQCow2 *qcow2; |- ImageInfoSpecificVmdk *vmdk; |+ q_obj_ImageInfoSpecificQCow2_wrapper qcow2; |+ q_obj_ImageInfoSpecificVmdk_wrapper vmdk; | } u; | }; Doing this removes asymmetry between QAPI's QMP side and its C side (both sides now expose 'data'), and means that the treatment of a simple union as sugar for a flat union is now equivalent in both languages (previously the two approaches used a different layer of dereferencing, where the simple union could be converted to a flat union with equivalent C layout but different {} on the wire, or to an equivalent QMP wire form but with different C representation). Using the implicit type also lets us get rid of the simple_union_type() hack. Of course, now all clients of simple unions have to adjust from using su->u.member to using su->u.member.data; while this touches a number of files in the tree, some earlier cleanup patches helped minimize the change to the initialization of a temporary variable rather than every single member access. The generated qapi-visit.c code is also affected by the layout change: |@@ -7393,10 +7393,10 @@ void visit_type_ImageInfoSpecific_member | } | switch (obj->type) { | case IMAGE_INFO_SPECIFIC_KIND_QCOW2: |- visit_type_ImageInfoSpecificQCow2(v, "data", &obj->u.qcow2, &err); |+ visit_type_q_obj_ImageInfoSpecificQCow2_wrapper_members(v, &obj->u.qcow2, &err); | break; | case IMAGE_INFO_SPECIFIC_KIND_VMDK: |- visit_type_ImageInfoSpecificVmdk(v, "data", &obj->u.vmdk, &err); |+ visit_type_q_obj_ImageInfoSpecificVmdk_wrapper_members(v, &obj->u.vmdk, &err); | break; | default: | abort(); Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1458254921-17042-13-git-send-email-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-03-17block: Remove bdrv_states listMax Reitz
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-03-17block: Add bdrv_next_monitor_owned()Max Reitz
Add a function for iterating over all monitor-owned BlockDriverStates so the generic block layer can do so. Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-03-17blockdev: Remove blk_hide_on_behalf_of_hmp_drive_del()Max Reitz
We can basically inline it in hmp_drive_del(); monitor_remove_blk() is called already, so we just need to call bdrv_make_anon(), too. Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-03-17blockdev: Split monitor reference from BB creationMax Reitz
Before this patch, blk_new() automatically assigned a name to the new BlockBackend and considered it referenced by the monitor. This patch removes the implicit monitor_add_blk() call from blk_new() (and consequently the monitor_remove_blk() call from blk_delete(), too) and thus blk_new() (and related functions) no longer take a BB name argument. In fact, there is only a single point where blk_new()/blk_new_open() is called and the new BB is monitor-owned, and that is in blockdev_init(). Besides thus relieving us from having to invent names for all of the BBs we use in qemu-img, this fixes a bug where qemu cannot create a new image if there already is a monitor-owned BB named "image". If a BB and its BDS tree are created in a single operation, as of this patch the BDS tree will be created before the BB is given a name (whereas it was the other way around before). This results in minor change to the output of iotest 087, whose reference output is amended accordingly. Signed-off-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-03-17block: Use blk_{commit,flush}_all() consistentlyMax Reitz
Replace bdrv_commmit_all() and bdrv_flush_all() by their BlockBackend equivalents. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-03-17block: Fix memory leak in hmp_drive_add_node()Kevin Wolf
hmp_drive_add_node() leaked qdict in the error path when no node-name is specified. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2016-03-17block: Fix qemu_root_bds_opts.head initialisationKevin Wolf
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-14hmp: Extend drive_del to delete nodes without BBKevin Wolf
Now that we can use drive_add to create new nodes without a BB, we also want to be able to delete such nodes again. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-14hmp: 'drive_add -n' for creating a node without BBKevin Wolf
This patch adds an option to the drive_add HMP command to create only a BlockDriverState without a BlockBackend on top. The motivation for this is that libvirt needs to specify options to a migration target (specifically, detect-zeroes). drive-mirror doesn't allow specifying options, and the proper way to do this is to create the target BDS separately with blockdev-add (where you can specify options) and then use blockdev-mirror to that BDS. However, libvirt can't use blockdev-add as long as it is still experimental, and we're expecting that it will still take some time, so we need to resort to drive_add. The problem with drive_add is that so far it always created a BB, and BDSes with a BB can't be used as a mirroring target as long as we don't support multiple BBs per BDS - and while we're working towards that goal, it's another thing that will still take some time. So to achieve the goal, the simplest solution to provide the functionality now without adding one-off options to the mirror QMP commands is to extend drive_add to create nodes without BBs. Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-03-14block: Fix cache mode defaults in bds_tree_init()Kevin Wolf
Without setting explicit defaults in the options, blockdev-add without an ID ended up defaulting to writethrough. It should be writeback as documented. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-14block: Fix snapshot=on cache modesKevin Wolf
Since commit 91a097e, we end up with a somewhat weird cache mode configuration with snapshot=on: The commit broke the cache mode inheritance for the snapshot overlay so that it is opened as writethrough instead of unsafe now. The following bdrv_append() call to put it on top of the tree swaps the WCE flag with the snapshot's backing file (i.e. the originally given file), so what we eventually get is cache=writeback on the temporary overlay and cache=writethrough,cache.no-flush=on on the real image file. This patch changes things so that the temporary overlay gets cache=unsafe again like it used to, and the real images get whatever the user specified. This means that cache.direct is now respected even with snapshot=on, and in the case of committing changes, the final flush is no longer ignored except explicitly requested by the user. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-14blockdev: Snapshotting must not open second instance of old topKevin Wolf
Calling bdrv_img_create() with a size of -1 means that it determines the size automatically by opening the backing file. However, in the case of live snapshots, the backing file is already opened and we must avoid opening the same image twice at the same time. Apart from that, just getting the size from the already existing BDS is a lot less overhead than opening a new instance. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com>
2016-03-05qapi: Avoid use of 'data' member of QAPI unionsEric Blake
QAPI code generators currently create a 'void *data' member as part of the anonymous union embedded in the C struct corresponding to a QAPI union. However, directly assigning to this member of the union feels a bit fishy, when we can assign to another member of the struct instead. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1457021813-10704-9-git-send-email-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-02-22blockdev: unset inappropriate flags when changing mediumAlyssa Milburn
Most importantly, this removes BDRV_O_TEMPORARY, to avoid unlink()ing an image which replaces a snapshotted one. Signed-off-by: Alyssa Milburn <fuzzie@fuzzie.org> Message-id: 20160206133618.GA16635@li141-249.members.linode.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2016-02-22qapi: Add burst length parameters to block_set_io_throttleAlberto Garcia
This patch adds the new bps_*_max_length and iops_*_max_length parameters to the block_set_io_throttle command. Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-22throttle: Add command-line settings to define the burst periodsAlberto Garcia
This patch adds all the throttling.*-max-length command-line parameters to define the length of the burst periods. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-22throttle: Use throttle_config_init() to initialize ThrottleConfigAlberto Garcia
We can currently initialize ThrottleConfig by zeroing all its fields, but this will change with the new fields to define the length of the burst periods. This patch introduces a new throttle_config_init() function and uses it to replace all memset() calls that initialize ThrottleConfig directly. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-22throttle: Merge all functions that check the configuration into oneAlberto Garcia
There's no need to keep throttle_conflicting(), throttle_is_valid() and throttle_max_is_missing_limit() as separate functions, so this patch merges all three into one. As a consequence, check_throttle_config() becomes redundant and can be replaced with throttle_is_valid(). Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-22throttle: Make throttle_is_valid() set errpAlberto Garcia
The caller does not need to set it, and this will allow us to refactor this function later. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-22throttle: Make throttle_max_is_missing_limit() set errpAlberto Garcia
The caller does not need to set it, and this will allow us to refactor this function later. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>