block: Rename raw_bsd to raw-format.c
Given that we have raw-win32.c and raw-posix.c, my initial guess at
raw_bsd.c was that it was for dealing with raw files using code
specific to the BSD operating system (beyond what raw-posix could
do). Not so - this name was chosen back in commit e1c66c6 to
distinguish that it was a BSD licensed file, in contrast to the
then-existing raw.c with an unclear and potentially unusable
license. But since it has been more than three years since the
rewrite, it's time to pick a more useful name for this file to
avoid this type of confusion to future contributors that don't know
the backstory, as none of our other files are named solely by the
license they use.
In reality, this file deals with the raw format, which is useful
with any number of protocols, while raw-{win32,posix} deal with
the file protocol (and in turn, that protocol is not limited to
use with the raw format). So rename raw_bsd to raw-format.c. We
could have also used the shorter name raw.c, except that collides
with the earlier use of that filename for a different license,
and it's better to be safe than risk license pollution.
The next patch will also rename raw-win32.c and raw-posix.c to
further distinguish the difference in roles.
It doesn't hurt that this gets rid of an underscore in the filename,
thereby making tab-completion on 'ra<TAB>' easier (now I don't have
to type the shift key, which slows things down :)
Suggested-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-12-02 20:48:53 +01:00
|
|
|
block-obj-y += raw-format.o qcow.o vdi.o vmdk.o cloop.o bochs.o vpc.o vvfat.o dmg.o
|
2012-05-22 13:44:39 +02:00
|
|
|
block-obj-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o qcow2-cache.o
|
|
|
|
|
block-obj-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o
|
|
|
|
|
block-obj-y += qed-check.o
|
2016-09-21 06:27:16 +02:00
|
|
|
block-obj-y += vhdx.o vhdx-endian.o vhdx-log.o
|
2015-07-01 19:10:35 +02:00
|
|
|
block-obj-y += quorum.o
|
2016-03-14 08:45:10 +01:00
|
|
|
block-obj-y += parallels.o blkdebug.o blkverify.o blkreplay.o
|
block: New BlockBackend
A block device consists of a frontend device model and a backend.
A block backend has a tree of block drivers doing the actual work.
The tree is managed by the block layer.
We currently use a single abstraction BlockDriverState both for tree
nodes and the backend as a whole. Drawbacks:
* Its API includes both stuff that makes sense only at the block
backend level (root of the tree) and stuff that's only for use
within the block layer. This makes the API bigger and more complex
than necessary. Moreover, it's not obvious which interfaces are
meant for device models, and which really aren't.
* Since device models keep a reference to their backend, the backend
object can't just be destroyed. But for media change, we need to
replace the tree. Our solution is to make the BlockDriverState
generic, with actual driver state in a separate object, pointed to
by member opaque. That lets us replace the tree by deinitializing
and reinitializing its root. This special need of the root makes
the data structure awkward everywhere in the tree.
The general plan is to separate the APIs into "block backend", for use
by device models, monitor and whatever other code dealing with block
backends, and "block driver", for use by the block layer and whatever
other code (if any) dealing with trees and tree nodes.
Code dealing with block backends, device models in particular, should
become completely oblivious of BlockDriverState. This should let us
clean up both APIs, and the tree data structures.
This commit is a first step. It creates a minimal "block backend"
API: type BlockBackend and functions to create, destroy and find them.
BlockBackend objects are created and destroyed exactly when root
BlockDriverState objects are created and destroyed. "Root" in the
sense of "in bdrv_states". They're not yet used for anything; that'll
come shortly.
A root BlockDriverState is created with bdrv_new_root(), so where to
create a BlockBackend is obvious. Where these roots get destroyed
isn't always as obvious.
It is obvious in qemu-img.c, qemu-io.c and qemu-nbd.c, and in error
paths of blockdev_init(), blk_connect(). That leaves destruction of
objects successfully created by blockdev_init() and blk_connect().
blockdev_init() is used only by drive_new() and qmp_blockdev_add().
Objects created by the latter are currently indestructible (see commit
48f364d "blockdev: Refuse to drive_del something added with
blockdev-add" and commit 2d246f0 "blockdev: Introduce
DriveInfo.enable_auto_del"). Objects created by the former get
destroyed by drive_del().
Objects created by blk_connect() get destroyed by blk_disconnect().
BlockBackend is reference-counted. Its reference count never exceeds
one so far, but that's going to change.
In drive_del(), the BB's reference count is surely one now. The BDS's
reference count is greater than one when something else is holding a
reference, such as a block job. In this case, the BB is destroyed
right away, but the BDS lives on until all extra references get
dropped.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-10-07 13:59:04 +02:00
|
|
|
block-obj-y += block-backend.o snapshot.o qapi.o
|
2016-12-02 20:48:54 +01:00
|
|
|
block-obj-$(CONFIG_WIN32) += file-win32.o win32-aio.o
|
|
|
|
|
block-obj-$(CONFIG_POSIX) += file-posix.o
|
2012-10-26 11:27:45 +02:00
|
|
|
block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
|
2016-05-30 15:53:15 +02:00
|
|
|
block-obj-y += null.o mirror.o commit.o io.o
|
2015-06-08 18:17:42 +02:00
|
|
|
block-obj-y += throttle-groups.o
|
2012-06-09 04:01:51 +02:00
|
|
|
|
2013-12-01 22:23:41 +01:00
|
|
|
block-obj-y += nbd.o nbd-client.o sheepdog.o
|
2012-05-22 13:44:39 +02:00
|
|
|
block-obj-$(CONFIG_LIBISCSI) += iscsi.o
|
2017-01-24 13:49:21 +01:00
|
|
|
block-obj-$(if $(CONFIG_LIBISCSI),y,n) += iscsi-opts.o
|
2014-02-03 10:26:13 +01:00
|
|
|
block-obj-$(CONFIG_LIBNFS) += nfs.o
|
2012-05-22 13:44:39 +02:00
|
|
|
block-obj-$(CONFIG_CURL) += curl.o
|
|
|
|
|
block-obj-$(CONFIG_RBD) += rbd.o
|
2012-09-27 16:00:32 +02:00
|
|
|
block-obj-$(CONFIG_GLUSTERFS) += gluster.o
|
block: Support Archipelago as a QEMU block backend
VM Image on Archipelago volume is specified like this:
file.driver=archipelago,file.volume=<volumename>[,file.mport=<mapperd_port>[,
file.vport=<vlmcd_port>][,file.segment=<segment_name>]]
'archipelago' is the protocol.
'mport' is the port number on which mapperd is listening. This is optional
and if not specified, QEMU will make Archipelago to use the default port.
'vport' is the port number on which vlmcd is listening. This is optional
and if not specified, QEMU will make Archipelago to use the default port.
'segment' is the name of the shared memory segment Archipelago stack is using.
This is optional and if not specified, QEMU will make Archipelago to use the
default value, 'archipelago'.
Examples:
file.driver=archipelago,file.volume=my_vm_volume
file.driver=archipelago,file.volume=my_vm_volume,file.mport=123
file.driver=archipelago,file.volume=my_vm_volume,file.mport=123,
file.vport=1234
file.driver=archipelago,file.volume=my_vm_volume,file.mport=123,
file.vport=1234,file.segment=my_segment
Signed-off-by: Chrysostomos Nanakos <cnanakos@grnet.gr>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-08-04 16:35:32 +02:00
|
|
|
block-obj-$(CONFIG_ARCHIPELAGO) += archipelago.o
|
2013-04-09 16:30:53 +02:00
|
|
|
block-obj-$(CONFIG_LIBSSH2) += ssh.o
|
2016-03-08 05:44:55 +01:00
|
|
|
block-obj-y += accounting.o dirty-bitmap.o
|
block: add event when disk usage exceeds threshold
Managing applications, like oVirt (http://www.ovirt.org), make extensive
use of thin-provisioned disk images.
To let the guest run smoothly and be not unnecessarily paused, oVirt sets
a disk usage threshold (so called 'high water mark') based on the occupation
of the device, and automatically extends the image once the threshold
is reached or exceeded.
In order to detect the crossing of the threshold, oVirt has no choice but
aggressively polling the QEMU monitor using the query-blockstats command.
This lead to unnecessary system load, and is made even worse under scale:
deployments with hundreds of VMs are no longer rare.
To fix this, this patch adds:
* A new monitor command `block-set-write-threshold', to set a mark for
a given block device.
* A new event `BLOCK_WRITE_THRESHOLD', to report if a block device
usage exceeds the threshold.
* A new `write_threshold' field into the `BlockDeviceInfo' structure,
to report the configured threshold.
This will allow the managing application to use smarter and more
efficient monitoring, greatly reducing the need of polling.
[Updated qemu-iotests 067 output to add the new 'write_threshold'
property. --Stefan]
[Changed g_assert_false() to !g_assert() to fix the build on older glib
versions. --Kevin]
Signed-off-by: Francesco Romani <fromani@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1421068273-692-1-git-send-email-fromani@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-01-12 14:11:13 +01:00
|
|
|
block-obj-y += write-threshold.o
|
2016-07-27 09:01:45 +02:00
|
|
|
block-obj-y += backup.o
|
2016-07-27 09:01:50 +02:00
|
|
|
block-obj-$(CONFIG_REPLICATION) += replication.o
|
2012-09-28 17:22:47 +02:00
|
|
|
|
block: add generic full disk encryption driver
Add a block driver that is capable of supporting any full disk
encryption format. This utilizes the previously added block
encryption code, and at this time supports the LUKS format.
The driver code is capable of supporting any format supported
by the QCryptoBlock module, so it registers one block driver
for each format. This patch only registers the "luks" driver
since the "qcow" driver is there only for back-compatibility
with existing qcow built-in encryption.
New LUKS compatible volumes can be formatted using qemu-img
with defaults for all settings.
$ qemu-img create --object secret,data=123456,id=sec0 \
-f luks -o key-secret=sec0 demo.luks 10G
Alternatively the cryptographic settings can be explicitly
set
$ qemu-img create --object secret,data=123456,id=sec0 \
-f luks -o key-secret=sec0,cipher-alg=aes-256,\
cipher-mode=cbc,ivgen-alg=plain64,hash-alg=sha256 \
demo.luks 10G
And query its size
$ qemu-img info demo.img
image: demo.img
file format: luks
virtual size: 10G (10737418240 bytes)
disk size: 132K
encrypted: yes
Note that it was not necessary to provide the password
when querying info for the volume. The password is only
required when performing I/O on the volume
All volumes created by this new 'luks' driver should be
capable of being opened by the kernel dm-crypt driver.
The only algorithms listed in the LUKS spec that are
not currently supported by this impl are sha512 and
ripemd160 hashes and cast6 cipher.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
[ kwolf - Added #include to resolve conflict with da34e65c ]
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-03-21 15:11:47 +01:00
|
|
|
block-obj-y += crypto.o
|
|
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
common-obj-y += stream.o
|
2012-09-17 08:35:53 +02:00
|
|
|
|
2016-08-12 15:27:04 +02:00
|
|
|
nfs.o-libs := $(LIBNFS_LIBS)
|
2014-02-10 07:48:54 +01:00
|
|
|
iscsi.o-cflags := $(LIBISCSI_CFLAGS)
|
|
|
|
|
iscsi.o-libs := $(LIBISCSI_LIBS)
|
|
|
|
|
curl.o-cflags := $(CURL_CFLAGS)
|
|
|
|
|
curl.o-libs := $(CURL_LIBS)
|
|
|
|
|
rbd.o-cflags := $(RBD_CFLAGS)
|
|
|
|
|
rbd.o-libs := $(RBD_LIBS)
|
|
|
|
|
gluster.o-cflags := $(GLUSTERFS_CFLAGS)
|
|
|
|
|
gluster.o-libs := $(GLUSTERFS_LIBS)
|
|
|
|
|
ssh.o-cflags := $(LIBSSH2_CFLAGS)
|
|
|
|
|
ssh.o-libs := $(LIBSSH2_LIBS)
|
block: Support Archipelago as a QEMU block backend
VM Image on Archipelago volume is specified like this:
file.driver=archipelago,file.volume=<volumename>[,file.mport=<mapperd_port>[,
file.vport=<vlmcd_port>][,file.segment=<segment_name>]]
'archipelago' is the protocol.
'mport' is the port number on which mapperd is listening. This is optional
and if not specified, QEMU will make Archipelago to use the default port.
'vport' is the port number on which vlmcd is listening. This is optional
and if not specified, QEMU will make Archipelago to use the default port.
'segment' is the name of the shared memory segment Archipelago stack is using.
This is optional and if not specified, QEMU will make Archipelago to use the
default value, 'archipelago'.
Examples:
file.driver=archipelago,file.volume=my_vm_volume
file.driver=archipelago,file.volume=my_vm_volume,file.mport=123
file.driver=archipelago,file.volume=my_vm_volume,file.mport=123,
file.vport=1234
file.driver=archipelago,file.volume=my_vm_volume,file.mport=123,
file.vport=1234,file.segment=my_segment
Signed-off-by: Chrysostomos Nanakos <cnanakos@grnet.gr>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-08-04 16:35:32 +02:00
|
|
|
archipelago.o-libs := $(ARCHIPELAGO_LIBS)
|
2016-09-05 04:50:45 +02:00
|
|
|
block-obj-$(if $(CONFIG_BZIP2),m,n) += dmg-bz2.o
|
|
|
|
|
dmg-bz2.o-libs := $(BZIP2_LIBS)
|
2014-02-10 07:48:54 +01:00
|
|
|
qcow.o-libs := -lz
|
|
|
|
|
linux-aio.o-libs := -laio
|