- 01 6月, 2015 2 次提交
-
-
由 Andrea Bolognani 提交于
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
-
由 Andrea Bolognani 提交于
-
- 29 5月, 2015 1 次提交
-
-
由 Ján Tomko 提交于
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-g59033788.
-
- 27 5月, 2015 2 次提交
-
-
由 Andrea Bolognani 提交于
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
-
由 Peter Krempa 提交于
Since commit bcd9a564 virDomainNumatuneGetMode returns the value via a pointer rather than in the return value. The change triggered problems with platforms where the compiler decides to use a data type of size different than integer at the point where we typecast it. Work around the issue by using an intermediate variable of the correct type that gets casted back by the default typecasting rules.
-
- 26 5月, 2015 3 次提交
-
-
由 John Ferlan 提交于
Rather than an algorithm based solely on libvirtd ctime to refresh the capabilities add the element of the libvirt build version into the equation. Since that version wouldn't be there prior to this code being run - don't fail on reading the capabilities if not found. In this case, the cache will always be rebuilt when a new libvirt version is installed.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1195882 Original commit id 'cbde3589' indicates that the cache file would be discarded if either the QEMU binary or libvirtd 'ctime' changes; however, the code only discarded if the QEMU binary time didn't match or if the new libvirtd ctime was later than what created the cache file. Since many factors come into play with 'ctime' adjustments (including perhaps turning back the hands of time), change the logic to also force a refresh if the ctime of libvirt is different than what's in the cache.
-
由 John Ferlan 提交于
Recent changes to the -M/--machine processing code in qemuParseCommandLine caused Coverity to determine there was a possible resource leak with how the 'list' is managed. Rather than try to add virStringFreeList calls everywhere - just promote list to the top of the variables and free it within the error processing code. Also required a couple of other tweaks in order to avoid double free's.
-
- 21 5月, 2015 6 次提交
-
-
由 Michal Privoznik 提交于
Not every chardev is plugged onto virtio-serial bus. However, the code introduced in 89e991a2 assumes that. Incorrectly. With previous patches we have three options where a chardev can be plugged: virtio-serial, USB and PCI. This commit fixes the detach part. However, since we are not auto allocating USB addresses yet, I'm just marking the place where appropriate code should go. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Not every chardev is plugged onto virtio-serial bus. However, the code introduced in 89e991a2 assumes that. Incorrectly. With previous patches we have three options where a chardev can be plugged: virtio-serial, USB and PCI. This commit fixes the attach part. However, since we are not auto allocating USB addresses yet, I'm just marking the place where appropriate code should go. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=998813 Implementation is pretty straight-forward. Of course, not all qemus out there supports the device, so new capability is introduced and checked prior each use of the device. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ján Tomko 提交于
Base-64 encode the password and pass it to the guest agent via the 'guest-set-user-password' command. https://bugzilla.redhat.com/show_bug.cgi?id=1174177
-
由 Jiri Denemark 提交于
Most virDomainDiskIndexByName callers do not care about the index; what they really want is a disk def pointer. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Erik Skultety 提交于
When starting a domain, if a domain specifies security drivers we do not have loaded, we fail. However we don't check for this during reconnect, so any operation relying on security driver functionality would fail. If someone e.g. starts a domain with selinux driver loaded, then they change the security driver to 'none' in config, restart the daemon and call dump/save/.., QEMU will return an error. As we shouldn't kill the domain, we should at least log an error to let the user know that domain reconnect wasn't completely clean. https://bugzilla.redhat.com/show_bug.cgi?id=1183893
-
- 20 5月, 2015 2 次提交
-
-
由 Michal Privoznik 提交于
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>
-
由 John Ferlan 提交于
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.
-
- 19 5月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
Since af2a1f05, qemuDomainGetNumaParameters() returns invalid value for a running guest. The problem is that it is getting the information from cgroups, but the parent cgroup is being left alone since the mentioned commit. Since the running guest's XML is in sync with cgroups, there is no need to look into cgroups (unless someone changes the configuration behind libvirt's back). Returning the info from the definition fixes a bug and is also a cleanup. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1221047Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 18 5月, 2015 2 次提交
-
-
由 Laine Stump 提交于
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.
-
由 Tony Krowiak 提交于
Introduces two new -machine option parameters to the QEMU command to enable/disable the CPACF protected key management operations for a guest: aes-key-wrap='on|off' dea-key-wrap='on|off' The QEMU code maps the corresponding domain configuration elements to the QEMU -machine option parameters to create the QEMU command: <cipher name='aes' state='on'> --> aes-key-wrap=on <cipher name='aes' state='off'> --> aes-key-wrap=off <cipher name='dea' state='on'> --> dea-key-wrap=on <cipher name='dea' state='off'> --> dea-key-wrap=off Signed-off-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com> Signed-off-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 16 5月, 2015 4 次提交
-
-
由 Laine Stump 提交于
We have previously effectively ignored all <controller type='ide'> elements in a domain definition. On the i440fx-based machinetypes there is an IDE controller that is included in the chipset and can't be removed (which is the ide controller with index='0'>), so it makes sense to ignore that one controller. However, if an i440fx domain definition has a 2nd controller, nothing catches this error (unless you also have a disk attached to it, in which case qemu will complain that you're trying to use the ide controller named "ide1", which doesn't exist), and if any other type of domain has even a single controller defined, it will be incorrectly ignored. Ignoring a bogus controller definition isn't such a big problem, as long as an error is logged when any disk is attached to that non-existent controller. But in the case of q35-based machinetypes, the hardcoded id ("alias" in libvirt terms) of its builtin SATA controller is "ide", which happens to be the same id as the builtin IDE controller on i440fx machinetypes. So libvirt creates a commandline believing that it is connecting the disk to the builtin (but actually nonexistent) IDE controller, qemu thinks that libvirt wanted that disk connected to the builtin SATA controller, and everybody is happy. Until you try to connect a 2nd disk to the IDE controller. Then qemu will complain that you're trying to set unit=1 on a controller that requires unit=0 (SATA controllers are organized differently than IDE controllers). After this patch, if a domain has an IDE controller defined for a machinetype that has no IDE controllers, libvirt will log an error about the controller itself as it is building the qemu commandline (rather than a (possible) error from qemu about disks attached to that controller). This is done by adding IDE to the list of controller types that are handled in the loop that creates controller command strings in qemuBuildCommandline() (previously it would *always* skip IDE controllers). Then qemuBuildControllerDevStr() is modified to log an appropriate error in the case of IDE controllers. In the future, if we add support for extra IDE controllers (piix3-ide and/or piix4-ide) we can just add it into the IDE case in qemuBuildControllerDevStr(). For now, nobody seems anxious to add extra support for an aging and very slow controller, when there are so many better options available. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1176071 (Fedora)
-
由 Laine Stump 提交于
Reorganize the loop that builds controller args to remove unnecessary duplicated code and superfluous else clauses. No functional change.
-
由 Laine Stump 提交于
This makes sure that that the commandlines generated for devices and controller devices are all using the alias that has been set in the controller's object as the id of the controller, rather than hardcoding a printf (or worse, encoding exceptions to the standard ${controller}${index} into the logic) Since this "fixes" the controller name used for the sata controller, the commandline arg for the sata controller in the sata test case had to be adjusted to be "sata0" instead of "ahci0". All other tests remain unchanged, verifying that the patch causes no other functional change. Because the function that finds a controller alias based on a device def requires a pointer to the full domainDef in order to get the list of controllers, the arglist of a few functions had to have this added.
-
由 Laine Stump 提交于
There are a few extra exceptions that weren't being accounted for when creating the alias for a controller. This resulted in 1) incorrect status XML, and 2) exceptions/printfs of what *should* have been directly available in the controller alias when constructing device commandline arguments: 1) The primary (and only) IDE controller on a 440FX machinetype is hardcoded to be "ide" in qemu. 2) The primary SATA controller on a 440FX machinetype is also hardcoded to be "ide" in qemu. 3) On machinetypes that don't support multiple PCI buses, the PCI bus is hardcoded in qemu to have the name "pci". 4) The first usb master controller is "usb", all others are the normal "usb%d". (note that usb controllers that are not a "master" will have the same index, and thus alias, as the master). We needed to pass in the full domainDef and qemuCaps in order to properly make the decisions about these exceptions.
-
- 15 5月, 2015 5 次提交
-
-
由 Jiri Denemark 提交于
When cancelling drive mirror, always try to do that for all disks even if it fails for some of them. Report the first error we saw. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Instead of redoing the same filtering over and over everytime we need to walk through all disks which are being migrated. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
And move it to qemu_domain.[ch] because this API is QEMU-only. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 14 5月, 2015 1 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1218577 Treat pinning an IOThread via API as if someone added an IOThread to ensure the iothreadid doesn't cause the guest to disappear
-
- 13 5月, 2015 3 次提交
-
-
由 zhang bo 提交于
As of eeb008db the variable is not used anymore. Drop it. Signed-off-by: NWang Yufei <james.wangyufei@huawei.com> Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ján Tomko 提交于
Otherwise we might allow coldplugging a device that uses an address that is already occupied, creating an unstartable domain. https://bugzilla.redhat.com/show_bug.cgi?id=1220195
-
由 Pavel Hrdina 提交于
In the XML we have the vnc port number, but QEMU takes on command line a vnc screen number, it's port-5900. We should fail with error message that only ports in range [5900,65535] are valid. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1164966Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 12 5月, 2015 3 次提交
-
-
由 Luyao Huang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1220809 When cold-plugging an RNG device but something fails in qemuDomainAssignAddresses, we will double free the RNG device. Once a device is plugged into the domain, we should set the device pointer to NULL to fix this issue. ... 5 0x00007fb7d180ac8a in virFree at util/viralloc.c:582 6 0x00007fb7d1895cdd in virDomainRNGDefFree at conf/domain_conf.c:19786 7 0x00007fb7d1895d99 in virDomainDeviceDefFree at conf/domain_conf.c:2022 8 0x00007fb7b92b8baf in qemuDomainAttachDeviceFlags at qemu/qemu_driver.c:8785 9 0x00007fb7d190c5d7 in virDomainAttachDeviceFlags at libvirt-domain.c:8488 10 0x00007fb7d23af9d2 in remoteDispatchDomainAttachDeviceFlags at remote_dispatch.h:2842 ... Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Laine Stump 提交于
The code to add device type to the commandline was identical for lsi and other models of SCSI controllers, but was duplicated (with the exception of a minor ordering difference of the if-else clauses) for the two cases. This patch replaces those two with a single instance of the code just before the if().
-
由 Laine Stump 提交于
This patch makes qemuValideDevicePCISlotsChipsets() more consistent in appearance by replacing several clauses of an if with the equivalent call to qemuDomainMachineIsI440FX. The if was checking exactly the same items, just in a slightly different order.
-
- 11 5月, 2015 3 次提交
-
-
由 Peter Krempa 提交于
Since libvirt doesn't call to update the new balloon size in qemu add code that will handle tweaking of the size of the current balloon statistic until qemu reports the new size using the event.
-
由 Peter Krempa 提交于
Use the new domain list collection helpers to avoid going through virDomainPtrs. This additionally implements filter capability when called through the api that accepts domain list filters.
-
由 Peter Krempa 提交于
Extend it to a universal helper used for clearing lists of any objects. Note that the argument type is specifically void * to allow implicit typecasting. Additionally add a helper that works on non-NULL terminated arrays once we know the length.
-
- 07 5月, 2015 2 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=890648 So, imagine you've issued an API that involves guest agent. For instance, you want to query guest's IP addresses. So the API acquires QUERY_JOB, locks the guest agent and issues the agent command. However, for some reason, guest agent replies to initial ping correctly, but then crashes tragically while executing real command (in this case guest-network-get-interfaces). Since initial ping went well, libvirt thinks guest agent is accessible and awaits reply to the real command. But it will never come. What will is a monitor event. Our handler (processSerialChangedEvent) will try to acquire MODIFY_JOB, which will fail obviously because the other thread that's executing the API already holds a job. So the event handler exits early, and the QUERY_JOB is never released nor ended. The way how to solve this is to put flag somewhere in the monitor internals. The flag is called @running and agent commands are issued iff the flag is set. The flag itself is set when we connect to the agent socket. And unset whenever we see DISCONNECT event from the agent. Moreover, we must wake up all the threads waiting for the agent. This is done by signalizing the condition they're waiting on. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Running shutdown with mode agent on a shutoff domain gives cryptic error message: virsh # shutdown --mode agent gentoo error: Failed to shutdown domain gentoo error: Guest agent is not responding: QEMU guest agent is not connected After this patch, the error is more clear: virsh # shutdown --mode agent gentoo error: Failed to shutdown domain gentoo error: Requested operation is not valid: domain is not running Reported-by: NMartin Kletzander <mkletzan@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-