virDomainLiveConfigHelperMethod that is used for this job now does
modify the flags but still requires the callers to extract the correct
definition objects.

In addition coverity and other static analyzers are usually unhappy as
they don't grasp the fact that @flags are upadted according to the
correct def to be present.

To work this issue around and simplify the calling chain let's add a new
helper that will work only on drivers that always copy the persistent
def to a transient at start of a vm. This will allow to drop a few
arguments. The new function syntax will also fill two definition
pointers rather than modifying the @flags parameter.

While we probably won't see machines with more than 65536 cpus for a
while lets store the cpu count as an integer so that we can avoid quite
a lot of overflow checks in our code.

We have been formatting the first serial device also
as a console device, but only if there were no other consoles.

If there is a <serial> device present in the XML, but no serial
<console>, or if there isn't any <console> at all but the domain
definition hasn't gone through a parse->format->parse round-trip,
the <console> device would not be formatted.

Change the code to always add the stub device for the first
serial device.

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

Console/channel devices have their pty devices assigned when the emulator is
actually started. If time is spent in guest preparation, someone attempts
to open the console/channel, the libvirt crashes in virChrdevLockFilePath().
The patch attempts to fix the crash by adding a check before attempting to
open.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>

Store the emulator pinning cpu mask as a pure virBitmap rather than the
virDomainPinDef since it stores only the bitmap and refactor
qemuDomainPinEmulator to do the same operations in a much saner way.

As a side effect virDomainEmulatorPinAdd and virDomainEmulatorPinDel can
be removed since they don't add any value.

As soon as we keep backward compatibility we treat this constant
as synonym to VIR_DOMAIN_VIRT_PARALLELS.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

This new name and constant will be used as substitutions for parallels driver one.
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>

If the domain has IOThreads defined, then audit the number started
at domain startup time.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

There are now many more reasons that virSocketAddrGetRange() could
fail, so it is much more informative to report the error there instead
of in the caller. (one of the two callers was previously assuming
success, which is almost surely safe based on the parsing that has
already happened to the config by that time, but it still is nicer to
account for an error "just in case")

Part of fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653

virSocketAddrGetRange() has been updated to take the network address
and prefix, and now checks that both the start and end of the range
are within that network, thus validating that the entire range of
addresses is in the network. For IPv4, it also checks that ranges to
not start with the "network address" of the subnet, nor end with the
broadcast address of the subnet (this check doesn't apply to IPv6,
since IPv6 doesn't have a broadcast or network address)

Negative tests have been added to the network update and socket tests
to verify that bad ranges properly generate an error.

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=985653

Use xmlFreeDoc instead of plain xmlFree.

4 bytes in 1 blocks are definitely lost in loss record 9 of 1,084
    at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x70730D6: xmlStrndup (in /usr/lib64/libxml2.so.2.9.2)
    by 0x701E3DC: xmlNewDoc (in /usr/lib64/libxml2.so.2.9.2)
    by 0x70C39F8: xmlSAX2StartDocument (in /usr/lib64/libxml2.so.2.9.2)
    by 0x7017245: xmlParseDocument (in /usr/lib64/libxml2.so.2.9.2)
    by 0x7017606: xmlDoRead (in /usr/lib64/libxml2.so.2.9.2)
    by 0x5309DAD: virXMLParseHelper (virxml.c:742)
    by 0x5367584: virStoragePoolLoadState (storage_conf.c:1863)

It's not a problem at all and causes virt-manager to break down.

Note: netcf 0.2.8 and earlier generates invalid XML for a bond with no
interfaces anyway, so in that case this error in libvirt is never
reached since we fail earlier.
Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>

If the redirfilter has no usbdev sub-elements, then do not format anything
rather than formatting an empty pair of elements:

    <redirfilter>
    </redirfilter>
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Commit id '73eda710' added virDomainKeyWrapDefParseXML which uses
virXPathNodeSet, but does not handle a -1 return thus causing a possible
loop condition exit problem later when the return value is used.

Change the logic to return the value from virXPathNodeSet if <= 0

The XML parser sets a default <mode> if none is explicitly passed in.
This is then used at pool/vol creation time, and unconditionally reported
in the XML.

The problem with this approach is that it's impossible for other code
to determine if the user explicitly requested a storage mode. There
are some cases where we want to make this distinction, but we currently
can't.

Handle <mode> parsing like we handle <owner>/<group>: if no value is
passed in, set it to -1, and adjust the internal consumers to handle
it.

Even though it's been pointed out they are false positives:

http://www.redhat.com/archives/libvir-list/2015-May/msg00301.html

and

http://www.redhat.com/archives/libvir-list/2015-May/msg00302.html

these still show up as Coverity issues. In order to silence Coverity
add an 'sa_assert' prior to check failure.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

-1 is just an internal placeholder and is meaningless to output in the XML.

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

Like usb-serial, the pci-serial device allows a serial device to be
attached to PCI bus. An example XML looks like this:

  <serial type='dev'>
    <source path='/dev/ttyS2'/>
    <target type='pci-serial' port='0'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
  </serial>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Sometimes the only thing we need is the pointer to virDomainDiskDef and
having to call virDomainDiskIndexBy* APIs, storing the disk index, and
looking it up in the disks array is ugly. After this patch, we can just
call virDomainDiskBy* and get the pointer in one step.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

After parsing the memory device XML the function would not restore the
XML parser context causing invalid XPath starting point for the rest of
the elements. This is a regression since 3e4230d2.

The test case addition uses the <idmap> element that is currently unused
by qemu, but parsed after the memory device definition and formatted
always.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1223631Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

virDomainParseMemory parses the size and then rounds up while converting
it to kibibytes. Since the number is limit-checked before the rounding
it's possible to use a number that would be correctly parsed the first
time, but not the second time. For numbers not limited to 32 bit systems
the magic is 9223372036854775807 bytes. That number then can't be parsed
back in kibibytes.

To solve the issue add a second overflow check for the few values that
would cause the problem. Since virDomainParseMemory is used in config
parsing, this avoids vanishing VMs.

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

So far, we are not reporting if numatune was even defined. The
value of zero is blindly returned (which maps onto
VIR_DOMAIN_NUMATUNE_MEM_STRICT). Unfortunately, we are making
decisions based on this value. Instead, we should not only return
the correct value, but report to the caller if the value is valid
at all.

For better viewing of this patch use '-w'.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

For a domain configured using the host cdrom, we should taint the domain
due to problems encountered when the host and guest try to control the tray.

For some reason a union (_virNodeDevCapData) that had only been
declared inside the toplevel struct virNodeDevCapsDef was being used
as an argument to functions all over the place. Since it was only a
union, the "type" attribute wasn't necessarily sent with it. While
this works, it just seems wrong.

This patch creates a toplevel typedef for virNodeDevCapData and
virNodeDevCapDataPtr, making it a struct that has the type attribute
as a member, along with an anonymous union of everything that used to
be in union _virNodeDevCapData. This way we only have to change the
following:

  s/union _virNodeDevCapData */virNodeDevCapDataPtr /

and

  s/caps->type/caps->data.type/

This will make me feel less guilty when adding functions that need a
pointer to one of these.

Two new domain configuration XML elements are added to enable/disable
the protected key management operations for a guest:

    <domain>
      ...
      <keywrap>
        <cipher name='aes|dea' state='on|off'/>
      </keywrap>
      ...
    </domain>
Signed-off-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com>
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Signed-off-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Because there are multiple potential reasons for an error, this
function logs any errors before returning NULL (since the caller won't
have the information needed to determine which was the reason for
failure).

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

And move it to qemu_domain.[ch] because this API is QEMU-only.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The APIs take the memory value in KiB and we store it in KiB
internally, but we cannot parse the whole ULONG_MAX range
on 64-bit systems, because virDomainParseScaledValue
needs to fit the value in bytes in an unsigned long long.

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

Since 'autofill'd iothreadid entries are not written during XML format
processing, it is possible that if an iothreadid in the middle of an
autofilled list would then change it's id on a subsequent restart.

Thus during the iothreadid deletion, if we determine the delete is not
the "last" thread, then clear the autofill bit for all iothreadid's
following the one being deleted (either the first or one in the middle).
This way, iothreadid's will be printed/saved.

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

Remove the check for the source host name for iSCSI source XML processing
declaring duplicate sources when the source device path and if present the
initiator of a proposed storage pool matches an existing storage pool.

The backend iSCSI storage driver uses 'iscsiadm --mode session' to query
available iscsid target sessions. The output displayed is the IP address
and the IQN (target path) of known targets. The displayed IP address
is a resolved address based on the session --login. Additionally, iscsid
keeps track of the various ways to define the host name (IPv4 Address,
IPv6 Address, /etc/hosts, etc.) for that IQN (see output of an 'iscsiadm
--mode node'). If an incoming IQN matches and the host name provided by
libvirt is resolved to the existing IQN, then iscsid will "reuse" the
session. Although libvirt could do the same name resolution, if there
is a difference, iscsid could still declare two seemingly different sources
to be the same and not create a new session which means libvirt now has
two storage pools looking at the same source. Thus to avoid any strange
host name resolution issues, just rely on iscsid for that and do not
allow multiple pools on the same host to use the same device path (IQN).

Only perform the port number check if the incoming definition actually
provides it. Since the port number is optional we could erroneously pass
a duplicate source host check since some storage pool backends which fill
in the default port number (e.g., iSCSI and sheepdog) for the started pool.

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

There is a lot of places, were it's pretty easy for user to enter some
characters that we need to escape to create a valid XML description.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1197580Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

Passing the return value to an enum directly is not safe.  Fix this by
comparing the true integer result of virTristateSwitchTypeFromString().
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

To avoid having the ballooned memory size larger than the actual
physical memory size, truncate the ballooned size if it overflows.