By default, pool-info will convert sizes to human friendly units.

This patch will introduce option [--bytes].
If specified, the raw sizes will be in the output.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

* remove _vboxIID_v2_x and _vboxIID_v3_x structs and repalce with one
  _vboxIID as all supprted vbox versions have the same IID structure.
* remove vboxIIDUnion that was used to abstract version depended IID
  differences.
* remove IID_MEMBER macro and use the new vboxIID directly.

This function was not implemented for vbox 5+ which removed
TakeScreenShotPNGToArray but provides TakeScreenShotToArray with
BitmapFormat_PNG argument which is the same thing.

The IVRDxServer was used because vbox < 4 used to have IVRDPServer
whereas vbox >= 4 has IVRDEServer. Now that support for legacy
versions is being removed, we can use IVRDEServer.

* removed oldMediumInterface flag and related code that was used for
  vbox 2.x
* remove accelerate2DVideo and networkRemoveInterface flags which were
  also conditionals for handling legacy vbox versions.

this was implemented only for vbox 3 series and was mostly stubs
anyway.

* the getMachineForSession is always true for 4.0+. This also means that
  checkflag argument in openSessionForMachine no longer has any meaning
  because it was or'ed with getMachineForSession (always true)
* remove supportScreenshot flag - vbox 4.0+ supports it
* remove detachDevicesExplicitly flag only relevant for < 4.0

VirtualBox 4.0+ uses IMedium and IHardDisk is no longer used, so

* remove typef IMedium IHardDisk
* merge UIHardDisk into UIMedium
* update all references accordingly

and fold vboxAttachDrivesNew into vboxAttachDrives

This removes most of the code wrapped in VBOX_API_VERSION < 4000000
preprocessor checks. Those are the ones that can be safely removed
without needing to update driver code to accomodate it.

That is, for versions older than 4.0. Also do not try to include
headers for those old versions.

* delete SDK header files for vbox older than 4.0
* delete .c files for vbox older than 4.0
* update vbox_XPCOMCGlue to use oldest supported header file, that is 4.0
  going forward.
* remove deleted files from Makefile.am

Among other recent changes, this includes a workaround to avoid
Clang compiler bug https://llvm.org/bugs/show_bug.cgi?id=16404
having spurious link failures.

* .gnulib: Update.
* bootstrap: Synchronize to upstream.
Signed-off-by: NEric Blake <eblake@redhat.com>

Now that we have built a fairly solid process for dealing with
release notes, we should start pushing for contributors to
provide the relevant information along with their code:
documenting the process is clearly a requirement for this to
happen.

Instead of encoding formatting information inside the
corresponding XSLT stylesheet, use a Python script to reformat
the text appropriately based on a few simple markers.

Splitting the task between the XSLT stylesheet and the Python
script allows us to keep both parts very simple.

Currently, building the NEWS file involves using a XSLT stylesheet
to extract information from the same HTML file that's used on the
libvirt website.

The process works, but it's quite fiddly in that it requires the
source HTML to be formatted in a very precise way, and a single
missing newline can mess up the resulting plain text considerably.

Moreover, the XSLT stylesheet itself encodes a lot of the details
of converting to plain text in a way that's not necessarily easy
to understand, tweak or fix.

To improve the process, move all existing entries to a new XML
file that contains exactly the information we care about in a
simple structured format, and start generating both the HTML and
plain text versions of the release notes using XSLT stylesheets
that can now afford to be almost trivial.

There are still some systems out there that have broken
setfilecon*() prototypes. Instead of taking 'const char *tcon' it
is taking 'char *tcon'. The function should just set the context,
not modify it.

We had been bitten with this problem before which resulted in
292d3f2d and subsequently b109c097. However, with one my latest
commits (4674fc6a) I've changed the type of @tcon variable to
'const char *' which results in build failure on the systems from
above.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function is used only from code compiled on Linux. Therefore
on non-Linux platforms it triggers compilation error:

../../src/qemu/qemu_domain.c:209:1: error: unused function 'qemuDomainGetPreservedMounts' [-Werror,-Wunused-function]
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

For the blockjobs, where libvirt is able to track the state internally
we can fix locking of images we can remove the appropriate locks.

Also when doing a pivoting operation we should not acquire the lock on
any of those images since both are actually locked already.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1302168

Images that became the backing chain of the current image due to the
snapshot need to be unlocked in the lock manager. Also if qemu was
paused during the snapshot the current top level images need to be
released until qemu is resumed so that they can be acquired properly.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1191901

The code at first changed the definition and then rolled it back in case
of failure. This was ridiculous. Refactor the code so that the image in
the definition is changed only when the snapshot is successful.

The refactor will also simplify further fix of image locking when doing
snapshots.

Libvirt is able to properly model what happens to the backing chain
after a snapshot so there's no real need to redetect the data.
Additionally with the _REUSE_EXT flag this might end up in redetecting
wrong data if the user puts wrong backing chain reference into the
snapshot image.

The libxl driver already supports getting maximum vcpu count via
libxlDomainGetVcpusFlags, allowing to trivially implement
virDomainGetMaxVcpus.

Commit id 'a48c674f' caused problems for systems without PARTED installed.

So move the PARTED probing code back to storage_backend_disk.c and create
a shim within storage_backend.c to call it if WITH_STORAGE_DISK is true;
otherwise, just return -1 with the error.

At startup time, rather than blindly trusting the target devices are
still properly formatted, let's check to make sure the pool's target
devices are all properly formatted before attempting to start the pool.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1373711

Add support and documentation for the [NO_]OVERWRITE flags for the
logical backend.

Update virsh.pod with a description of the process for usage of
the flags and building of the pool's volume group.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Make the remaining code a bit cleaner.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If the build fails, then we need to ensure that we've run pvremove
on any devices which we've run pvcreate on; otherwise, a subsequent
build could fail since running pvcreate twice on a device requires
special force arguments.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Currently as long as the disk is formatted using a known parted format
type, the algorithm is happy to continue. However, that leaves a scenario
whereby a disk formatted using "pc98" could be used by a pool that's defined
using "dvh" (or vice versa). Alter the check to be match and different
and adjust the caller.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than have the Disk code having to use PARTED to determine if
there's something on the device, let's use the virStorageBackendDeviceProbe.
and only fallback to the PARTED probing if the BLKID code isn't built in.

This will also provide a mechanism for the other current caller (File
System Backend) to utilize a PARTED parsing algorithm in the event that
BLKID isn't built in to at least see if *something* exists on the disk
before blindly trying to use. The PARTED error checking will not find
file system types, but if there is a partition table set on the device,
it will at least cause a failure.

Move virStorageBackendDiskValidLabel and virStorageBackendDiskFindLabel
to storage_backend and rename/rework the code to fit the new model.

Update the virsh.pod description to provide a more generic description
of the process since we could now use either blkid or parted to find
data on the target device.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Prior to starting up, let's be sure the target volume device is
formatted as we expect; otherwise, inhibit the start.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

It's possible that the API could be called from a startup path in
order to check whether the label on the device matches what our
format is. In order to handle that condition, add a 'writelabel'
boolean to the API in order to indicate whether a write or just
read is about to happen.

This alters two "error" conditions that would care about knowing.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

A device may be formatted using some sort of disk partition format type.
We can check that using the blkid_ API's as well - so alter the logic to
allow checking the device for both a filesystem and a disk partition.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1363586

Commit id '27758859' introduced the "NO_OVERWRITE" flag check for
file system backends; however, the implementation, documentation,
and algorithm was inconsistent. For the "flag" description for the
API the flag was described as "Do not overwrite existing pool";
however, within the storage backend code the flag is described
as "it probes to determine if filesystem already exists on the
target device, renurning an error if exists".

The code itself was implemented using the paradigm to set up the
superblock probe by creating a filter that would cause the code
to only search for the provided format type. If that type wasn't
found, then the algorithm would return success allowing the caller
to format the device. If the format type already existed on the
device, then the code would fail indicating that the a filesystem
of the same type existed on the device.

The result is that if someone had a file system of one type on the
device, it was possible to overwrite it if a different format type
was specified in updated XML effectively trashing whatever was on
the device already.

This patch alters what NO_OVERWRITE does for a file system backend
to be more realistic and consistent with what should be expected when
the caller requests to not overwrite the data on the disk.

Rather than filter results based on the expected format type, the
code will allow success/failure be determined solely on whether the
blkid_do_probe calls finds some known format on the device. This
adjustment also allows removal of the virStoragePoolProbeResult
enum that was under utilized.

If it does find a formatted file system different errors will be
generated indicating a file system of a specific type already exists
or a file system of some other type already exists.

In the original virsh support commit id 'ddcd5674', the description
for '--no-overwrite' within the 'pool-build' command help output
has an ambiguous "of this type" included in the short description.
Compared to the longer description within the "Build a given pool."
section of the virsh.pod file it's more apparent that the meaning
of this flag would cause failure if a probe of the target already
has a filesystem.

So this patch also modifies the short description to just be the
antecedent of the 'overwrite' flag, which matches the API description.
This patch also modifies the grammar in virsh.pod for no-overwrite
as well as reworking the paragraph formats to make it easier to read.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rename virStorageBackendFileSystemProbe and to virStorageBackendBLKIDFindFS
and move to the more common storage_backend module.

Create a shim virStorageBackendDeviceIsEmpty which will make the call
to the virStorageBackendBLKIDFindFS and check the return value.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

After previous commits, this function is no longer needed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Again, there is no need to create /var/lib/libvirt/$domain.*
directories in CreateNamespace(). It is sufficient to create them
as soon as we need them which is in BuildNamespace. This way we
don't leave them around for the whole lifetime of domain.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The c1140eb9 got me thinking. We don't want to special case /dev
in qemuDomainGetPreservedMounts(), but in all other places in the
code we special case it anyway. I mean,
/var/run/libvirt/$domain.dev path is constructed separately just
so that it is not constructed here. It makes only a little sense
(if any at all).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If something goes wrong in this function we try a rollback. That
is unlink all the directories we created earlier. For some weird
reason unlink() was called instead of rmdir().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>