It seems file format is usually specified event for
real block devices. So report that file format is
raw in virDomainGetXMLDesc and add checks for proper
file format to prlsdkAddDisk.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

NULL value of virDomainVideoAccelDefPtr means default
values for video acceleration, so don't report error in
this case.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

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

When we use attach-device add a hostdev or chr device which have a
iscsi address or others (just like guest agent, subsys iscsi disk...),
we will find there is no basic controller for our new attached device.
Somtimes this will make guest cannot start after we add them (although
they can start at the second time).
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

When libvirt is managing a bridge's forwarding database (FDB)
(macTableManager='libvirt'), if we add FDB entries for a new guest
interface even before the qemu process is created, then in the case of
a migration any other guest attached to the "destination" bridge will
have its traffic immediately sent to the destination of the migration
even while the source domain is still running (and the destination, of
course, isn't). To make sure that traffic from other guests on the new
host continues flowing to the old guest until the new one is ready, we
have to wait until the new guest CPUs are started to add the FDB
entries.

Conversely, we need to remove the FDB entries from the bridge any time
the guest CPUs are stopped; among other things, this will assure
proper operation during a post-copy migration (which is just the
opposite of the problem described in the previous paragraph).

We can change vnc password by using virDomainUpdateDeviceFlags API with
live flag. But it can't be changed with config flag. Error is reported as
below.

error: Operation not supported: persistent update of device 'graphics' is not supported

This patch supports the graphics arguments changed with config flag.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

It's not supported to change some graphics arguments with '--live'.
Replace some error code VIR_ERR_INTERNAL_ERROR and VIR_ERR_INVALID_ARG
with VIR_ERR_OPERATION_UNSUPPORTED.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

The original code always checked *boot which was in effect boot[0]. It
should use boot[i].
Signed-off-by: NWei Liu <wei.liu2@citrix.com>

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

When both parameter have lockspaces present, virDomainLeaseIndex
always returns -1 even there is a lease the same with the one we
check. This is due to broken logic in 'if-else' statement.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

It occurred to me that OpenStack uses the following XML when not using
regular huge pages:

  <memoryBacking>
    <hugepages>
      <page size='4' unit='KiB'/>
    </hugepages>
  </memoryBacking>

However, since we are expecting to see huge pages only, we fail to
startup the domain with following error:

  libvirtError: internal error: Unable to find any usable hugetlbfs
  mount for 4 KiB

While regular system pages are not huge pages technically, our code is
prepared for that and if it helps OpenStack (or other management
applications) we should cope with that.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Introduced by commit id '17bddc46' - fix a libvirtd crash when
matching a network iscsi hostdev with a host iscsi hostdev.

When we use attach-device to coldplug a network iscsi hostdev,
libvirt will check if there is already a device in XML. But if
the 'b' is a host iscsi hostdev and 'a' is a network iscsi hostdev,
then libvirtd will crash in virDomainHostdevMatchSubsysSCSIiSCSI
because 'b' doesn't have a hostname.

Add a check in virDomainHostdevMatchSubsys, if the a's protocol
and b's protocol is not the same.

Following is the backtrace:

0  0x00007f850d6bc307 in virDomainHostdevMatchSubsysSCSIiSCSI at conf/domain_conf.c:10889
1  virDomainHostdevMatchSubsys at conf/domain_conf.c:10911
2  virDomainHostdevMatch at conf/domain_conf.c:10973
3  virDomainHostdevFind at conf/domain_conf.c:10998
4  0x00007f84f6a10560 in qemuDomainAttachDeviceConfig at qemu/qemu_driver.c:7223
5  qemuDomainAttachDeviceFlags at qemu/qemu_driver.c:7554
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

fix typo introduced in previous commit

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

In our config files users are expected to pass several integer values
for different configuration knobs. However, majority of them expect a
nonnegative number and only a few of them accept a negative number too
(notably keepalive_interval in libvirtd.conf).
Therefore, a new type to config value is introduced: VIR_CONF_ULONG
that is set whenever an integer is positive or zero. With this
approach knobs accepting VIR_CONF_LONG should accept VIR_CONF_ULONG
too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There's no need to implement ToString() function like we do if we
can use our shiny macros.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There's no need for condition of the following form:

  if (str && STREQ(str, dst))

since we have STREQ_NULLABLE macro that handles NULL cases.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

For historical reasons, only the first <console> element might be of targetType
serial, but we checked for other consoles of targetType serial in our post-parse
callback if and only if we knew the first console was serial, otherwise
the check was skipped.
This patch moves the check one level up, so first
the check for secondary console of type serial is performed and then the
rest of operations continue unchanged.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1170092

We now have a qemuInterfaceStartDevices() which does the final
activation needed for the host-side tap/macvtap devices that are used
for qemu network connections. It will soon make sense to have the
converse qemuInterfaceStopDevices() which will undo whatever was done
during qemuInterfaceStartDevices().

A function to "stop" a single device has also been added, and is
called from the appropriate place in qemuDomainDetachNetDevice(),
although this is currently unnecessary - the device is going to
immediately be deleted anyway, so any extra "deactivation" will be for
naught. The call is included for completeness, though, in anticipation
that in the future there may be some required action that *isn't*
nullified by deleting the device.

This patch is a part of a more complete fix for:

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

The patch that added qemuInterfaceStartDevices() (upstream commit
82977058) had an extra conditional to
prevent calling it if the reason for starting the CPUs was
VIR_DOMAIN_RUNNING_UNPAUSED or VIR_DOMAIN_RUNNING_SAVE_CANCELED.  This
was put in by the author as the result of a reviewer asking if it was
necessary to ifup the interfaces in *all* occasions (because these
were the two cases where the CPU would have already been started (and
stopped) once, so the interface would already be ifup'ed).

It turns out that, as long as there is no corresponding
qemuInterfaceStopDevices() to ifdown the interfaces anytime the CPUs
are stopped, neglecting to ifup when reason is RUNNING_UNPAUSED or
RUNNING_SAVE_CANCELED doesn't cause any problems (because it just
happens that the interface will have already been ifup'ed by a prior
call when the CPU was previously started for some other reason).

However, it also doesn't *help*, and there will soon be a
qemuInterfaceStopDevices() function which *will* ifdown these
interfaces when the guest CPUs are stopped, and once that is done, the
interfaces will be left down in some cases when they should be up (for
example, if a domain is paused and then unpaused).

So, this patch is removing the condition in favor of always calling
qemuInterfaeStartDevices() when the guest CPUs are started.

This patch (and the aforementioned patch) resolve:

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

When one domain is being undefined and at the same time started, for
example, there is a possibility of a rare problem occuring.

 - Thread 1 does virDomainUndefine(), has the lock, checks that the
   domain is active and because it's not, calls
   virDomainObjListRemove().

 - Thread 2 does virDomainCreate() and tries to lock the domain.

 - Thread 1 needs to lock domain list in order to remove the domain from
   it, but must unlock domain first (proper order is to lock domain list
   first and the domain itself second).

 - Thread 2 grabs the lock, starts the domain and releases the lock.

 - Thread 1 grabs the lock and removes the domain from list.

With this patch:

 - The undefining domain gets marked as "to undefine" before it is
    unlocked.

 - If domain is found in any of the search APIs, it's returned only if
   it is not marked as "to undefine".  The check is done while the
   domain is locked.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1150505Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

It make no sense at all to have it there.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

- docs/news.html.in libvirt.spec.in: update for release
- po/*.po*: updated localization and regenerated

When calling virCgroupAllowAllDevices we get these invalid entries
in the device cgroup config.
    b -1:-1 rw
    c -1:-1 rw
Check for positive values before outputting the major and minor to
avoid that.

Output error when we try to set a too large max_sectors.
Just like queues and cmd_per_lun here.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

This fixes reverting to snapshots created by older libvirt
and allows libvirt not to lose track of a domain that
has this in its live status XML (such as a domain
restored from managedsave)

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

For host-passthrough CPU we don't honor the CPU
features specified in the XML, but we allow
outputting them via the UPDATE_CPU flag for dumpxml,
this gives user a rough idea of what features the CPU
might have.

After restoring a managedsave'd domain, the features
might end up in the live status XML (in /var/run) without
the model. This XML cannot be parsed by the daemon after
restart and the domain might disappear.

This fix skips formatting the features for HOST_PASSTHROUGH
when UPDATE_CPU is not specified, so the newly restored domains
and newly created snapshots won't be affected.

Note: this doesn't fix existing snapshots or already restored
running domains.

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

Add missing ATTRIBUTE_UNUSED markers.

A logic bug in qemuConnectGetAllDomainStats makes the code mark the
monitor as available when qemuDomainObjBeginJob fails, instead of when
it succeeds, as the correct flow requires.

This patch fixes the check and updates the code documentation
accordingly.

Broken by commit 57023c0a.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>

When using qemuProcessAttach to attach a qemu process,
the DAC label is not filled correctly.

Introduce a new function to get the uid:gid from the system
and fill the label.

This fixes the daemon crash when 'virsh screenshot' is called:
https://bugzilla.redhat.com/show_bug.cgi?id=1161831

It also fixes qemu-attach after the prerequisite of this patch
(commit f8c1fb3d) was pushed out of order.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Currently, MAC registration occurs during device creation, which is
early enough that, during live migration, you end up with duplicate
MAC addresses on still-running source and target devices, even though
the target device isn't actually being used yet.
This patch proposes to defer MAC registration until right before
the guest can actually use the device -- In other words, right
before starting guest CPUs.
Signed-off-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: NLaine Stump <laine@laine.org>

Commit id 'c9ffd3ea' updated the descriptions, but pointed at the
wrong place for the pool-define-as (it should have been pool-create-as)

Some programs want to change some values for the network interfaces
configuration in /proc/sys/net/ipv[46] folders. Giving RW access on them
allows wicked to work on openSUSE 13.2+.

Reusing the lxcNeedNetworkNamespace function to tell
lxcContainerMountBasicFS if the netns is disabled. When no netns is
set up, then we don't mount the /proc/sys/net/ipv[46] folder RW as
these would provide full access to the host NICs config.

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

The refactoring done as part of commit id '59446096' caused a regression
for the multi initiator IQN commit '6aabcb5b' because the sendtargets was
not done on/for the initiator IQN prior to login (or trying to disable
autologin)

Prior to that commit, the paths were essentially

virStorageBackendISCSIStartPool
    virStorageBackendISCSILogin
        virStorageBackendISCSIConnection
            if initiatoriqn
                virStorageBackendCreateIfaceIQN
                Issue sendtargets
                Perform --login
            else
                Issue sendtargets
                Perform --login

After that commit:

virStorageBackendISCSIStartPool
    Issue sendtargets
    Call virStorageBackendISCSIConnection
        If initiatoriqn
            virStorageBackendCreateIfaceIQN
            Perform --login
        else
            Perform --login

So for non initiator IQN paths, nothing changed. For the initiator path,
the --login fails as does any attempts to change autologin via "--op update
--name node.startup --value manual".

It make no sense at all to have it there.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

Signed-off-by: NHao Liu <hliu@redhat.com>

In old version of parted like parted-2.1-25, error message is shown in
stdout when printing a disk info without disk label.

    Error: /dev/sda: unrecognised disk label

This line has been moved to stderr in newer version of parted. So we
should check both stdout and stderr when locating this message.

This should fix bug:
    https://bugzilla.redhat.com/show_bug.cgi?id=1172468Signed-off-by: NHao Liu <hliu@redhat.com>

When user doesn't have read access on one of the domains he requested,
the for loop could exit abruptly or continue and override pointer which
pointed to locked object.

This patch fixed two issues at once.  One is that domflags might have
had QEMU_DOMAIN_STATS_HAVE_JOB even when there was no job started (this
is fixed by doing domflags |= QEMU_DOMAIN_STATS_HAVE_JOB only when the
job was acquired and cleaning domflags on every start of the loop.
Second one is that the domain is kept locked when
virConnectGetAllDomainStatsCheckACL() fails and continues the loop when
it didn't end.  Adding a simple virObjectUnlock() and clearing the
pointer ought to do.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

If we want to perform some operation and domain state is not suitable
for that operation, we should report error VIR_ERR_OPERATION_INVALID.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>