Adding qemu as a submodule of KVMFORNFV

This Patch includes the changes to add qemu as a submodule to
kvmfornfv repo and make use of the updated latest qemu for the
execution of all testcase
Change-Id: I1280af507a857675c7f81d30c95255635667bdd7
Signed-off-by:RajithaY<rajithax.yerrumsetty@intel.com>

1 files changed, 0 insertions, 568 deletions

diff --git a/qemu/qemu-img.texi b/qemu/qemu-img.texi
deleted file mode 100644
index afaebdd40..000000000
--- a/qemu/qemu-img.texi
+++ /dev/null
@@ -1,568 +0,0 @@
-@example
-@c man begin SYNOPSIS
-@command{qemu-img} @var{command} [@var{command} @var{options}]
-@c man end
-@end example
-
-@c man begin DESCRIPTION
-qemu-img allows you to create, convert and modify images offline. It can handle
-all image formats supported by QEMU.
-
-@b{Warning:} Never use qemu-img to modify images in use by a running virtual
-machine or any other process; this may destroy the image. Also, be aware that
-querying an image that is being modified by another process may encounter
-inconsistent state.
-@c man end
-
-@c man begin OPTIONS
-
-The following commands are supported:
-
-@include qemu-img-cmds.texi
-
-Command parameters:
-@table @var
-@item filename
- is a disk image filename
-
-@item --object @var{objectdef}
-
-is a QEMU user creatable object definition. See the @code{qemu(1)} manual
-page for a description of the object properties. The most common object
-type is a @code{secret}, which is used to supply passwords and/or encryption
-keys.
-
-@item --image-opts
-
-Indicates that the @var{filename} parameter is to be interpreted as a
-full option string, not a plain filename. This parameter is mutually
-exclusive with the @var{-f} and @var{-F} parameters.
-
-@item fmt
-is the disk image format. It is guessed automatically in most cases. See below
-for a description of the supported disk formats.
-
-@item --backing-chain
-will enumerate information about backing files in a disk image chain. Refer
-below for further description.
-
-@item size
-is the disk image size in bytes. Optional suffixes @code{k} or @code{K}
-(kilobyte, 1024) @code{M} (megabyte, 1024k) and @code{G} (gigabyte, 1024M)
-and T (terabyte, 1024G) are supported.  @code{b} is ignored.
-
-@item output_filename
-is the destination disk image filename
-
-@item output_fmt
- is the destination format
-@item options
-is a comma separated list of format specific options in a
-name=value format. Use @code{-o ?} for an overview of the options supported
-by the used format or see the format descriptions below for details.
-@item snapshot_param
-is param used for internal snapshot, format is
-'snapshot.id=[ID],snapshot.name=[NAME]' or '[ID_OR_NAME]'
-@item snapshot_id_or_name
-is deprecated, use snapshot_param instead
-
-@item -c
-indicates that target image must be compressed (qcow format only)
-@item -h
-with or without a command shows help and lists the supported formats
-@item -p
-display progress bar (compare, convert and rebase commands only).
-If the @var{-p} option is not used for a command that supports it, the
-progress is reported when the process receives a @code{SIGUSR1} signal.
-@item -q
-Quiet mode - do not print any output (except errors). There's no progress bar
-in case both @var{-q} and @var{-p} options are used.
-@item -S @var{size}
-indicates the consecutive number of bytes that must contain only zeros
-for qemu-img to create a sparse image during conversion. This value is rounded
-down to the nearest 512 bytes. You may use the common size suffixes like
-@code{k} for kilobytes.
-@item -t @var{cache}
-specifies the cache mode that should be used with the (destination) file. See
-the documentation of the emulator's @code{-drive cache=...} option for allowed
-values.
-@item -T @var{src_cache}
-specifies the cache mode that should be used with the source file(s). See
-the documentation of the emulator's @code{-drive cache=...} option for allowed
-values.
-@end table
-
-Parameters to snapshot subcommand:
-
-@table @option
-
-@item snapshot
-is the name of the snapshot to create, apply or delete
-@item -a
-applies a snapshot (revert disk to saved state)
-@item -c
-creates a snapshot
-@item -d
-deletes a snapshot
-@item -l
-lists all snapshots in the given image
-@end table
-
-Parameters to compare subcommand:
-
-@table @option
-
-@item -f
-First image format
-@item -F
-Second image format
-@item -s
-Strict mode - fail on different image size or sector allocation
-@end table
-
-Parameters to convert subcommand:
-
-@table @option
-
-@item -n
-Skip the creation of the target volume
-@end table
-
-Command description:
-
-@table @option
-@item check [-f @var{fmt}] [--output=@var{ofmt}] [-r [leaks | all]] [-T @var{src_cache}] @var{filename}
-
-Perform a consistency check on the disk image @var{filename}. The command can
-output in the format @var{ofmt} which is either @code{human} or @code{json}.
-
-If @code{-r} is specified, qemu-img tries to repair any inconsistencies found
-during the check. @code{-r leaks} repairs only cluster leaks, whereas
-@code{-r all} fixes all kinds of errors, with a higher risk of choosing the
-wrong fix or hiding corruption that has already occurred.
-
-Only the formats @code{qcow2}, @code{qed} and @code{vdi} support
-consistency checks.
-
-In case the image does not have any inconsistencies, check exits with @code{0}.
-Other exit codes indicate the kind of inconsistency found or if another error
-occurred. The following table summarizes all exit codes of the check subcommand:
-
-@table @option
-
-@item 0
-Check completed, the image is (now) consistent
-@item 1
-Check not completed because of internal errors
-@item 2
-Check completed, image is corrupted
-@item 3
-Check completed, image has leaked clusters, but is not corrupted
-@item 63
-Checks are not supported by the image format
-
-@end table
-
-If @code{-r} is specified, exit codes representing the image state refer to the
-state after (the attempt at) repairing it. That is, a successful @code{-r all}
-will yield the exit code 0, independently of the image state before.
-
-@item create [-f @var{fmt}] [-o @var{options}] @var{filename} [@var{size}]
-
-Create the new disk image @var{filename} of size @var{size} and format
-@var{fmt}. Depending on the file format, you can add one or more @var{options}
-that enable additional features of this format.
-
-If the option @var{backing_file} is specified, then the image will record
-only the differences from @var{backing_file}. No size needs to be specified in
-this case. @var{backing_file} will never be modified unless you use the
-@code{commit} monitor command (or qemu-img commit).
-
-The size can also be specified using the @var{size} option with @code{-o},
-it doesn't need to be specified separately in this case.
-
-@item commit [-q] [-f @var{fmt}] [-t @var{cache}] [-b @var{base}] [-d] [-p] @var{filename}
-
-Commit the changes recorded in @var{filename} in its base image or backing file.
-If the backing file is smaller than the snapshot, then the backing file will be
-resized to be the same size as the snapshot.  If the snapshot is smaller than
-the backing file, the backing file will not be truncated.  If you want the
-backing file to match the size of the smaller snapshot, you can safely truncate
-it yourself once the commit operation successfully completes.
-
-The image @var{filename} is emptied after the operation has succeeded. If you do
-not need @var{filename} afterwards and intend to drop it, you may skip emptying
-@var{filename} by specifying the @code{-d} flag.
-
-If the backing chain of the given image file @var{filename} has more than one
-layer, the backing file into which the changes will be committed may be
-specified as @var{base} (which has to be part of @var{filename}'s backing
-chain). If @var{base} is not specified, the immediate backing file of the top
-image (which is @var{filename}) will be used. For reasons of consistency,
-explicitly specifying @var{base} will always imply @code{-d} (since emptying an
-image after committing to an indirect backing file would lead to different data
-being read from the image due to content in the intermediate backing chain
-overruling the commit target).
-
-@item compare [-f @var{fmt}] [-F @var{fmt}] [-T @var{src_cache}] [-p] [-s] [-q] @var{filename1} @var{filename2}
-
-Check if two images have the same content. You can compare images with
-different format or settings.
-
-The format is probed unless you specify it by @var{-f} (used for
-@var{filename1}) and/or @var{-F} (used for @var{filename2}) option.
-
-By default, images with different size are considered identical if the larger
-image contains only unallocated and/or zeroed sectors in the area after the end
-of the other image. In addition, if any sector is not allocated in one image
-and contains only zero bytes in the second one, it is evaluated as equal. You
-can use Strict mode by specifying the @var{-s} option. When compare runs in
-Strict mode, it fails in case image size differs or a sector is allocated in
-one image and is not allocated in the second one.
-
-By default, compare prints out a result message. This message displays
-information that both images are same or the position of the first different
-byte. In addition, result message can report different image size in case
-Strict mode is used.
-
-Compare exits with @code{0} in case the images are equal and with @code{1}
-in case the images differ. Other exit codes mean an error occurred during
-execution and standard error output should contain an error message.
-The following table sumarizes all exit codes of the compare subcommand:
-
-@table @option
-
-@item 0
-Images are identical
-@item 1
-Images differ
-@item 2
-Error on opening an image
-@item 3
-Error on checking a sector allocation
-@item 4
-Error on reading data
-
-@end table
-
-@item convert [-c] [-p] [-n] [-f @var{fmt}] [-t @var{cache}] [-T @var{src_cache}] [-O @var{output_fmt}] [-o @var{options}] [-s @var{snapshot_id_or_name}] [-l @var{snapshot_param}] [-S @var{sparse_size}] @var{filename} [@var{filename2} [...]] @var{output_filename}
-
-Convert the disk image @var{filename} or a snapshot @var{snapshot_param}(@var{snapshot_id_or_name} is deprecated)
-to disk image @var{output_filename} using format @var{output_fmt}. It can be optionally compressed (@code{-c}
-option) or use any format specific options like encryption (@code{-o} option).
-
-Only the formats @code{qcow} and @code{qcow2} support compression. The
-compression is read-only. It means that if a compressed sector is
-rewritten, then it is rewritten as uncompressed data.
-
-Image conversion is also useful to get smaller image when using a
-growable format such as @code{qcow}: the empty sectors are detected and
-suppressed from the destination image.
-
-@var{sparse_size} indicates the consecutive number of bytes (defaults to 4k)
-that must contain only zeros for qemu-img to create a sparse image during
-conversion. If @var{sparse_size} is 0, the source will not be scanned for
-unallocated or zero sectors, and the destination image will always be
-fully allocated.
-
-You can use the @var{backing_file} option to force the output image to be
-created as a copy on write image of the specified base image; the
-@var{backing_file} should have the same content as the input's base image,
-however the path, image format, etc may differ.
-
-If the @code{-n} option is specified, the target volume creation will be
-skipped. This is useful for formats such as @code{rbd} if the target
-volume has already been created with site specific options that cannot
-be supplied through qemu-img.
-
-@item info [-f @var{fmt}] [--output=@var{ofmt}] [--backing-chain] @var{filename}
-
-Give information about the disk image @var{filename}. Use it in
-particular to know the size reserved on disk which can be different
-from the displayed size. If VM snapshots are stored in the disk image,
-they are displayed too. The command can output in the format @var{ofmt}
-which is either @code{human} or @code{json}.
-
-If a disk image has a backing file chain, information about each disk image in
-the chain can be recursively enumerated by using the option @code{--backing-chain}.
-
-For instance, if you have an image chain like:
-
-@example
-base.qcow2 <- snap1.qcow2 <- snap2.qcow2
-@end example
-
-To enumerate information about each disk image in the above chain, starting from top to base, do:
-
-@example
-qemu-img info --backing-chain snap2.qcow2
-@end example
-
-@item map [-f @var{fmt}] [--output=@var{ofmt}] @var{filename}
-
-Dump the metadata of image @var{filename} and its backing file chain.
-In particular, this commands dumps the allocation state of every sector
-of @var{filename}, together with the topmost file that allocates it in
-the backing file chain.
-
-Two option formats are possible.  The default format (@code{human})
-only dumps known-nonzero areas of the file.  Known-zero parts of the
-file are omitted altogether, and likewise for parts that are not allocated
-throughout the chain.  @command{qemu-img} output will identify a file
-from where the data can be read, and the offset in the file.  Each line
-will include four fields, the first three of which are hexadecimal
-numbers.  For example the first line of:
-@example
-Offset          Length          Mapped to       File
-0               0x20000         0x50000         /tmp/overlay.qcow2
-0x100000        0x10000         0x95380000      /tmp/backing.qcow2
-@end example
-@noindent
-means that 0x20000 (131072) bytes starting at offset 0 in the image are
-available in /tmp/overlay.qcow2 (opened in @code{raw} format) starting
-at offset 0x50000 (327680).  Data that is compressed, encrypted, or
-otherwise not available in raw format will cause an error if @code{human}
-format is in use.  Note that file names can include newlines, thus it is
-not safe to parse this output format in scripts.
-
-The alternative format @code{json} will return an array of dictionaries
-in JSON format.  It will include similar information in
-the @code{start}, @code{length}, @code{offset} fields;
-it will also include other more specific information:
-@itemize @minus
-@item
-whether the sectors contain actual data or not (boolean field @code{data};
-if false, the sectors are either unallocated or stored as optimized
-all-zero clusters);
-
-@item
-whether the data is known to read as zero (boolean field @code{zero});
-
-@item
-in order to make the output shorter, the target file is expressed as
-a @code{depth}; for example, a depth of 2 refers to the backing file
-of the backing file of @var{filename}.
-@end itemize
-
-In JSON format, the @code{offset} field is optional; it is absent in
-cases where @code{human} format would omit the entry or exit with an error.
-If @code{data} is false and the @code{offset} field is present, the
-corresponding sectors in the file are not yet in use, but they are
-preallocated.
-
-For more information, consult @file{include/block/block.h} in QEMU's
-source code.
-
-@item snapshot [-l | -a @var{snapshot} | -c @var{snapshot} | -d @var{snapshot} ] @var{filename}
-
-List, apply, create or delete snapshots in image @var{filename}.
-
-@item rebase [-f @var{fmt}] [-t @var{cache}] [-T @var{src_cache}] [-p] [-u] -b @var{backing_file} [-F @var{backing_fmt}] @var{filename}
-
-Changes the backing file of an image. Only the formats @code{qcow2} and
-@code{qed} support changing the backing file.
-
-The backing file is changed to @var{backing_file} and (if the image format of
-@var{filename} supports this) the backing file format is changed to
-@var{backing_fmt}. If @var{backing_file} is specified as ``'' (the empty
-string), then the image is rebased onto no backing file (i.e. it will exist
-independently of any backing file).
-
-@var{cache} specifies the cache mode to be used for @var{filename}, whereas
-@var{src_cache} specifies the cache mode for reading backing files.
-
-There are two different modes in which @code{rebase} can operate:
-@table @option
-@item Safe mode
-This is the default mode and performs a real rebase operation. The new backing
-file may differ from the old one and qemu-img rebase will take care of keeping
-the guest-visible content of @var{filename} unchanged.
-
-In order to achieve this, any clusters that differ between @var{backing_file}
-and the old backing file of @var{filename} are merged into @var{filename}
-before actually changing the backing file.
-
-Note that the safe mode is an expensive operation, comparable to converting
-an image. It only works if the old backing file still exists.
-
-@item Unsafe mode
-qemu-img uses the unsafe mode if @code{-u} is specified. In this mode, only the
-backing file name and format of @var{filename} is changed without any checks
-on the file contents. The user must take care of specifying the correct new
-backing file, or the guest-visible content of the image will be corrupted.
-
-This mode is useful for renaming or moving the backing file to somewhere else.
-It can be used without an accessible old backing file, i.e. you can use it to
-fix an image whose backing file has already been moved/renamed.
-@end table
-
-You can use @code{rebase} to perform a ``diff'' operation on two
-disk images.  This can be useful when you have copied or cloned
-a guest, and you want to get back to a thin image on top of a
-template or base image.
-
-Say that @code{base.img} has been cloned as @code{modified.img} by
-copying it, and that the @code{modified.img} guest has run so there
-are now some changes compared to @code{base.img}.  To construct a thin
-image called @code{diff.qcow2} that contains just the differences, do:
-
-@example
-qemu-img create -f qcow2 -b modified.img diff.qcow2
-qemu-img rebase -b base.img diff.qcow2
-@end example
-
-At this point, @code{modified.img} can be discarded, since
-@code{base.img + diff.qcow2} contains the same information.
-
-@item resize @var{filename} [+ | -]@var{size}
-
-Change the disk image as if it had been created with @var{size}.
-
-Before using this command to shrink a disk image, you MUST use file system and
-partitioning tools inside the VM to reduce allocated file systems and partition
-sizes accordingly.  Failure to do so will result in data loss!
-
-After using this command to grow a disk image, you must use file system and
-partitioning tools inside the VM to actually begin using the new space on the
-device.
-
-@item amend [-p] [-f @var{fmt}] [-t @var{cache}] -o @var{options} @var{filename}
-
-Amends the image format specific @var{options} for the image file
-@var{filename}. Not all file formats support this operation.
-@end table
-@c man end
-
-@ignore
-@c man begin NOTES
-Supported image file formats:
-
-@table @option
-@item raw
-
-Raw disk image format (default). This format has the advantage of
-being simple and easily exportable to all other emulators. If your
-file system supports @emph{holes} (for example in ext2 or ext3 on
-Linux or NTFS on Windows), then only the written sectors will reserve
-space. Use @code{qemu-img info} to know the real size used by the
-image or @code{ls -ls} on Unix/Linux.
-
-Supported options:
-@table @code
-@item preallocation
-Preallocation mode (allowed values: @code{off}, @code{falloc}, @code{full}).
-@code{falloc} mode preallocates space for image by calling posix_fallocate().
-@code{full} mode preallocates space for image by writing zeros to underlying
-storage.
-@end table
-
-@item qcow2
-QEMU image format, the most versatile format. Use it to have smaller
-images (useful if your filesystem does not supports holes, for example
-on Windows), optional AES encryption, zlib based compression and
-support of multiple VM snapshots.
-
-Supported options:
-@table @code
-@item compat
-Determines the qcow2 version to use. @code{compat=0.10} uses the
-traditional image format that can be read by any QEMU since 0.10.
-@code{compat=1.1} enables image format extensions that only QEMU 1.1 and
-newer understand (this is the default). Amongst others, this includes zero
-clusters, which allow efficient copy-on-read for sparse images.
-
-@item backing_file
-File name of a base image (see @option{create} subcommand)
-@item backing_fmt
-Image format of the base image
-@item encryption
-If this option is set to @code{on}, the image is encrypted with 128-bit AES-CBC.
-
-The use of encryption in qcow and qcow2 images is considered to be flawed by
-modern cryptography standards, suffering from a number of design problems:
-
-@itemize @minus
-@item The AES-CBC cipher is used with predictable initialization vectors based
-on the sector number. This makes it vulnerable to chosen plaintext attacks
-which can reveal the existence of encrypted data.
-@item The user passphrase is directly used as the encryption key. A poorly
-chosen or short passphrase will compromise the security of the encryption.
-@item In the event of the passphrase being compromised there is no way to
-change the passphrase to protect data in any qcow images. The files must
-be cloned, using a different encryption passphrase in the new file. The
-original file must then be securely erased using a program like shred,
-though even this is ineffective with many modern storage technologies.
-@end itemize
-
-Use of qcow / qcow2 encryption is thus strongly discouraged. Users are
-recommended to use an alternative encryption technology such as the
-Linux dm-crypt / LUKS system.
-
-@item cluster_size
-Changes the qcow2 cluster size (must be between 512 and 2M). Smaller cluster
-sizes can improve the image file size whereas larger cluster sizes generally
-provide better performance.
-
-@item preallocation
-Preallocation mode (allowed values: @code{off}, @code{metadata}, @code{falloc},
-@code{full}). An image with preallocated metadata is initially larger but can
-improve performance when the image needs to grow. @code{falloc} and @code{full}
-preallocations are like the same options of @code{raw} format, but sets up
-metadata also.
-
-@item lazy_refcounts
-If this option is set to @code{on}, reference count updates are postponed with
-the goal of avoiding metadata I/O and improving performance. This is
-particularly interesting with @option{cache=writethrough} which doesn't batch
-metadata updates. The tradeoff is that after a host crash, the reference count
-tables must be rebuilt, i.e. on the next open an (automatic) @code{qemu-img
-check -r all} is required, which may take some time.
-
-This option can only be enabled if @code{compat=1.1} is specified.
-
-@item nocow
-If this option is set to @code{on}, it will turn off COW of the file. It's only
-valid on btrfs, no effect on other file systems.
-
-Btrfs has low performance when hosting a VM image file, even more when the guest
-on the VM also using btrfs as file system. Turning off COW is a way to mitigate
-this bad performance. Generally there are two ways to turn off COW on btrfs:
-a) Disable it by mounting with nodatacow, then all newly created files will be
-NOCOW. b) For an empty file, add the NOCOW file attribute. That's what this option
-does.
-
-Note: this option is only valid to new or empty files. If there is an existing
-file which is COW and has data blocks already, it couldn't be changed to NOCOW
-by setting @code{nocow=on}. One can issue @code{lsattr filename} to check if
-the NOCOW flag is set or not (Capital 'C' is NOCOW flag).
-
-@end table
-
-@item Other
-QEMU also supports various other image file formats for compatibility with
-older QEMU versions or other hypervisors, including VMDK, VDI, VHD (vpc), VHDX,
-qcow1 and QED. For a full list of supported formats see @code{qemu-img --help}.
-For a more detailed description of these formats, see the QEMU Emulation User
-Documentation.
-
-The main purpose of the block drivers for these formats is image conversion.
-For running VMs, it is recommended to convert the disk images to either raw or
-qcow2 in order to achieve good performance.
-@end table
-
-
-@c man end
-
-@setfilename qemu-img
-@settitle QEMU disk image utility
-
-@c man begin SEEALSO
-The HTML documentation of QEMU for more precise information and Linux
-user mode emulator invocation.
-@c man end
-
-@c man begin AUTHOR
-Fabrice Bellard
-@c man end
-
-@end ignore