- 04 4月, 2017 15 次提交
-
-
由 Peter Krempa 提交于
Use the relative lookup specifier rather than the global one. Otherwise only the first name would be looked up. Add a test case to cover the scenario. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1436574
-
由 Peter Krempa 提交于
Add a test program called virstorageutiltest and test the gluster pool detection code.
-
由 Peter Krempa 提交于
To allow testing of the algorithm, split out the extractor into a separate helper.
-
由 Peter Krempa 提交于
The native gluster pool source list data differs from the data used for attaching gluster volumes as netfs pools. Currently the only difference was the format. Since native pools don't use it and later there will be more differences add a more deterministic way to switch between the types instead.
-
由 Nikolay Shirokovskiy 提交于
-
由 Ján Tomko 提交于
Similar to commit b202c39a ignore the warning that breaks the build with clang: util/virnetlink.c:365:52: error: cast from 'char *' to 'struct nlmsghdr *' increases required alignment from 1 to 4 [-Werror,-Wcast-align] for (msg = resp; NLMSG_OK(msg, len); msg = NLMSG_NEXT(msg, len)) { ^~~~~~~~~~~~~~~~~~~~ /usr/include/linux/netlink.h:87:7: note: expanded from macro 'NLMSG_NEXT' (struct nlmsghdr*)(((char*)(nlh)) + NLMSG_ALIGN((nlh)->nlmsg_len))) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
由 Peter Krempa 提交于
Make sure that non-hotpluggable vcpus stay clustered at the beginning after modifying persistent definition. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437010
-
由 Peter Krempa 提交于
Validate that users don't try to disable vcpu 0.
-
由 Peter Krempa 提交于
Vcpu order is required to stay sequential. Clear the order on cpu coldplug to avoid issues with removing vcpus out of sequence.
-
由 Peter Krempa 提交于
'next' is declared as 'ssize_t' so use '%zd'
-
由 Peter Krempa 提交于
Buggy condition meant that vcpu0 would not be iterated in the checks. Since it's not hotpluggable anyways we would not be able to break the configuration of a live VM. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437013
-
由 Erik Skultety 提交于
Like all devices, add the 'id' option for mdevs as well. Patch also adjusts the test accordingly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438431Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1371892 The 'capacity' value (e.g. guest logical size) for a LUKS volume is smaller than the 'physical' value of the file in the file system, so we need to account for that. When peeking at the encryption information about the volume add a fetch of the payload_offset which is described as the offset to the start of the volume data (in 512 byte sectors) in QEMU's QCryptoBlockLUKSHeader. Then adjust the ->capacity appropriately when we determine that the volume target encryption has a payload_offset value.
-
由 Cédric Bosdonnat 提交于
Add check for more than one RTA_OIF, even though this is rather unlikely. Get rid of the buggy switch / break as this code won't need to handle more attributes. Use VIR_WARNINGS_NO_CAST_ALIGN to fix impossible to fix util/virnetdevip.c:560:17: error: cast increases required alignment of target type [-Werror=cast-align]
-
- 03 4月, 2017 7 次提交
-
-
由 Andrea Bolognani 提交于
Make sure every combination of ACPI and UEFI works, or fails to work, as expected.
-
由 Andrea Bolognani 提交于
Depending on the architecture, requirements for ACPI and UEFI can be different; more specifically, while on x86 UEFI requires ACPI, on aarch64 it's the other way around. Enforce these requirements when validating the domain, and make the error message more accurate by mentioning that they're not necessarily applicable to all architectures. Several aarch64 test cases had to be tweaked because they would have failed the validation step otherwise.
-
由 Andrea Bolognani 提交于
So far, libvirt has assumed that only x86 supports ACPI, but that's inaccurate since aarch64 supports it too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
-
由 Andrea Bolognani 提交于
Now that the NO_ACPI and NO_HPET capabilities are set automatically by virQEMUCapsInitQMPBasicArch() if appropriate for the architecture, they shouldn't be used manually to avoid masking bugs.
-
由 Andrea Bolognani 提交于
The capabilities used in test cases should match those used during normal operation for the tests to make any sense. This results in the generated command line for a few test cases (most notably non-x86 test cases that were wrongly assuming they could use -no-acpi) changing.
-
由 Andrea Bolognani 提交于
Instead of having a single function that probes the architecture from the monitor and then sets a bunch of basic capabilities based on it, have a separate function for each part: virQEMUCapsInitQMPArch() only sets the architecture, and virQEMUCapsInitQMPBasicArch() only sets the capabilities. This split will be useful later on, when we will want to set basic capabilities from the test suite without having to go through the pain of mocking the monitor.
-
由 Andrea Bolognani 提交于
Creating dummy <change> elements was a workaround for the HTML DTD not allowing empty <ul> elements, but we can do better by tweaking the the XSLT stylesheet.
-
- 01 4月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
Now that the source file is validated against a schema that only allows the <code> HTML tag to be used, we can rely on that assumption to simplify our XSLT stylesheet.
-
- 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.
-