2014-09-16 16:24:24 +02:00
|
|
|
block-obj-y += raw_bsd.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o vvfat.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
|
block: vhdx - log parsing, replay, and flush support
This adds support for VHDX v0 logs, as specified in Microsoft's
VHDX Specification Format v1.00:
https://www.microsoft.com/en-us/download/details.aspx?id=34750
The following support is added:
* Log parsing, and validation - validate that an existing log
is correct.
* Log search - search through an existing log, to find any valid
sequence of entries.
* Log replay and flush - replay an existing log, and flush/clear
the log when complete.
The VHDX log is a circular buffer, with elements (sectors) of 4KB.
A log entry is a variably-length number of sectors, that is
comprised of a header and 'descriptors', that describe each sector.
A log may contain multiple entries, know as a log sequence. In a log
sequence, each log entry immediately follows the previous entry, with an
incrementing sequence number. There can only ever be one active and
valid sequence in the log.
Each log entry must match the file log GUID in order to be valid (along
with other criteria). Once we have flushed all valid log entries, we
marked the file log GUID to be zero, which indicates a buffer with no
valid entries.
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-10-30 15:44:45 +01:00
|
|
|
block-obj-$(CONFIG_VHDX) += vhdx.o vhdx-endian.o vhdx-log.o
|
2014-02-21 22:21:15 +01:00
|
|
|
block-obj-$(CONFIG_QUORUM) += quorum.o
|
2012-06-09 04:01:51 +02:00
|
|
|
block-obj-y += parallels.o blkdebug.o blkverify.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
|
2012-10-26 11:43:58 +02:00
|
|
|
block-obj-$(CONFIG_WIN32) += raw-win32.o win32-aio.o
|
2012-05-22 13:44:39 +02:00
|
|
|
block-obj-$(CONFIG_POSIX) += raw-posix.o
|
2012-10-26 11:27:45 +02:00
|
|
|
block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
|
2014-10-24 15:57:37 +02:00
|
|
|
block-obj-y += null.o mirror.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
|
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
|
2014-09-05 15:46:16 +02:00
|
|
|
block-obj-y += accounting.o
|
2012-09-28 17:22:47 +02:00
|
|
|
|
|
|
|
|
common-obj-y += stream.o
|
|
|
|
|
common-obj-y += commit.o
|
2013-06-24 17:13:11 +02:00
|
|
|
common-obj-y += backup.o
|
2012-09-17 08:35:53 +02:00
|
|
|
|
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)
|
2014-02-10 07:48:54 +01:00
|
|
|
qcow.o-libs := -lz
|
|
|
|
|
linux-aio.o-libs := -laio
|
