- 25 8月, 2016 6 次提交
-
-
由 Peter Krempa 提交于
Individual vCPU hotplug requires us to track the state of any vCPU. To allow this add the following XML: <domain> ... <vcpu current='2'>3</vcpu> <vcpus> <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/> <vcpu id='1' enabled='no' hotpluggable='yes'/> </vcpus> ... The 'enabled' attribute allows to control the state of the vcpu. 'hotpluggable' controls whether given vcpu can be hotplugged and 'order' allows to specify the order to add the vcpus.
-
由 Peter Krempa 提交于
Similarly to devices the guest may allow unplug of the VCPU if libvirt is down. To avoid problems, refresh the vcpu state on reconnect. Don't mess with the vcpu state otherwise.
-
由 Peter Krempa 提交于
Now that the monitor code gathers all the data we can extract it to relevant places either in the definition or the private data of a vcpu. As only thread id is broken for TCG guests we may extract the rest of the data and just skip assigning of the thread id. In case where qemu would allow cpu hotplug in TCG mode this will make it work eventually.
-
由 Peter Krempa 提交于
For hotplug purposes it's necessary to retrieve data using query-hotpluggable-cpus while the old query-cpus API report thread IDs and order of hotplug. This patch adds code that merges the data using a rather non-trivial algorithm and fills the data to the qemuMonitorCPUInfo structure for adding to appropriate place in the domain definition.
-
由 Peter Krempa 提交于
As of qemu commit: commit a32ef3bfc12c8d0588f43f74dcc5280885bbdb30 Author: Thomas Huth <thuth@redhat.com> Date: Wed Jul 22 15:59:50 2015 +0200 vl: Add another sanity check to smp_parse() function v2.4.0-952-ga32ef3b configuration where the maximum CPU count doesn't match the topology is rejected. Prior to that only configurations where the topology would contain more cpus than the maximum count would be rejected. Use QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS as a relevant recent enough witness to avoid breaking old configs.
-
由 Peter Krempa 提交于
The function will gradually add more returned data. Return a struct for every vCPU containing the data.
-
- 12 8月, 2016 2 次提交
-
-
由 Andrea Bolognani 提交于
Now that the default USB controller model is explicit rather than implicit for i440fx machines, we have to tweak the conditions for dropping it in order to keep migration towards libvirt <= 0.9.4 working.
-
由 Andrea Bolognani 提交于
When the user doesn't specify any model for a USB controller, we use an architecture-dependent default, but we don't reflect it in the guest XML. Pick the default USB controller model when parsing the guest XML instead of when creating the QEMU command line, so that our choice is saved back to disk.
-
- 04 8月, 2016 4 次提交
-
-
由 Michal Privoznik 提交于
In qemu, enabling this feature boils down to adding the following onto the command line: -global driver=cfi.pflash01,property=secure,value=on However, there are some constraints resulting from the implementation. For instance, System Management Mode (SMM) is required to be enabled, the machine type must be q35-2.4 or later, and the guest should be x86_64. While technically it is possible to have 32 bit guests with secure boot, some non-trivial CPU flags tuning is required (for instance lm and nx flags must be prohibited). Given complexity of our CPU driver, this is not trivial. Therefore I've chosen to forbid 32 bit guests for now. If there's ever need, we can refine the check later. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Call the vcpu thread info validation separately to decrease complexity of returned values by qemuDomainRefreshVcpuInfo. This function now returns 0 on success and -1 on error. Certain failures of qemu to report data are still considered as success. Any error reported now is fatal.
-
由 Peter Krempa 提交于
Validate the presence of the thread id according to state of the vCPU rather than just checking the vCPU count. Additionally put the new validation code into a separate function so that the information retrieval can be split from the validation.
-
由 Peter Krempa 提交于
The function will eventually do more useful stuff than just detection of thread ids.
-
- 02 8月, 2016 5 次提交
-
-
由 John Ferlan 提交于
Move QEMU_DRIVE_HOST_PREFIX into the qemu_alias.c to dissuade future callers from using it. Create qemuAliasDiskDriveSkipPrefix in order to handle the current consumers that desire to check if an alias has the drive- prefix and "get beyond it" in order to get the disk alias.
-
由 Chunyan Liu 提交于
To sync with virDomainControllerModelUSB, we add two models in qemuControllerModelUSB 'qusb1' and 'qusb2', but those models are not supported in qemu driver. So add check in device post parse to report errors if 'qusb1' and 'qusb2' are specified. Signed-off-by: NChunyan Liu <cyliu@suse.com>
-
由 Martin Kletzander 提交于
Until now we simply errored out when the translation from pool+volume failed. However, we should instead check whether that disk is needed or not since there is an option for that. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1168453Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
There is an error reset following the function and check for startupPolicy before that. Let's reflect those things inside that function so that future code doesn't have to be that complex. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 01 8月, 2016 1 次提交
-
-
由 Boris Fiuczynski 提交于
The panic devices with models s390 and pseries are autogenerated. For backwards compatibility reasons the devices are to be removed when migrating. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 29 7月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
Consider the following XML snippet: <memory model=''> <target> <size unit='KiB'>523264</size> <node>0</node> </target> </memory> Whats wrong you ask? The @model attribute. This should result in an error thrown into users faces during virDomainDefine phase. Except it doesn't. The XML validation catches this error, but if users chose to ignore that, they will end up with invalid XML. Well, they won't be able to start the machine - that's when error is produced currently. But it would be nice if we could catch the error like this earlier. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 28 7月, 2016 1 次提交
-
-
由 Daniel P. Berrange 提交于
The current LUKS support has a "luks" volume type which has a "luks" encryption format. This partially makes sense if you consider the QEMU shorthand syntax only requires you to specify a format=luks, and it'll automagically uses "raw" as the next level driver. QEMU will however let you override the "raw" with any other driver it supports (vmdk, qcow, rbd, iscsi, etc, etc) IOW the intention though is that the "luks" encryption format is applied to all disk formats (whether raw, qcow2, rbd, gluster or whatever). As such it doesn't make much sense for libvirt to say the volume type is "luks" - we should be saying that it is a "raw" file, but with "luks" encryption applied. IOW, when creating a storage volume we should use this XML <volume> <name>demo.raw</name> <capacity>5368709120</capacity> <target> <format type='raw'/> <encryption format='luks'> <secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/> </encryption> </target> </volume> and when configuring a guest disk we should use <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/home/berrange/VirtualMachines/demo.raw'/> <target dev='sda' bus='scsi'/> <encryption format='luks'> <secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/> </encryption> </disk> This commit thus removes the "luks" storage volume type added in commit 318ebb36 Author: John Ferlan <jferlan@redhat.com> Date: Tue Jun 21 12:59:54 2016 -0400 util: Add 'luks' to the FileTypeInfo The storage file probing code is modified so that it can probe the actual encryption formats explicitly, rather than merely probing existance of encryption and letting the storage driver guess the format. The rest of the code is then adapted to deal with VIR_STORAGE_FILE_RAW w/ VIR_STORAGE_ENCRYPTION_FORMAT_LUKS instead of just VIR_STORAGE_FILE_LUKS. The commit mentioned above was included in libvirt v2.0.0. So when querying volume XML this will be a change in behaviour vs the 2.0.0 release - it'll report 'raw' instead of 'luks' for the volume format, but still report 'luks' for encryption format. I think this change is OK because the storage driver did not include any support for creating volumes, nor starting guets with luks volumes in v2.0.0 - that only since then. Clearly if we change this we must do it before v2.1.0 though. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 26 7月, 2016 2 次提交
-
-
由 Tomasz Flendrich 提交于
Dropping the caching of ccw address set. The cached set is not required anymore, because the set is now being recalculated from the domain definition on demand, so the cache can be deleted.
-
由 Tomasz Flendrich 提交于
Dropping the caching of virtio serial address set. The cached set is not required anymore, because the set is now being recalculated from the domain definition on demand, so the cache can be deleted. Credit goes to Cole Robinson.
-
- 21 7月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Check if they fit on the USB controllers the domain has, and error out if two devices try to use the same address.
-
- 20 7月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Resolves a CI test integration failure with a RHEL6/Centos6 environment. In order to use a LUKS encrypted device, the design decision was to generate an encrypted secret based on the master key. However, commit id 'da86c6c2' missed checking for that specifically. When qemuDomainSecretSetup was implemented, a design decision was made to "fall back" to a plain text secret setup if the specific cipher was not available (e.g. virCryptoHaveCipher(VIR_CRYPTO_CIPHER_AES256CBC)) as well as the QEMU_CAPS_OBJECT_SECRET. For the luks encryption setup there is no fall back to the plaintext secret, thus if that gets set up by qemuDomainSecretSetup, then we need to fail. Also, while the qemuxml2argvtest has set the QEMU_CAPS_OBJECT_SECRET bit, it didn't take into account the second requirement that the ability to generate the encrypted secret is possible. So modify the test to not attempt to run the luks-disk if we know we don't have the encryption algorithm.
-
- 19 7月, 2016 2 次提交
-
-
由 John Ferlan 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1301021 Generate the luks command line using the AES secret key to encrypt the luks secret. A luks secret object will be in addition to a an AES secret. For hotplug, check if the encinfo exists and if so, add the AES secret for the passphrase for the secret object used to decrypt the device. Modify/augment the fakeSecret* in qemuxml2argvtest in order to handle find a uuid or a volume usage with a specific path prefix in the XML (corresponds to the already generated XML tests). Add error message when the 'usageID' is not 'mycluster_myname'. Commit id '1d632c39' altered the error message generation to rely on the errors from the secret_driver (or it's faked replacement). Add the .args output for adding the LUKS disk to the domain Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Soon we will be adding luks encryption support. Since a volume could require both a luks secret and a secret to give to the server to use of the device, alter the alias generation to create a slightly different alias so that we don't have two objects with the same alias. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 18 7月, 2016 2 次提交
-
-
由 Jiri Denemark 提交于
Migration to an older libvirt (pre v1.3.0-175-g71408079) is broken because older versions of libvirt generated different channel paths and they didn't drop the default paths when parsing domain XMLs. We'd get such a nice error message: internal error: process exited while connecting to monitor: 2016-07-08T15:28:02.665706Z qemu-kvm: -chardev socket, id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/ domain-3-nest/org.qemu.guest_agent.0,server,nowait: Failed to bind socket to /var/lib/libvirt/qemu/channel/target/domain-3-nest/ org.qemu.guest_agent.0: No such file or directory That said, we should not even format the default paths when generating a migratable XML. https://bugzilla.redhat.com/show_bug.cgi?id=1320470Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Playing directly with our live definition, updating it, and reverting it back once we are done is very nice and it's quite dangerous too. Let's just make a copy of the domain definition if needed and do all tricks on the copy. https://bugzilla.redhat.com/show_bug.cgi?id=1320470Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 11 7月, 2016 6 次提交
-
-
由 Michal Privoznik 提交于
This one's a bit more complicated. In qemuProcessPrepareDomain() a master key for encrypting secret for ciphered disks is created. This object lives within qemuDomainObjPrivate object. It is freed in qemuProcessStop(), but if nobody calls it (for instance like our qemuxml2argvtest does), the key object leaks. ==17078== 32 bytes in 1 blocks are definitely lost in loss record 633 of 707 ==17078== at 0x4C2C070: calloc (vg_replace_malloc.c:623) ==17078== by 0xAD924DF: virAllocN (viralloc.c:191) ==17078== by 0x5050BA6: virCryptoGenerateRandom (qemuxml2argvmock.c:166) ==17078== by 0x453DC8: qemuDomainMasterKeyCreate (qemu_domain.c:678) ==17078== by 0x47A36B: qemuProcessPrepareDomain (qemu_process.c:4913) ==17078== by 0x47C728: qemuProcessCreatePretendCmd (qemu_process.c:5542) ==17078== by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332) ==17078== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413) ==17078== by 0x446E7A: virTestRun (testutils.c:179) ==17078== by 0x445BD9: mymain (qemuxml2argvtest.c:2022) ==17078== by 0x44886F: virTestMain (testutils.c:969) ==17078== by 0x445D9B: main (qemuxml2argvtest.c:2036) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrange 提交于
The code in qemuDomainObjPrivateXMLParseVcpu for parsing the 'idstr' string was comparing the overall boolean result against 0 which was always true qemu/qemu_domain.c: In function 'qemuDomainObjPrivateXMLParseVcpu': qemu/qemu_domain.c:1482:59: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare] if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 || ^ It was further performing two distinct error checks in the same conditional and reporting a single error message, which was misleading in one of the two cases. This splits the conditional check into two parts with distinct error messages and fixes the logic error. Fixes the bug in commit 5184f398 Author: Peter Krempa <pkrempa@redhat.com> Date: Fri Jul 1 14:56:14 2016 +0200 qemu: Store vCPU thread ids in vcpu private data objects Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Peter Krempa 提交于
Rather than storing them in an external array store them directly.
-
由 Peter Krempa 提交于
Note the vcpu ID so that once we allow non-contiguous vCPU topologies it will be possible to pair thread id's with the vcpus.
-
由 Peter Krempa 提交于
Further patches will be adding index and modifying the source variables so this will make it more clear.
-
由 Peter Krempa 提交于
Members will be added in follow-up patches.
-
- 08 7月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
Otherwise migration during which we didn't send client_migrate_info QMP command will get stuck waiting for SPICE migration to finish if libvirtd sent the QMP command in a previous migration attempt. Broken by bd7c8a69. https://bugzilla.redhat.com/show_bug.cgi?id=1151723Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 04 7月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
Due to the way the hardware works, KVM on ppc64 always requires memory locking; however, that is not the case for non-KVM ppc64 guests, eg. ppc64 guests that are running on x86_64 with TCG. Only require memory locking for ppc64 guests if they are using KVM or, as it's the case for all architectures, they have host devices assigned using VFIO. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1350772
-
- 02 7月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Introduce a helper to help determine if a disk src could be possibly used for a disk secret... Going to need this for hot unplug. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 28 6月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 6月, 2016 1 次提交
-
-
由 Laine Stump 提交于
libvirt's qemu driver doesn't have direct access to the config on the guest side of a network interface, and currently doesn't have any method in place to even inform the guest of the desired config. In the future, an unenforceable attempt to set the guest-side IP info could be made by adding a static host entry to the appropriate dnsmasq configuration (or changing the default dhcp client address on the qemu commandline for type='user' interfaces), or enhancing the guest agent to allow setting an IP address, but for now it can't have any effect, and we don't want to give the illusion that it does. To prevent the "disappearance" of any existing configs with ip address/route info (due to parser failure), this check is added in the newly implemented qemuDomainDeviceDefValidate(), which is only called when a domain is defined or started, *not* when it is reread from disk at libvirtd startup.
-
- 25 6月, 2016 1 次提交
-
-
由 John Ferlan 提交于
Rather than pass authdef, pass the 'authdef->username' and the '&authdef->secdef' Note that a username may be NULL. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-