- 03 4月, 2017 11 次提交
-
-
由 Peter Krempa 提交于
If a transient storage pool is deemed inactive after libvirtd restart it would not be deleted from the list. Reuse virStoragePoolUpdateInactive along with a refactor necessary to properly update the state. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1242801
-
由 Peter Krempa 提交于
After a pool is made inactive the definition objects need to be updated (if a new definition is prepared) and transient pools need to be completely removed. Split out the code doing these steps into a separate function for later reuse.
-
由 Peter Krempa 提交于
When registering a storage poll backend, the code would use virStorageTypeToString instead of virStoragePoolTypeToString. The following message would be logged: virDriverLoadModuleFunc:71 : Lookup function 'virStorageBackendSCSIRegister' virStorageBackendRegister:174 : Registering storage backend '(null)'
-
由 Peter Krempa 提交于
Since this file gets changed (and broken) rather often, introduce a schema file so that the test suite can validate it.
-
由 Peter Krempa 提交于
Add stricter rules for the news file and fix offending entries.
-
由 Peter Krempa 提交于
Sometimes it may be desired to validate individual files against a schema. Refactor the data structures to unify them and introduce a new macro DO_TEST_FILE(schema, xmlfile) which will test the XML file against the given schema file.
-
由 Michal Privoznik 提交于
Currently, if we want to zero out disk source (e,g, due to startupPolicy when starting up a domain) we use virDomainDiskSetSource(disk, NULL). This works well for file based storage (storage type file, dir, or block). But it doesn't work at all for other types like volume and network. So imagine that you have a domain that has a CDROM configured which source is a volume from an inactive pool. Because it is startupPolicy='optional', the CDROM is empty when the domain starts. However, the source element is not cleared out in the status XML and thus when the daemon restarts and tries to reconnect to the domain it refreshes the disks (which fails - the storage pool is still not running) and thus the domain is killed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The virMacMap module is there for dumping [domain, <list of is MACs>] pairs into a file so that libvirt_guest NSS module can use it. Whenever a interface is allocated from network (e.g. on domain<F2> startup or NIC hotplug), network is notified and so is virMacMap module subsequently. The module update functions networkMacMgrAdd() and networkMacMgrDel() gracefully handle the case when there's no module. The problem is, the module is created if and only if network is freshly started, or if the daemon restarts and network previously had the module. This is not very user friendly - if users want to use the NSS module they need to destroy their network and bring it up again (and subsequently all the domains using it). One disadvantage of this approach implemented here is that one may get just partial results: any already running network does not record mac maps, thus only newly plugged domains will be stored in the module. The network restart scenario is not touched by this of course. But one can argue that older libvirts had never recorded the mac maps anyway. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So far our code is full of the following pattern: dom = virGetDomain(conn, name, uuid) if (dom) dom->id = 42; There is no reasong why it couldn't be just: dom = virGetDomain(conn, name, uuid, id); After all, client domain representation consists of tuple (name, uuid, id). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 02 4月, 2017 1 次提交
-
-
由 Daniel Veillard 提交于
* docs/news.xml: update for release * po/*.po*: regenerated
-
- 01 4月, 2017 3 次提交
-
-
由 Roman Bogorodskiy 提交于
USB tables -> USB tablet.
-
由 Dawid Zamirski 提交于
that is: s/hyperyVerifyResponse/hypervVerifyResponse/
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1389313Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 31 3月, 2017 2 次提交
-
-
由 Erik Skultety 提交于
There was an unhandled 'open' call which resulted in: "error: Library function returned error but did not set virError" Even if this happens during the daemon's start when we still don't have any set of outputs defined yet, we can safely report an error, since we automatically fallback to stderr which is fine even for both running as a daemonized process, since this happens before the daemon forks into the background, and running as a systemd service, since systemd re-directs std outputs to journald by default. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1436060Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Peter Krempa 提交于
After the release it's necessary to add a new <release> section for the upcoming release. Add a template so that it does not have to be compiled over and over again.
-
- 30 3月, 2017 5 次提交
-
-
由 Michal Privoznik 提交于
In 9e246583 a check that denies internal snapshots when pflash based loader is configured for the domain. However, if there's none and an user tries to do an internal snapshot they will witness daemon crash as in that case vm->def->os.loader is NULL and we dereference it unconditionally. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jiri Denemark 提交于
CPU features which change their value from disabled to enabled between two calls to query-cpu-model-expansion (the first with no extra properties set and the second with 'migratable' property set to false) can be marked as enabled and non-migratable in qemuMonitorCPUModelInfo. Since the code consuming qemuMonitorCPUModelInfo currently ignores the migratable flag, this change is effectively changing the CPU model advertised in domain capabilities to contain all features (even those which block migration). And this matches what we do for QEMU older than 2.9.0, when we detect all CPUID bits ourselves without asking QEMU. As a result of this change <cpu mode='host-model'> <feature name='invtsc' policy='require'/> </cpu> will work with all QEMU versions. Such CPU definition would be forbidden with QEMU >= 2.9.0 without this patch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
QEMU is able to tell us whether a CPU feature would block migration or not. This patch adds support for storing such features in qemuMonitorCPUModelInfo. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Roman Bogorodskiy 提交于
- Add a news entry - Update the driver page with documentation of the new options and some examples
-
- 29 3月, 2017 5 次提交
-
-
由 Peter Krempa 提交于
When idx is 0 virStorageFileChainLookup returns the base (bottom) of the backing chain rather than the top. This is expected by the callers of qemuDomainGetStorageSourceByDevstr. Add a special case for idx == 0
-
由 Ján Tomko 提交于
Since commit fcbbb289 we steal the pointer to the storage pool source name if there was no pool name specified. Properly duplicate the string to avoid freeing it twice. https://bugzilla.redhat.com/show_bug.cgi?id=1436400
-
由 Ján Tomko 提交于
Pool types that have the VIR_STORAGE_POOL_SOURCE_NAME flag set allow omitting the <name> element and instead fill out the pool name from the <source><name> element. Relax the schema to make <name> optional for these pools. Expressing that at least one of these is required is out of scope of the schema.
-
由 Michal Privoznik 提交于
One of the problems with our virGetDomain function is that it copies just domain name and domain UUID. Therefore it's very easy to forget aboud domain ID. This can cause some bugs, like virConnectGetAllDomainStats not reporting proper domain IDs. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1434882 Imagine the following scenario: 1) virsh net-start default 2) virsh start myFavouriteDomain 3) virsh net-destroy default 4) virsh destroy myFavouriteDomain (assuming myFavouriteDomain has an interface from default network) Regardless of how unlikely this scenario looks like, we should not crash. The problem is, on net-destroy in networkShutdownNetworkVirtual() the virMacMap module is unrefed, but the stale pointer is kept around. Thus when the domain destroy procedure comes in, networkReleaseActualDevice() and subsequently networkMacMgrDel() is called. This function sees the stale pointer and starts calling the virMacMap module APIs which work over freed memory. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 28 3月, 2017 13 次提交
-
-
由 Peter Krempa 提交于
Mention the hyperv notifier and the new API to set block thresholds.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1398087 Clean up the virsh man page description for --pool-create-as in order to better describe how the various arguments are used when creating (or defining) a logical pool. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
off_t is signed and it's size is the same as long only on 64b archs. Thus it cannot be formatted as %lu. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
-
由 Andrea Bolognani 提交于
These tests cover a number of scenarios where we care about the memory locking limit being set correctly for the guest to work properly.
-
由 Andrea Bolognani 提交于
This will be used later on in the test suite.
-
由 Andrea Bolognani 提交于
The value we use internally to represent the lack of a memory locking limit, VIR_DOMAIN_MEMORY_PARAM_UNLIMITED, doesn't match the value setrlimit() and prlimit() use for the same purpose, RLIM_INFINITY, so we have to handle the translation ourselves. Partially-resolves: https://bugzilla.redhat.com/1431793
-
由 Andrea Bolognani 提交于
For guests that use <memoryBacking><locked>, our only option is to remove the memory locking limit altogether. Partially-resolves: https://bugzilla.redhat.com/1431793
-
由 Andrea Bolognani 提交于
Instead of having a separate function, we can simply return zero from the existing qemuDomainGetMemLockLimitBytes() to signal the caller that the memory locking limit doesn't need to be set for the guest. Having a single function instead of two makes it less likely that we will use the wrong value, which is exactly what happened when we started applying the limit that was meant for VFIO-using guests to <memoryBacking><locked>-using guests.
-
由 Andrea Bolognani 提交于
This reverts commit c2e60ad0. Turns out this check is excessively strict: there are ways other than <memtune><hard_limit> to raise the memory locking limit for QEMU processes, one prominent example being tweaking /etc/security/limits.conf. Partially-resolves: https://bugzilla.redhat.com/1431793
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Commits 29f7b5ea and 5edf9aaf pushed them incorrectly at the end of the file in the bug fixes section for libvirt 2.5.0. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-