Currently the protocol type with index 0 was NBD which made it hard to
distinguish whether the protocol type was actually assigned. Add a new
protocol type with index 0 to distinguish it explicitly.

Skip networked storage but continue iteration through backing chain to
iterate through all the local paths in the backing chain.

Print the debug statements of individual file access functions from the
main API functions instead of the individual backend functions.

Also enhance initialization debug messages on a per-backend basis.

The gluster volume name was previously stored as part of the source path
string. This is unfortunate when we want to do operations on the path as
the volume is used separately.

Parse and store the volume name separately for gluster storage volumes
and use the newly stored variable appropriately.

Refactor the function to accept a virStorageSourcePtr instead of just
the path, add a check to run it only on local storage and fix callers
(possibly by using a newly introduced wrapper that wraps a path in the
 virStorageSource struct for legacy code)

Refresh the disk backing chains when reconnecting to a qemu process
after daemon restart. There are a few internal fields that don't get
refreshed from the XML. Until we are able to do that, let's reload all
the metadata by the backing chain crawler.

This is similar to the previous commit in that we need to explicitly
send migrate_cancel when libvirt detects an error other than those
reported by query-migrate. However, the possibility to hit such error is
pretty small.

When QEMU reports failed or cancelled migration, we don't need to send
it migrate_cancel QMP command. But in all other error paths, such as if
we detect broken connection to a destination daemon or something else
happens inside libvirt, we need to explicitly send migrate_cancel
command instead of relying on the migration to be implicitly cancelled
when destination QEMU is killed.

Because we were not doing so, one could end up with a paused domain
after failed migration.

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

The current error message is

    error: use virDomainMigrateToURI3 for peer-to-peer migration

which is correct but a bit misleading because the client did not specify
VIR_MIGRATE_PEER2PEER flag. This patch changes the error message to

    error: cannot perform tunnelled migration without using peer2peer
    flag

which is consistent with the error reported by older migration APIs.

Reported by Rich Jones in
https://bugzilla.redhat.com/show_bug.cgi?id=1095924

Commit 546154e3 parses the type attribute from a <backingStore>
element, but forgot that the earlier commit 9673418c added a
placeholder element in the same 1.2.3 release; as a result,
the C code was mistakenly allowing "none" as a type.

Similarly, the same commit allows "none" as the <format>
sub-element type, even though that has been a placeholder
since the 0.10.2 release with commit f772b3d9.

* src/conf/domain_conf.c (virDomainDiskBackingStoreParse): Require
non-zero types.
Signed-off-by: NEric Blake <eblake@redhat.com>

If virDomainMemoryStats is called too soon after domain startup,
QEMU returns:
"error":{"class":"GenericError","desc":"guest hasn't updated any stats yet"}
when we try to query balloon stats.

Check for this reply and log it as OPERATION_INVALID instead of
INTERNAL_ERROR. This means the daemon only logs it at the debug level,
without polluting system logs.

Reported by Laszlo Pal:
https://www.redhat.com/archives/libvirt-users/2014-May/msg00023.html

In the f56c773b we've made the substitution but forgot to fix one
comment which is still referring to the old name. This may be
potentially misleading.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In a number of places in the bhyve driver, virObjectUnlock()
is called with an arg without check if the arg is non-NULL, which
could result in passing NULL value and a warning like:

virObjectUnlock:340 : Object 0x0 ((unknown)) is not a virObjectLockable instance

* src/bhyve/bhyve_driver.c (bhyveDomainGetInfo)
(bhyveDomainGetState, bhyveDomainGetAutostart)
(bhyveDomainSetAutostart, bhyveDomainIsActive)
(bhyveDomainIsPersistent, bhyveDomainGetXMLDesc)
(bhyveDomainUndefine, bhyveDomainLookupByUUID)
(bhyveDomainLookupByName, bhyveDomainLookupByID)
(bhyveDomainCreateWithFlags, bhyveDomainOpenConsole):
Check if arg is not NULL before calling virObjectUnlock on it.

If you trigger bug 1033369, we get the error message:

  error from service: Invalid argument

Which is a bit too generic to pinpoint what is actually failing. This
changes it to:

  error from service: CreateMachine: Invalid argument
Acked-by: NEric Blake <eblake@redhat.com>

This is the only callsite.

We drop use of localerror.name here, because it's not actually useful
to us: rather than the parameter name which received an invalid value
(which was assumed), it's actually the the dbus errno equivalent.
Just use the error string.
Acked-by: NEric Blake <eblake@redhat.com>

I got a build failure when cross-compiling to mingw with the
mingw64-dbus package installed:

  CC       virmockdbus_la-virmockdbus.lo
../../tests/virmockdbus.c:29:6: error: 'dbus_connection_set_change_sigpipe' redeclared without dllimport attribute: previous dllimport ignored [-Werror=attributes]
 VIR_MOCK_STUB_VOID_ARGS(dbus_connection_set_change_sigpipe,
      ^
../../tests/virmockdbus.c:33:18: error: 'dbus_bus_get' redeclared without dllimport attribute: previous dllimport ignored [-Werror=attributes]
 VIR_MOCK_STUB_RET_ARGS(dbus_bus_get,
...

Well duh - mingw lacks dlopen and friends, even if it can support
dbus.  A similar failure occured in virsystemdtest.c; but in that
file, we know that systemd is a Linux-only concept.

* tests/virmockdbus.c: Cripple on mingw.
* tests/virsystemdtest.c: Cripple on non-Linux.
Signed-off-by: NEric Blake <eblake@redhat.com>

When doing an external checkpoint of a VM with no disk selected we'd
return failure but not set error code. This was a result of ret not
being set to 0 during walking of the disk array.

Rework early failure checking and set the error code to success before
iterating the array of disks so that we return success if no disks are
snapshotted.

Fixes the following symptom (or without --diskspec for diskless VMs)

 $ virsh snapshot-create-as snapshot-test  --memspec /tmp/asdf --diskspec hda,snapshot=no
 error: An error occurred, but the cause is unknown

If neither disks nor memory are selected for snapshot we'd record
metadata in case of external snapshot and do a disk snapshot in case of
external disk snapshot. Forbid this as it doesn't make much sense.

qemu's savevm command does a snapshot of all non readonly disks of a VM.
Libvirt though allowed disabling snapshot for certain disk of a VM.

Convert the switch to a typecasted value so that the compiler tracks
additions for us.

Support events for these functions:

 - domainDefineXML
 - domainUndefine
 - domainCreate{WithFlags,XML}
 - domainDestroy

For now, we set the migration URI via command line '--migrate_uri' or
construct the URI by looking up the dest host's hostname which could be
solved by DNS automatically.

But in cases the dest host have two or more NICs to reach, we may need to
send the migration data over a specific NIC which is different from the
automatically resolved one for some reason like performance, security, etc.
Thus we must explicitly specify the migrateuri in command line everytime,
but it is too troublesome if there are many such hosts (and don't forget
virt-manager).

This patch adds a configuration file option on dest host to save the
default value set which can be specified to a migration hostname or
one of this host's addresses used for transferring data, thus user doesn't
have to specify it in command line everytime.
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Inspired by a simpler patch from "Wangrui (K) <moon.wangrui@huawei.com>".

A submitted patch pointed out that virNetlinkCommand() was doing an
improper typecast of the return value from nl_recv() (int to
unsigned), causing it to miss error returns, and that even after
remedying that problem, virNetlinkCommand() was calling VIR_FREE() on
the pointer returned from nl_recv() (*resp) even if nl_recv() had
returned an error, and that in this case the pointer was verifiably
invalid, as it was pointing to memory that had been allocated by
libnl, but then freed prior to returning the error.

While reviewing this patch, I noticed several other problems with this
seemingly simple function (at least one of them as serious as the
problem being reported/fixed by the aforementioned patch), and decided
they all deserved to be fixed. Here is the list:

1) The return value from nl_recv() must be assigned to an int (rather
   than unsigned int) in order to detect failure.

2) When nl_recv() returns an error or 0, the contents of *resp is
   invalid, and should be simply set to 0, *not* VIR_FREE()'d.

3) When nl_recv() returns 0, errno is not set, so the logged error
   message should not reference errno (it *is* an error though).

4) The first error return from virNetlinkCommand returns -EINVAL,
   incorrectly implying that the caller can expect the return value to
   be of the "-errno" variety, which is not true in any other case.

5) The 2nd error return returns directly with garbage in *resp. While
   the caller should never use *resp in this case, it's still good
   practice to set it to NULL.

6) For the next 5 (!!) error conditions, *resp will contain garbage,
   and virNetlinkCommand() will goto it's cleanup code which will
   VIR_FREE(*resp), almost surely leading to a segfault.

In addition to fixing these 6 problems, this patch also makes the
following two changes to make the function conform more closely to the
style of other libvirt code:

1) Change the handling of return code from "named rc and defaulted to
0, but changed to -1 on error" to the more common "named ret and
defaulted to -1, but changed to 0 on success".

2) Rename the "error" label to "cleanup", since the code that follows
is executed in success cases as well as failure.

Commit d5c86278 was incomplete; other functions also triggered
compiler warnings about collisions in the use of 'sync'.

* src/qemu/qemu_driver.c (qemuDomainSetTime): Fix another client.
* tools/virsh-domain-monitor.c (cmdDomTime): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

Old gcc complains about shadowing 'sync' variable:

../../src/qemu/qemu_agent.c: In function 'qemuAgentSetTime':
../../src/qemu/qemu_agent.c:1737: warning: declaration of 'sync'
  shadows a global declaration [-Wshadow]
/usr/include/unistd.h:464: warning: shadowed declaration is here
  [-Wshadow]
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The commit 84c59ffa improved the way we change ejectable media.
If for any reason the first "eject" didn't open the tray we
should return with error.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This partially reverts commits b279e52f and ea18f8b2.

It turns out our code base is full of:

if ((struct.member = virBlahFromString(str)) < 0)
    goto error;

Meanwhile, the C standard says it is up to the compiler whether
an enum is signed or unsigned when all of its declared values
happen to be positive.  In my testing (Fedora 20, gcc 4.8.2),
the compiler picked signed, and nothing changed.  But others
testing with gcc 4.7 got compiler warnings, because it picked
the enum to be unsigned, but no unsigned value is less than 0.
Even worse:

if ((struct.member = virBlahFromString(str)) <= 0)
    goto error;

is silently compiled without warning, but incorrectly treats -1
from a bad parse as a large positive number with no warning; and
without the compiler's help to find these instances, it is a
nightmare to maintain correctly.  We could force signed enums
with a dummy negative declaration in each enum, or cast the
result of virBlahFromString back to int after assigning to an
enum value, or use a temporary int for collecting results from
virBlahFromString, but those actions are all uglier than what we
were trying to cure by directly using enum types for struct
values in the first place.  It's better off to just live with int
members, and use 'switch ((virFoo) struct.member)' where we want
the compiler to help, than to track down all the conversions from
string to enum and ensure they don't suffer from type problems.

* src/util/virstorageencryption.h: Revert back to int declarations
with comment about enum usage.
* src/util/virstoragefile.h: Likewise.
* src/conf/domain_conf.c: Restore back to casts in switches.
* src/qemu/qemu_driver.c: Likewise.
* src/qemu/qemu_command.c: Add cast rather than revert.
Signed-off-by: NEric Blake <eblake@redhat.com>

With dynamic_ownership = 1 but no seclabels, RestoreChardevLabel
dereferences the NULL seclabel when checking if norelabel is set.

Remove this check, since it is already done in RestoreSecurityAllLabel
and if norelabel is set, RestoreChardevLabel is never called.

Each VM consists of a set of files in PCS: config, hard
disk images, log file, memory dump. All these files are stored
in a per-vm directory. When we create a new VM, we can ether specify
path to the VM or create the VM in a default path
(<default path>/<vm name>.pvm). This default path can be configured
with command
prlsrvctl user set --def-vm-home <path> command.

Currenty parallels driver creates VM in the same place, where first
hard disk is located. Let's change this logic and create VMs in
the default path. It will be much clearer and allow us to create
VMs without hard disks.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Disks support in this driver was implemented with an assumption,
that disk images can't be created by hand, without VM. So
complex storage driver was implemented with workaround.

This is not true, we can create new disks using ploop tool.
So the first step to reimplement disks support in parallels
driver is to do not use information from the storage driver,
until we will implement VIR_STORAGE_TYPE_VOLUME disks.

So after this patch disks can be added in the same way as
in any other driver: you create a disk image and then add
an entry to the XML definition of the domain with path to that
image file, for example:

<disk type='file' device='disk'>
  <driver type='ploop'/>
  <source file='/storage/harddisk1.hdd'/>
  <target dev='sda' bus='sata'/>
  <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

This patch makes parallels storage driver useless, but I'll fix it
later. Now you can create an image by hand, using ploop tool,
and then add it to some domain.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Set file format in virDomainDef structure to produce correct
XML in virDomainGetXMLDesc function.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Add VIR_STORAGE_FILE_PLOOP format. This format is used
to store disk images for virtual machines in PCS and containers
in PCS, OpenVZ and also in Parallels Desktop for Mac.

This format is described on OpenVZ site -
https://openvz.org/Ploop (together with ploop devices). It
consists of XML descriptor and one or more image files: base
image and deltas. Format of the image files described here:
https://openvz.org/Ploop/format.

This patch only adds VIR_STORAGE_FILE_PLOOP constant, consequent
patches will use it in parallels driver.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

The domain definition is clearly used a few lines
below so there's no need to mark @def as unused.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We allow a seclabel to be specified in the <source> element
of a chardev:

<serial type='file'>
  <source path='/tmp/serial.file'>
    <seclabel model='dac' relabel='no'/>
  </source>
</serial>

But we format it outside the source:

<serial type='file'>
  <source path='/tmp/serial.file'/>
  <target port='0'/>
    <seclabel model='dac' relabel='no'/>
</serial>

Move the formatting inside the source to fix this to make the
seclabel persistent across XML format->parse.

Introduced by commit f8b08d0e 'Add <seclabel> to character devices.'

Drop the 'Disk' from the name, as there is nothing disk-specific
about the function.

The DAC driver ignores the relabel='no' attribute in chardev config

  <serial type='file'>
    <source path='/tmp/jim/test.file'>
      <seclabel model='dac' relabel='no'/>
    </source>
    <target port='0'/>
  </serial>

This patch avoids labeling chardevs when relabel='no' is specified.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

When relabel='no' at the domain level, there is no need to call
the hostdev relabeling functions.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

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

The DAC driver ignores the relabel='no' attribute in disk config

  <disk type='file' device='floppy'>
    <driver name='qemu' type='raw'/>
    <source file='/some/path/floppy.img'>
      <seclabel model='dac' relabel='no'/>
    </source>
    <target dev='fda' bus='fdc'/>
    <readonly/>
  </disk>

This patch avoid labeling disks when relabel='no' is specified.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

If relabel='no' at the domain level, no need to attempt relabeling
in virSecurityDAC{Set,Restore}SecurityAllLabel().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>