- 13 9月, 2017 2 次提交
-
-
由 Cole Robinson 提交于
For a logged in user this a path like /dev/dri/renderD128 will have default ownership root:video which won't work for the qemu:qemu user, so we need to chown it. We only do this when mount namespaces are enabled in the qemu driver, so the chown'ing doesn't interfere with other users of the shared render node path https://bugzilla.redhat.com/show_bug.cgi?id=1460804
-
由 Cole Robinson 提交于
The VIR_SECURITY_MANAGER_MOUNT_NAMESPACE flag informs the DAC driver if mount namespaces are in use for the VM. Will be used for future changes. Wire it up in the qemu driver
-
- 12 9月, 2017 9 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1464313 If a Disk pool was defined/created using XML that either didn't specify a specific format or specified format type='unknown', then restarting a pool after an initial disk backend build with overwrite would fail after a libvirtd restart for a non-autostarted pool. This is because the persistent pool data is not updated during pool build w/ overwrite processing to have the VIR_STORAGE_POOL_DISK_DOS default format. So in addition to the alteration done during disk build processing, alter the default expectation for disk startup to be DOS if nothing has been defined yet. That will either succeed if the pool had been successfully built previously using the default DOS format or fail with a message indicating the format is something else that does not match the expect format 'dos'.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1477880 If the "/#" is missing from the provided iSCSI path, then we need to provide the default LUN of /0; otherwise, QEMU will fail to parse the URL causing a failure to either create the guest or hotplug attach the storage. During post parse, for any iSCSI disk or hostdev, scan the source path looking for the presence of '/', if found, then we can assume the LUN is provided. If not found, alter the input XML to add the "/0". This will cause the generated XML to have the generated value when the domain config is saved after post parse.
-
由 Peter Krempa 提交于
Commit 703abf1d changed the logic so that we don't attempt to re-create the image if it's a block device. This was done by modifying the 'reuse' variable. Unfortunately after modifying it one of the uses was to infer whether we should probe the disk format. After changes in the commit mentioned above we would attempt the probe if the target of the copy is a block device and the format was not provided explicitly rather than using the format of the disk. Fix it by explicitly checking whether the user requested a reuse of the disk rather than the modified boolean flag. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1490826
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1447169 Again, no special here. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1447169 With this patch users can cold plug a watchdog. Things are pretty simple because a domain can have at most one watchdog device. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
If there was an error when constructing the buffer, NULL is returned. The buffer is never freed though. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Guido Günther 提交于
-
由 Guido Günther 提交于
-
由 Guido Günther 提交于
-
- 11 9月, 2017 4 次提交
-
-
由 Jiri Denemark 提交于
When destroying a domain libvirt marks it internally with a beingDestroyed flag to make sure the qemuDomainDestroyFlags API itself cleans up after the domain rather than letting an uninformed EOF handler do it. However, when the domain is being started at the moment libvirt was asked to destroy it, only the starting thread can properly clean up after the domain and thus it ignores the beingDestroyed flag. Once qemuDomainDestroyFlags finally gets a job, the domain may not be running anymore, which should not be reported as an error if the domain has been starting up. https://bugzilla.redhat.com/show_bug.cgi?id=1445600Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Ján Tomko 提交于
This option requires: <ioapic driver='qemu'/> Report an error in case someone tries to combine it with different ioapic setting. Setting 'eim' on without enabling 'intremap' does not make sense. https://bugzilla.redhat.com/show_bug.cgi?id=1457610
-
由 Ján Tomko 提交于
Simplify the formatting function even further.
-
由 Ján Tomko 提交于
Use the new helper to simplify the code. This also fixes the bug of not formatting 'eim' in the useless case if it's the only enabled attribute.
-
- 07 9月, 2017 16 次提交
-
-
由 Andrea Bolognani 提交于
Add a 'cleanup' label and improve the readability of one of the checks by making it conform to our formatting standard and moving the corresponding comment. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NLaine Stump <laine@laine.org>
-
由 Stefan Berger 提交于
TPM 2 does not implement sysfs files for cancellation of commands. We therefore use /dev/null for the cancel path passed to QEMU. Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com> Tested-by: NJavier Martinez Canillas <javierm@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Brijesh Singh 提交于
Add a new CPU model called 'EPYC' to model processors from AMD EPYC family (which includes EPYC 76xx,75xx,74xx, 73xx and 72xx). The following features bits have been added/removed compare to Opteron_G5 Added: monitor, movbe, rdrand, mmxext, ffxsr, rdtscp, cr8legacy, osvw, fsgsbase, bmi1, avx2, smep, bmi2, rdseed, adx, smap, clfshopt, sha xsaveopt, xsavec, xgetbv1, arat Removed: xop, fma4, tbm The patch is depend on EPYC CPU model supported introduced in qemu [1] [1] https://patchwork.kernel.org/patch/9902205/ Cc: Tom Lendacky <Thomas.Lendacky@amd.com> Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
In case of real migration (not migrating to file on save, dump etc) migration info is not complete at time qemu finishes migration in normal (non postcopy) mode. We need to update disks stats, downtime info etc. Thus let's not expose this job status as completed. To archive this let's set status to 'qemu completed' after qemu reports migration is finished. It is not visible as complete job to clients. Cookie code on confirm phase will finally turn job into completed. As we don't need more things to do when migrating to file status is set to 'completed' as before in this case. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
When getting job info in case mirror does not reach ready phase fetch mirror stats from qemu. Otherwise mirror stats are already saved in current job. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Looks like it is more simple to drop this optimization as we are going to add getting disks stats during migration via quering qemu process and checking if we have to acquire job condition becomes more complicate. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Instead of checking stat.status let's set status to migrating as soon as migrate command is send (waiting for completion is a good place too). Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Setting status to none has little value - getting job status will not return even elapsed time. After this patch getting job stats stays correct in a sence it will not fetch migration stats because it consults stats.status before doing the fetch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Querying destination migration statistics may result in getting a failure or getting a elapsed time value depending on stats.status value which is odd. Instead let's always fail. Clients should be ready to handle this as currently getting failure period can be considerable. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
qemuMigrationFetchJobStatus is rather inconvinient. Some of its callers don't need status to be updated, some don't need to update elapsed time right away. So let's update status or elapsed time in callers instead. This patch drops updating job status on getting job stats by client. This way we will not provide status 'completed' while it is not yet updated by migration routine. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
qemuMonitorGetMigrationStats will do it for us anyway. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
This way we get stats only in one place. The former code waits for complete/postcopy status basically and don't need to mess with stats. The patch drops raising an error on stats updates failure. This does not make much sense anyway. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Let's introduce QEMU_DOMAIN_JOB_STATUS_POSTCOPY state for job.current->status instead of checking job.current->stats.status. The latter can be changed when fetching migration statistics. Moving state function from the variable and leave only store function seems more managable. This patch removes all state checking usage of stats except for qemuDomainGetJobStatsInternal. This place will be handled separately. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
This patch simply switches code from using VIR_DOMAIN_JOB_* to introduced QEMU_DOMAIN_JOB_STATUS_*. Later this gives us freedom to introduce states for postcopy and mirroring phases. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
qemu driver does not have VIR_DOMAIN_JOB_BOUNDED jobs and timeRemaining is always 0. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 06 9月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1439991 Whenever a device is being updated via virDomainUpdateDeviceFlags() API, we parse the device XML and ideally run some generic checks to validate the configuration (e.g. if device defines per-device boot order but the domain has os/boot element already). Well, that's the theory - due to a missing check we've jumped early from that check function. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 05 9月, 2017 6 次提交
-
-
由 John Ferlan 提交于
Neither @cfg nor (now) @driver is used in the API, so remove them and mark @opaque as UNUSED. NB: Commit id 'fa3c5585' dropped the unused @qemuCaps which was the last consumer of @driver other than @cfg, but even @cfg was never used even in the original implementation from commit id 'd987f63a'.
-
由 Cole Robinson 提交于
arm/aarch64 -M virt on KVM doesn't and will never work with standard VGA card emulation. The recommended method is to use type=virtio, so let's make it the default for video devices without an explicit type set by the user. https://bugzilla.redhat.com/show_bug.cgi?id=1404112Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
And not generic domain_conf code. We will need qemu private functions in a bit. Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
This allows drivers to set their own default. But if a driver neglects to fill one in, we still error like we previously would at parse time. Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
Will be needed for future patches to pull the default video type setting out of XML parsing routines. Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Erik Skultety 提交于
There were a few places in our code where the following pattern in 'if' condition occurred: if ((foo = bar() < 0)) do something; This patch adjusts the conditions to the expected format: if ((foo = bar()) < 0) do something; Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1488192Signed-off-by: NErik Skultety <eskultet@redhat.com> Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 04 9月, 2017 2 次提交
-
-
由 Andrea Bolognani 提交于
Suggested-by: NMartin Kletzander <mkletzan@redhat.com> Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Daniel P. Berrange 提交于
Although not previously explicitly documented, the expectation for the libvirt event loop is that an implementation is registered early in application startup, before calling any libvirt APIs and then run forever after. Replacing a previously registered event loop is not safe & subject to races even if virConnectClose has been called on open handles, due to delayed deregistration of callbacks during conenction close. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-