As soon as we keep backward compatibility we treat this constant
as synonym to VIR_DOMAIN_VIRT_PARALLELS.
Signed-off-by: Maxim Nestratov <mnestratov@parallels.com>
Commit id '980b265d' neglected to check for a successful status when
deciding whether to release the device address for the RNG attach thus
the address would be released even though the device was added.
Signed-off-by: Luyao Huang <lhuang@redhat.com>
Commit id '862473fa' neglected to return the status from the
qemuDomainRemoveRNGDevice call in qemuDomainRemoveDevice causing
the function to always fail when receiving an RNG device unplug
event. Additionally the domain status/state would not be updated
in the processDeviceDeletedEvent path.
Signed-off-by: Luyao Huang <lhuang@redhat.com>
Newer binutils 'ar' has added an option 'D' for deterministic
builds, and at least on rawhide, this option is enabled by default.
But it conflicts with the 'u' optimization where the linker only
modifies libraries based on file timestamps, but can result in
different library ordering based on which files were touched last.
Thus, it results in some noisy compilation, for every CCLD line:
CCLD libvirt_driver_qemu_impl.la
ar: `u' modifier ignored since `D' is the default (see `U')
Upstream automake has decided that defaulting ARFLAGS to 'cru' is
no longer beneficial, and that switching the default to 'cr' will
both silence the noise and not penalize modern build systems.
https://lists.gnu.org/archive/html/automake-patches/2015-06/msg00000.html
But rather than wait for newer automake to propagate to all systems
that already have newer binutils, we might as well just use the new
default ourselves, even on older platforms.
* configure.ac: Default AR[_]FLAGS to 'cr', not 'cru'.
Signed-off-by: Eric Blake <eblake@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
This loop had automatic variable definitions mixed with code. This
patch moves the definitions to the top of the function and puts
cleanup for them at the bottom. No functional change.
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
This was revealed when I made a cut-paste mistake in an upgrade to
virSocketAddrGetRange(), leading to failure to check for the end
address being outside of the defined network, but a negative test case
that should have caught the error instead returned success.
The problem was that testRange in sockettest.c was written so that
when it expected a failure, even an "unexpected success" would be
considered as an "expected failure" because of the way the check in
testRange was done. testRange had this:
if (gotsize < 0 || gotsize != size) {
return pass ? -1 : 0;
} else {
return pass ? 0 : -1;
}
but all the tests that expected a failure give "-1" as the expected
size. So in a case where we expect a failure, we would have pass ==
false and size == -1. If virSocketAddrGetRange() was incorrectly
*successful* (returned some positive number), then "gotsize != size"
would be, e.g. "276 != -1", so we would take the if clause and, since
pass == false, we would return 0 (success i.e. expected failure).
The solution is that in the case where we expect failure, we should
just ignore size - virSocketAddrGetRange() must return -1 in order for
us to report "expected failure == success".
Part of fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653
This will allow us to use vshError() to report errors from inside
vshCommandOpt*(), instead of replicating the same logic and error
messages all over the place.
We also have more context inside the vshCommandOpt*() functions,
for example the actual value used on the command line, which means
we can produce more detailed error messages.
vshCommandOptBool() is the exception here, because it's explicitly
designed not to report any error.
The new tests deal with numeric options of three kinds: regular,
scaled and timeouts. For each, both valid and invalid inputs
are provided, hopefully covering all cases: this should allow us
to avoid regressions when changing the relevant code in virsh.
We do update pool volume object list before we actually create any
volume. If buildVol fails, we then try to delete the volume in the
storage as well as remove it from our structures. The problem is, that
any backend that supports both buildVol and deleteVol would fail in this
case which is completely unnecessary. This patch causes the update to
take place after we know a volume has been created successfully, thus no
removal in case of a buildVol failure is necessary.
https://bugzilla.redhat.com/show_bug.cgi?id=1223177
We allocate 16 bytes for IPv4 address and 55 bytes for interface
key, therefore we should read up to 15/54 bytes and let the last byte
reserved for terminating null byte in sscanf.
https://bugzilla.redhat.com/show_bug.cgi?id=1226400
Incorporates fixes for cross-compiling to mingw on rawhide, where
gcc 5.1 changes detection of how to properly determine PRIdMAX.
Also picks up some improvements for compilation on Mac OS X.
* .gnulib: Update to latest, for at least mingw.
Signed-off-by: Eric Blake <eblake@redhat.com>
Commit 198cc1d3 introduced libxl-lockd and libxl-sanlock config
files but forgot to add them to the spec file. Follow-up commit
62b18d98 added the files to daemon-driver-libxl, but missed adding
them to the daemon package when configuring libvirt
--without-driver-modules. In addition, commit 62b18d98 added
libxl-sanlock to daemon-driver-libxl, but it should be included
in lock-sanlock when libvirt is configured --with-sanlock.
The libxl tries to check if it's running in dom0 by parsing
/proc/xen/capabilities and if that fails it doesn't load.
There's no procfs interface in Xen on FreeBSD, so this check always
fails.
In addition to checking procfs, check if /dev/xen/xenstored, that's enough to
check if we're running in dom0 in FreeBSD case.
When shrinking a volume by a certain size, instead of typing
vol-resize volume 1G --delta --shrink
we allow the convience of specifying a negative value:
vol-resize volume -1G --delta --shrink
getting the same results with one more character.
A negative value only makes sense as a delta. Imply the
--delta parameter if the value is negative.
Still require --shrink, because the operation is potentially
destructive.
The guest firmware provides the same functionality as the pvpanic
device, and the relevant element should always be present in the
domain XML to reflect this fact, so add it after parsing the
definition if it wasn't there already.
The guest firmware provides the same functionality as the pvpanic
device, which is not available in QEMU on pSeries, so the domain
XML should be allowed to contain the <panic> element.
On the other hand, unlike the pvpanic device, the guest firmware
can't be configured, so report an error if an address has been
provided in the XML.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1182388
https://bugzilla.redhat.com/show_bug.cgi?id=1224088
commit id 'bd00e00e' neglected to add the new adapter source options
into the if condition that allowed printing the <source> XML fields.
The <adapter type='fc_host'.../> doesn't require other options in order
to be complete.
When attempting to hotplug a virtio-serial console to a domain
that had no virtio-serial controllers (not even those that
are added by libvirt when some devices need them) at daemon startup,
report a user-friendly error:
error: Failed to attach device from console.xml
error: internal error: no virtio-serial controllers are available
instead of crashing the daemon:
Process terminating with default action of signal 11 (SIGSEGV): dumping core
Access not within mapped region at address 0x8
at 0x531028F: virDomainVirtioSerialAddrNext (domain_addr.c:916)
by 0x531028F: virDomainVirtioSerialAddrAssign (domain_addr.c:1029)
by 0x1CBF68: qemuDomainAttachChrDevice (qemu_hotplug.c:1565)
by 0x1BCD5E: qemuDomainAttachDeviceLive (qemu_driver.c:7997)
by 0x1BCD5E: qemuDomainAttachDeviceFlags (qemu_driver.c:8743)
Introduced in v1.2.14-30-g5903378.
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)
For HVM domains, vfb info must be populated in the libxl_domain_build_info
struct. Currently this is done in the libxlMakeVfbList function, but IMO
it would be cleaner to populate the build_info vfb in a separate
libxlMakeBuildInfoVfb function. libxlMakeVfbList would then handle only
vfb devices, simiar to the other libxlMake<device>List functions.
A future patch will extend libxlMakeBuildInfoVfb to support SPICE.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1224018
The disk pool recalculates the pool allocation, capacity, and available
values each time through processing a newly created disk partition. This
created an issue with the allocation setting since the code used is shared
with the refresh path. Each path calls virStorageBackendDiskReadPartitions
which initializes the pool values and then processes the partition table
from the 'libvirt_parthelper' utility output with the only difference being
create passes a specific volume to be processed while refresh pass a NULL
indicating to process all volumes. That passed volume is check during the
virStorageBackendDiskMakeVol call to see if the current partition described
by the volume key already exists. If it exists, then no adjustments are
made to the allocation and the next entry in the output is checked.
For the create path this resulted in only the most recently created
partition size would be accounted for in the 'allocation' setting. This
patch thus checks whether the incoming volume is NULL before clearing
the pool allocation value.
Commit id '2ac0e647' for https://bugzilla.redhat.com/show_bug.cgi?id=1206521
was meant to be a generic check for the CreateVol, CreateVolFrom, and
DeleteVol paths to check if the storage backend's changed the pool's view
of allocation or available values.
Unfortunately as it turns out this caused a side effect when the disk backend
created an extended partition there would be no actual storage removed from
the pool, thus the changes would not find any change in allocation or
available and incorrectly update the pool values using the size of the
extended partition. A subsequent refresh of the pool would reset the
values appropriately.
This patch modifies those checks in order to specifically not update the
pool allocation and available for only the disk backend rather than be
generic before and after checks.
There are also a couple that were very uninformatively just logging
the value of the pointer rather than the string itself:
* the "name" arg to virNodeDeviceLookupByName()
* wwnn and wwpn args to virNodeDeviceLookupSCSIHostByWWN()
All char*'s that make sense should now have their contents logged
rather than the pointer, and all %s args should now be inside
NULLSTR().
In a couple of cases, the node device driver (and the test node device
driver which likely copied it) was only logging "Node device not
found" when it couldn't find the requested device. This patch changes
those cases to log the name (and in the case when it's relevant, the
wwnn and wwpn) as well.
Virsh capabilities will list offline cpus as online when
libvirt is compiled with numactl option disabled. This
fix will list correct set of online cpus.
This never worked.
In 0.9.10 when this API was introduced, it was intended that
the SHRINK flag combined with DELTA would shrink the volume by
the specified capacity (to avoid passing negative numbers).
See commit 055bbf4.
When the SHRINK flag was finally implemented for the first backend
in 1.2.13 (commit aa9aa6a), it was only implemented for the absolute
values and with the delta flag the volume is always extended,
regardless of the SHRINK flag.
Treat the SHRINK flag as a minus sign when used together with DELTA,
to allow shrinking volumes as was documented in the API since 0.9.10.
https://bugzilla.redhat.com/show_bug.cgi?id=1220213
Since shrinking a volume below existing allocation is not allowed,
it is not possible for a successful resize with VOL_RESIZE_ALLOCATE
to increase the pool's available value.
Even with the SHRINK flag it is possible to extend the current
allocation or even the capacity. Remove the overflow when
computing delta with this flag and do the check even if the
flag was specified.
https://bugzilla.redhat.com/show_bug.cgi?id=1073305
It is necessary to have unpolluted screen when connecting to
parallels driver via virsh.
Otherwise a lot of unexpected output one will get on the console.
Signed-off-by: Maxim Nestratov <mnestratov@parallels.com>
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: Lubomir Rintel <lkundrak@v3.sk>
The QMP command, like the interrupt reinjection logic it's connected
to, is only implemented in QEMU when TARGET_I386 is defined, so
checking for its availability on any other architecture is pointless.
On the other hand, when we're on x86, we shouldn still make sure that
rtc-reset-reinjection is available and refuse to set the time
otherwise.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1211938
