There's this function virNetDevBandwidthParse which parses the
bandwidth XML snippet. But it's not clever much. For the
following XML it allocates the virNetDevBandwidth structure even
though it's completely empty:

    <bandwidth>
    </bandwidth>

Later in the code there are some places where we check if
bandwidth was set or not. And since we obtained pointer from the
parsing function we think that it is when in fact it isn't.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The virDomainDefParse* and virDomainDefFormat* methods both
accept the VIR_DOMAIN_XML_* flags defined in the public API,
along with a set of other VIR_DOMAIN_XML_INTERNAL_* flags
defined in domain_conf.c.

This is seriously confusing & error prone for a number of
reasons:

 - VIR_DOMAIN_XML_SECURE, VIR_DOMAIN_XML_MIGRATABLE and
   VIR_DOMAIN_XML_UPDATE_CPU are only relevant for the
   formatting operation
 - Some of the VIR_DOMAIN_XML_INTERNAL_* flags only apply
   to parse or to format, but not both.

This patch cleanly separates out the flags. There are two
distint VIR_DOMAIN_DEF_PARSE_* and VIR_DOMAIN_DEF_FORMAT_*
flags that are used by the corresponding methods. The
VIR_DOMAIN_XML_* flags received via public API calls must
be converted to the VIR_DOMAIN_DEF_FORMAT_* flags where
needed.

The various calls to virDomainDefParse which hardcoded the
use of the VIR_DOMAIN_XML_INACTIVE flag change to use the
VIR_DOMAIN_DEF_PARSE_INACTIVE flag.

The virCPUDefFormat* methods were relying on the VIR_DOMAIN_XML_*
flag definitions. It is not desirable for low level internal
functions to be coupled to flags for the public API, since they
may need to be called from several different contexts where the
flags would not be appropriate.

Well, since the link to the virConnectGetDomainCapabilities API is in
<pre/> section we must take special care about the spaces around the
link.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1135339 documents some
confusing behavior when a user tries to start an inactive block
commit in a second connection while there is already an on-going
active commit from a first connection.  Eventually, qemu will
support multiple simultaneous block jobs, but as of now, it does
not; furthermore, libvirt also needs an overhaul before we can
support simultaneous jobs.  So, the best way to avoid confusing
ourselves is to quit relying on qemu to tell us about the situation
(where we risk getting in weird states) and instead forbid a
duplicate block commit ourselves.

Note that we are still relying on qemu to diagnose attempts to
interrupt an inactive commit (since we only track XML of an active
commit), but as inactive commit is less confusing for libvirt to
manage, there is less that can go wrong by leaving that detection
up to qemu.

* src/qemu/qemu_driver.c (qemuDomainBlockCommit): Hoist check for
active commit to occur earlier outside of conditions.
Signed-off-by: NEric Blake <eblake@redhat.com>

The virDomainDefParseString method will report a suitable error
on parsing fail, so don't replace that.

The XenAPI driver was passing the flags for
virDomainCreateXML straight into the virDomainDefParseString
method, even though they expect totally different sets of
flags. It should have been using VIR_DOMAIN_XML_INACTIVE

The VIR_DOMAIN_XML_SECURE flag only has effect on the formatting
of XML so should not be passed to virDomainDefParseNode

Make sure every virt driver implements virDomainDefineXMLFlags
by adding a trivial passthrough from the existing impl with
no flags set.

The virDomainDefineXML method is one of the few that still lacks
an 'unsigned int flags' parameter. This will be needed for adding
XML validation to this API. virDomainCreateXML fortunately already
has flags.

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

When we try to hotplug a channel chr device with no target, we
will get success (which should fail) in virDomainChrDefParseXML,
because we use goto cleanup this place and return an incomplete
definition (with no target). In qemuDomainAttachChrDevice,
we add it to the domain definition, but fail to remove it from
there when chardev-add fails, because virDomainChrRemove
matches chardevices according to the target name.
The device definition is then freed in qemuDomainAttachDeviceFlags,
leaving a stale pointer in the domain definition.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

QEMU supports feature specification with -cpu host and we just skip
using that.  Since QEMU developers themselves would like to use this
feature, this patch modifies the code to work.

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

This reverts commit 2c78051a.

Conflicts:
	src/Makefile.am
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This reverts commit 6b818d3b.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This reverts commit 4f524212.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This reverts commit 703ef966.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This reverts commit 1b21d300.

Conflicts:
	src/Makefile.am
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This reverts commit e662968f.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This reverts commit edacdb3d.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This reverts commit 533349ff.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This reverts commit cab76783.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

so it applies to interfaces of type 'direct' too.

Reported and patch provided by Bastian Blank at

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769600

Well, apparently it's possible for a patch to sneak in through
review process and break 'make check'. It happened just lately
with 0e502466 which changed the default of vgamem_mb for
qxl device. However, there were left some domain XMLs within our
test suite relying on the old default. These should be updated to
match the change.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The curent libvirt CPU driver for s390 does not return a host CPU model.
This patch returns 'host' according to the other platforms that would
not decode any CPU model.
This is an intermediate bugfix due to a discussion on OpenStack mailing
list. The final patch introducing the CPU model support for s390x will
exchange the hard-coded decode method.
Signed-off-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>

Found this one by inspection... The API claims to "own" the input
value even in the case of error.  However, in the initial entry
to the API if the value exists, was STRING, but without a str value
it just returned without freeing the 'value' which it claims to now
own.  So I added the virConfFreeValue() call in order to resolve.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id 'a4e86390' modified the command line to allow --ipadd multiple
times; however, it did not account for the condition where a NULL is
returned which will could lead to some interesting errors with multiple
--ipadd's without parameters.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit id 'a4e86390' modified the command line to allow --ipadd multiple
times, which caused Coverity to notice a latent memory leak with the
'ipAddr' string not being VIR_FREE()'d
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The default value should be 16 MiB instead of 8 MiB. Only really old
version of upstream QEMU used the 8 MiB as default for vga framebuffer.

Without this change if you update your libvirt where we introduced the
"vgamem" attribute for QXL video device the value will be set to 8 MiB,
but previously your guest had 16 MiB because we didn't pass any value to
QEMU command line which means QEMU used its own 16 MiB as default.

This will affect all users with guest's display resolution higher than
1920x1080.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

It was brought to my attention that some -boot options may not
work with UEFI. For instance, rebootTimeout is very SeaBIOS
specific,splash logo is not implemented yet on OVMF, and so on.
We should document this limitation at least.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 6b9964 enforces checking invalid use of VSH_OT_STRING with
VSH_OFLAG_REQ. This commit tries to do the same thing to stop using
VSH_OT_DATA without VSH_OFLAG_REQ and also fix existing misuse.
Signed-off-by: NHao Liu <hliu@redhat.com>

Reported and patch provided by Bastian Blank at

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769600

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

The way that we currently generate the <driver/> for <controller/> is
just madness:

    <controller type='scsi' index='0' model='virtio-scsi'>
      <driver queues='12'/>
      <driver cmd_per_lun='123'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>

It's obvious that we should be aiming at the following:

    <controller type='scsi' index='0' model='virtio-scsi'>
      <driver queues='12' cmd_per_lun='123'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Remove the resize flag and use the same code path for all callers.
This flag was added by commit 18f03166 to allow virStorageFileResize
use 'safezero' while preserving the behavior.

Explicitly return -2 when a fallback to a different method should
be done, to make the code path more obvious.

Fail immediately when ftruncate fails in the mmap method,
as we did before commit 18f03166.

The 'pool-build' command description for --overwrite and --no-overwrite
indicated usage for only 'filesystem' pools; however, the 'disk' pool
also supports the flags as of commit id 'afa1029a'. So add a description
for that usage.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

I noticed this while working on a previous commit.  Why should
we be calling out '../src/' when it is sufficient to refer to just
'./'?  Blind copy-and-paste runs rampant in this file :)

* src/Makefile.am (INCLUDES, *_CFLAGS): Shorten to $(srcdir).
Signed-off-by: NEric Blake <eblake@redhat.com>

We need the flex to generate new xen_xl_disk parser.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Well, the parallel build doesn't work as there are not dependencies
set correctly. When running 'make -j' I see this error:

make[2]: Entering directory '/home/zippy/work/libvirt/libvirt.git/src'
  GEN      util/virkeymaps.h
  GEN      locking/lock_protocol.h
make[2]: *** No rule to make target 'xenconfig/xen_xl_disk.h', needed by 'all'.  Stop.
make[2]: *** Waiting for unfinished jobs....
  GEN      lxc/lxc_controller_dispatch.h

The fix is to correctly set dependencies by letting make know that .c
and .h are to be generated from .l. Moreover, the section is moved
closer to the other section which uses it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

This reverts commit 703ef966.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

VMware ESX does not always set the "serialX.fileType" tag in VMX files. The
default value for this tag is "device", and when adding a new serial port
of this type VMware will omit the fileType tag. This caused libvirt to
fail to parse the VMX file. Fixed by making this tag optional and using
"device" as a default value. Also updated vmx2xmltest to test for this
case.
Signed-off-by: NEric Blake <eblake@redhat.com>