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: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
There was a couple of problems with the style fixes applied to the original
patch:
1.) virFileReadAllQuiet comparison was incorrectly parenthesized when moved
into a condition, causing the len to be set to the result of comparison. This,
together with the removed underflow check would underflow the phy buffer.
2.) The logic was broken. Failure to call "ip" would abort the function, thus
the "iw" branch would never be reached.
This aims to fix the issues and work around possible style complains :)
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Refactor the function to return the bitmap instead of an integer and the
inner workings so that they make more sense.
This patch also fixes possible segfault on old systems that was
introduced by commit:
commit f1a43a8e41
Author: Hu Tao <hutao@cn.fujitsu.com>
Date: Fri Sep 14 15:46:59 2012 +0800
use virBitmap to store cpu affinity info
Since commit 55ace7c478, the sockettest
fails without VIR_TEST_DEBUG set. The problem is found by test number
42 (co-incidence?), which tests range '192.168.122.1' -
'192.168.122.255' in network '192.168.122.0/24'. That is supposed to
fail because the end address is equal to the broadcast address.
When comparing these two in 'virSocketAddrEqual(end, &broadcast)',
there is a check for sin_addr as well as for sin_port. That port,
however, is different when we do not enable test debugging. With the
testing enabled, the port is 0 (correctly initialized), but without that
it has a random number there. And that's because the structure is not
initialized anywhere.
By zeroing the structure before filling in the info, we make sure we
return only the address and not any information that was not requested.
And the test work once again.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Since the monitor code now supports ullongs when setting balloon size,
drop the legacy code with overflow checking.
Additionally the comment mentioning that the job is treated as a sync
job does not make sense any more since the monitor is entered
asynchronously.
Since some functions can be optimized by reusing the buffers that they
already have instead of allocating and copying new ones, lets split
virBitmapToData to two functions where one only converts the data and
the second one is a wrapper that allocates the buffer if necessary.
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.
In case when <vcpu ... cpuset=""> is not specified, the vcpupin array is
not guaranteed to be allocated to def->vcpus. This would cause a crash
for TCG since it does not report thread IDs for vCPUs.
We remember driver name in a new field 'drivername' within
private parallels connection structure. When a new domain
is defined we use this name to set corresponding virtType.
We set VIR_DOMAIN_VIRT_VZ for 'vz' driver and
VIR_DOMAIN_VIRT_PARALLELS for 'Parallels'.
Signed-off-by: Maxim Nestratov <mnestratov@parallels.com>
Though parallels:///system is still accepted we will encourage users
to use vz:///system instead.
Signed-off-by: Maxim Nestratov <mnestratov@parallels.com>
We add this connection driver just as an exact copy with different
name to keep backward compatibility.
Vz stands for Virtuozzo, which is a new name of Parallels Cloud Server.
Signed-off-by: Maxim Nestratov <mnestratov@parallels.com>
If 'parallels:///system' uri is specified then connection is made to
'Parallels' driver and domain type will be VIR_DOMAIN_VIRT_PARALLELS.
In case of 'vz:///system' connection is established to 'vz' driver
and domain type will be VIR_DOMAIN_VIRT_VZ.
Signed-off-by: Maxim Nestratov <mnestratov@parallels.com>
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>
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
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
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.
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
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.
