[libvirt] [PATCH v2] storage: dir: adapts .wipeVol for ploop volumes
by Olga Krishtal
The modification of .volWipe callback wipes ploop volume using one of
given wiping algorithm: dod, nnsa, etc.
However, in case of ploop volume we need to reinitialize root.hds and DiskDescriptor.xml.
v2:
- added check on ploop tools presens
- virCommandAddArgFormat changed to virCommandAddArg
Signed-off-by: Olga Krishtal <okrishtal(a)virtuozzo.com>
---
src/storage/storage_backend.c | 68 +++++++++++++++++++++++++++++++++++++++----
1 file changed, 62 insertions(+), 6 deletions(-)
diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
index 5adf1fd..14b3a64 100644
--- a/src/storage/storage_backend.c
+++ b/src/storage/storage_backend.c
@@ -2195,6 +2195,55 @@ virStorageBackendWipeLocal(virStorageVolDefPtr vol,
return ret;
}
+static int
+virStorageBackendVolWipePloop(virStorageVolDefPtr vol)
+{
+ virCommandPtr cmd = NULL;
+ char *target_path = NULL;
+ char *disk_desc = NULL;
+ char *create_tool = NULL;
+
+ int ret = -1;
+
+ create_tool = virFindFileInPath("ploop");
+ if (!create_tool) {
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("unable to find ploop tools, please install them"));
+ return -1;
+ }
+
+ if (virAsprintf(&target_path, "%s/root.hds", vol->target.path) < 0)
+ goto cleanup;
+
+ if (virAsprintf(&disk_desc, "%s/DiskDescriptor.xml", vol->target.path) < 0)
+ goto cleanup;
+
+ if (virFileRemove(disk_desc, 0, 0) < 0) {
+ virReportError(errno, _("Failed to delete DiskDescriptor.xml of volume '%s'"),
+ vol->target.path);
+ goto cleanup;
+ }
+ if (virFileRemove(target_path, 0, 0) < 0) {
+ virReportError(errno, _("failed to delete root.hds of volume '%s'"),
+ vol->target.path);
+ goto cleanup;
+ }
+
+ cmd = virCommandNewArgList(create_tool, "init", "-s", NULL);
+
+ virCommandAddArgFormat(cmd, "%lluM", VIR_DIV_UP(vol->target.capacity,
+ (1024 * 1024)));
+ virCommandAddArgList(cmd, "-t", "ext4", NULL);
+ virCommandAddArg(cmd, target_path);
+ ret = virCommandRun(cmd, NULL);
+
+ cleanup:
+ VIR_FREE(disk_desc);
+ VIR_FREE(target_path);
+ VIR_FREE(create_tool);
+ virCommandFree(cmd);
+ return ret;
+}
int
virStorageBackendVolWipeLocal(virConnectPtr conn ATTRIBUTE_UNUSED,
@@ -2207,6 +2256,8 @@ virStorageBackendVolWipeLocal(virConnectPtr conn ATTRIBUTE_UNUSED,
const char *alg_char = NULL;
struct stat st;
virCommandPtr cmd = NULL;
+ char *path = NULL;
+ char *target_path = vol->target.path;
virCheckFlags(0, -1);
@@ -2214,12 +2265,12 @@ virStorageBackendVolWipeLocal(virConnectPtr conn ATTRIBUTE_UNUSED,
vol->target.path, algorithm);
if (vol->target.format == VIR_STORAGE_FILE_PLOOP) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("wiping for ploop volumes is not supported"));
- goto cleanup;
+ if (virAsprintf(&path, "%s/root.hds", vol->target.path) < 0)
+ goto cleanup;
+ target_path = path;
}
- fd = open(vol->target.path, O_RDWR);
+ fd = open(target_path, O_RDWR);
if (fd == -1) {
virReportSystemError(errno,
_("Failed to open storage volume with path '%s'"),
@@ -2276,13 +2327,12 @@ virStorageBackendVolWipeLocal(virConnectPtr conn ATTRIBUTE_UNUSED,
if (algorithm != VIR_STORAGE_VOL_WIPE_ALG_ZERO) {
cmd = virCommandNew(SCRUB);
virCommandAddArgList(cmd, "-f", "-p", alg_char,
- vol->target.path, NULL);
+ target_path, NULL);
if (virCommandRun(cmd, NULL) < 0)
goto cleanup;
ret = 0;
- goto cleanup;
} else {
if (S_ISREG(st.st_mode) && st.st_blocks < (st.st_size / DEV_BSIZE)) {
ret = virStorageBackendVolZeroSparseFileLocal(vol, st.st_size, fd);
@@ -2292,10 +2342,16 @@ virStorageBackendVolWipeLocal(virConnectPtr conn ATTRIBUTE_UNUSED,
vol->target.allocation,
st.st_blksize);
}
+ if (ret < 0)
+ goto cleanup;
}
+ if (vol->target.format == VIR_STORAGE_FILE_PLOOP)
+ ret = virStorageBackendVolWipePloop(vol);
+
cleanup:
virCommandFree(cmd);
+ VIR_FREE(path);
VIR_FORCE_CLOSE(fd);
return ret;
}
--
1.8.3.1
7 years, 10 months
[libvirt] question about PCI new_id sysfs interface
by Jim Fehlig
After updating the dom0 kernel on one of my Xen test hosts, I noticed problems
with PCI hostdev management. E.g
# virsh nodedev-detach pci_0000_07_10_1
error: Failed to detach device pci_0000_07_10_1
error: Failed to add PCI device ID '8086 1520' to pciback: File exists
It turns out there was a small interface change to new_id with the following
commit to 3.16 kernel
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/dr...
which now causes xen_pciback to fail writes of "vendorid productid" to new_id. e.g.
# echo "8086 1520" > /sys/bus/pci/drivers/pciback/new_id
-bash: echo: write error: File exists
Interestingly, vfio doesn't encounter the same error
# echo "8086 1520" > /sys/bus/pci/drivers/vfio-pci/new_id
# echo $?
0
vfio-pci has:
static struct pci_driver vfio_pci_driver = {
.name = "vfio-pci",
.id_table = NULL, /* only dynamic ids */
while xen-pciback has:
static const struct pci_device_id pcistub_ids[] = {
{
.vendor = PCI_ANY_ID,
.device = PCI_ANY_ID,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
},
{0,},
};
static struct pci_driver xen_pcibk_pci_driver = {
.name = "pciback",
.id_table = pcistub_ids,
So any vendor/device pair will match for xen-pciback, while none will match for
vfio-pci.
But after reading that commit and the associated thread, it is not clear to me
how to best fix this. Options are
1. set .id_table to NULL for xen-pciback
2. drop using the new_id interface from libvirt
3. pass more values (subvendor, subdevice, class, etc) to the new_id interface
I'm not sure what problems, if any, options 1 and 2 might cause. Option 2 seems
the best approach since new_id seems to be a rather unsafe interface.
Thanks for your opinions!
Regards,
Jim
7 years, 10 months
Re: [libvirt] [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features
by David Hildenbrand
Are there any further comments, especially on patches 23-25, introducing new
QOM interfaces?
Also, if anybody is planning to look into this, please speak up :)
Otherwise it might make sense to put this onto the next KVM call agenda.
David
> This is our second attempt to implement CPU models for s390x. We realized
> that we also want to have features exposed via the CPU model. While doing
> that we realized that we want to have a better interface for libvirt.
>
> Unfortunately, CPU models on s390x are special and we have to take care of:
> - A CPU like z13 looks differently in various environments (under different
> LPAR versions, under different z/VM versions, under different KVM
> versions, export regulation) - we have _a lot_ of feature variability.
> - We still have certain features that are not published but might be
> implemented/introduced in the future. As they are a theoretical part
> of a CPU already, we have to find a way to model these future changes.
> - We still have certain features that are already published, but not
> implemented. Implementation might be added in the future in KVM.
> - We heavily rely on KVM to tell us which features it can actually
> virtualize - user space queries like "STFL(e)" give no guarantees.
> - Certain "subfeatures" were introduced in one run. In practice, they are
> always around, but in theory, subfeatures could be dropped in the future.
> - Just because two CPU models have the same features doesn't mean they
> are equal - some internal numbers might be different. E.g. we won't allow
> running a z13 under a zBC12 just by turning off features.
> - We cannot blindly enable all possible features for a CPU generation,
> the IBC "Instruction Blocking Control" in KVM will try to block
> instructions introduced with certain features. So a CPU generation always
> has some maximum feature set that is guaranteed to work.
>
> It all boils down to a specific released CPU to have.
> a) A fixed feature set that we expect it to be have on every hypervisor.
> b) A variable part that depends on the hypervisor and that could be
> extended in the future (adding not yet implemented features) that we
> always want to enable later on.
> c) A variable part that we want to enable only if requested - nested
> virtualization ("vsie") and assists are one example.
>
> But, the fixed feature set is not really what we want to use as a default.
> It is just like a really minimum, stable base.
>
> So we have
> a) A "stable" CPU model for each released CPU that will never change and
> maps to the minimum feature set we expect to be around on all
> hypervisors. e.g. "z13-base" or "z10EC.2-base". These are migration
> safe.
> b) A "default" CPU model for each released CPU, that can change between
> QEMU versions and that will always include the features we expect to
> be around in our currently supported environments and will contain only
> features we expect to be stable. E.g. nested virtualization will not be
> contained in these models. These models are not migration safe, e.g
> "z13" or "z10EC.2". The feature set can differ between QEMU versions.
> c) An internal "maximum" CPU model for each generation that tells us which
> features were supported as a maximum back when the hardware was
> released. This will not be exposed
>
> To not have to replicate all CPU model changes ("new default fetaures") in
> libvirt, to not duplicate the logic about compatibility and the like,
> our approach tries to keep all the QEMU logic in libvirt and provide
> standardized interfaces for libvirt to e.g. baseline, compare. This
> allows libvirt to not have to care about any model names or feature names,
> it can just pass the data from interface to interface and report it to
> the user.
>
> Also, libvirt might want to know what the "host" model looks like and
> convert a CPU model to a migration safe variant. For this reason, a QMP
> command is added that can create a migration safe variant of a variable
> CPU model, indicating only the delta changes done to a stable model.
>
> So we have:
> a) "query-cpu-model-expansion" - tell us what the "host" or a migration
> unsafe model looks like. Either falling back to a stable model or
> completely exposing all properties. We are interested in stable models.
> b) "query-cpu-model-comparison" - tell us how two CPU models compare,
> indicating which properties were responsible for the decision.
> c) "query-cpu-model-baseline" - create a new model out of two models,
> taking a requested level of stability into account.
>
> As we are aware that e.g. x86 has their own idea of a CPU model and their
> existing implementation in place, but are also looking into to ways to e.g.
> expand the "host" CPU model to a detailed representation, we designed the
> "expansion" interface to also allow that.
>
> Comments are very welcome, but please always keep the restrictions and
> specialties in mind when suggesting some major design changes.
>
> The header update will be replaced by a kvm-next header update as soon as
> the VSIE patches are upstream. The major KVM interface changes are already
> part of kvm-next.
>
> The current state is available on git://github.com/cohuck/qemu on branch
> "cpumodel-s390x".
>
> David Hildenbrand (26):
> s390x/cpumodel: "host" and "qemu" as CPU subclasses
> s390x/cpumodel: expose CPU class properties
> s390x/cpumodel: generate CPU feature group lists
> s390x/cpumodel: introduce CPU feature group definitions
> s390x/cpumodel: register defined CPU models as subclasses
> s390x/cpumodel: store the CPU model in the CPU instance
> s390x/cpumodel: expose features and feature groups as properties
> s390x/cpumodel: let the CPU model handle feature checks
> s390x/cpumodel: check and apply the CPU model
> s390x/sclp: factor out preparation of cpu entries
> s390x/sclp: introduce sclp feature blocks
> s390x/sclp: indicate sclp features
> s390x/sclp: propagate the ibc val(lowest and unblocked ibc)
> s390x/sclp: propagate the mha via sclp
> s390x/sclp: propagate hmfai
> update linux headers (CPU model)
> s390x/kvm: allow runtime-instrumentation for "none" machine
> s390x/kvm: implement CPU model support
> s390x/kvm: disable host model for existing compat machines
> s390x/kvm: let the CPU model control CMM(A)
> qmp: add QMP interface "query-cpu-model-expansion"
> qmp: add QMP interface "query-cpu-model-comparison"
> qmp: add QMP interface "query-cpu-model-baseline"
> s390x/cpumodel: implement QMP interface "query-cpu-model-expansion"
> s390x/cpumodel: implement QMP interface "query-cpu-model-comparison"
> s390x/cpumodel: implement QMP interface "query-cpu-model-baseline"
>
> Michael Mueller (2):
> s390x/cpumodel: introduce CPU features
> s390x/cpumodel: generate CPU feature lists for CPU models
>
> Makefile.target | 2 +-
> hw/s390x/s390-virtio-ccw.c | 5 +
> hw/s390x/s390-virtio.c | 6 +-
> hw/s390x/sclp.c | 35 +-
> include/hw/s390x/sclp.h | 17 +-
> include/sysemu/arch_init.h | 10 +
> linux-headers/asm-s390/kvm.h | 40 ++
> qapi-schema.json | 184 ++++++
> qmp-commands.hx | 18 +
> qmp.c | 22 +
> rules.mak | 1 +
> stubs/Makefile.objs | 3 +
> stubs/arch-query-cpu-model-baseline.c | 13 +
> stubs/arch-query-cpu-model-comparison.c | 12 +
> stubs/arch-query-cpu-model-expansion.c | 12 +
> target-s390x/Makefile.objs | 22 +-
> target-s390x/cpu-qom.h | 5 +
> target-s390x/cpu.c | 35 +-
> target-s390x/cpu.h | 5 +
> target-s390x/cpu_features.c | 376 +++++++++++
> target-s390x/cpu_features.h | 302 +++++++++
> target-s390x/cpu_models.c | 1055 +++++++++++++++++++++++++++++++
> target-s390x/cpu_models.h | 113 ++++
> target-s390x/gen-features.c | 587 +++++++++++++++++
> target-s390x/helper.c | 29 +-
> target-s390x/kvm.c | 346 +++++++++-
> target-s390x/machine.c | 14 +-
> 27 files changed, 3203 insertions(+), 66 deletions(-)
> create mode 100644 stubs/arch-query-cpu-model-baseline.c
> create mode 100644 stubs/arch-query-cpu-model-comparison.c
> create mode 100644 stubs/arch-query-cpu-model-expansion.c
> create mode 100644 target-s390x/cpu_features.c
> create mode 100644 target-s390x/cpu_features.h
> create mode 100644 target-s390x/cpu_models.c
> create mode 100644 target-s390x/cpu_models.h
> create mode 100644 target-s390x/gen-features.c
>
7 years, 10 months
[libvirt] gconfig: Add hostdev support v4
by Zeeshan Ali (Khattak)
Finally I got the time to clean-up and fix the patches. It's been a while last i looked into them already and I got a bit confused at some point so I appologize if I didn't address some of the review comments.
7 years, 10 months
[libvirt] [PATCH v3 00/10] Add support for LUKS encrypted devices
by John Ferlan
v2: http://www.redhat.com/archives/libvir-list/2016-June/msg01691.html
Changes since v2 (all as a result of code review)
Patch 1: New as a result of review comment regarding virSecretDefFormatUsage
Patch 2: Change "id" to "name", fixed the html.in, remove whitespice,
generated patch 1 due to virSecretDefFormatUsage comment
Patch 3: Altered the html.in, don't believe the review comment for
wrong type in qemuProcessGetVolumeQcowPassphrase is right,
also modified the testdata output file to follow suggestion
for changes made in patch 5 & 6
Patch 4: Was essentially ACK'd, but requires previous patches. Took care
of the testdata output file.
Patch 5: Adjusted html.in, modified virStorageEncryptionInfoDef to have
both cipher_* and ivgen_* params in it - affected other places
(and fixed those),
Patch 6: Essentially ACK'd (the chmod was removed)
Patch 7: NEW - going to need this for hot unplug...
Patch 8: Adjusted per review of this series and the other 3 patch series
for rbd disk hot plug/unplug
Patch 9: NEW - Need to generate a different alias for LUKS
Patch 10: Mostly unchanged except to utilze the luks specific alias
generation... also moved the unplug to right place.
John Ferlan (10):
conf: No need to check for usage fields during Format
conf: Add new secret type "passphrase"
util: Add 'usage' for encryption
encryption: Add luks parsing for storageencryption
encryption: Add <cipher> and <ivgen> to encryption
storage: Add support to create a luks volume
qemu: Introduce helper qemuDomainSecretDiskCapable
qemu: Add secinfo for hotplug virtio disk
qemu: Alter the qemuDomainGetSecretAESAlias to add new arg
qemu: Add luks support for domain disk
docs/aclpolkit.html.in | 4 +
docs/formatsecret.html.in | 62 ++++-
docs/formatstorageencryption.html.in | 115 ++++++++-
docs/schemas/secret.rng | 10 +
docs/schemas/storagecommon.rng | 57 ++++-
include/libvirt/libvirt-secret.h | 3 +-
src/access/viraccessdriverpolkit.c | 13 ++
src/conf/domain_conf.c | 11 +
src/conf/secret_conf.c | 36 ++-
src/conf/secret_conf.h | 1 +
src/conf/virsecretobj.c | 5 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_alias.c | 10 +-
src/qemu/qemu_alias.h | 3 +-
src/qemu/qemu_command.c | 9 +
src/qemu/qemu_domain.c | 58 +++--
src/qemu/qemu_domain.h | 3 +
src/qemu/qemu_hotplug.c | 123 +++++++++-
src/qemu/qemu_process.c | 19 +-
src/storage/storage_backend.c | 260 +++++++++++++++++++--
src/storage/storage_backend.h | 3 +-
src/storage/storage_backend_fs.c | 10 +-
src/storage/storage_backend_gluster.c | 2 +
src/util/virqemu.c | 23 ++
src/util/virqemu.h | 6 +
src/util/virstorageencryption.c | 166 +++++++++++--
src/util/virstorageencryption.h | 18 +-
.../qemuxml2argv-encrypted-disk-usage.args | 24 ++
.../qemuxml2argv-encrypted-disk-usage.xml | 36 +++
.../qemuxml2argv-luks-disk-cipher.args | 36 +++
.../qemuxml2argv-luks-disk-cipher.xml | 45 ++++
.../qemuxml2argvdata/qemuxml2argv-luks-disks.args | 36 +++
tests/qemuxml2argvdata/qemuxml2argv-luks-disks.xml | 45 ++++
tests/qemuxml2argvtest.c | 12 +-
.../qemuxml2xmlout-encrypted-disk-usage.xml | 1 +
.../qemuxml2xmlout-luks-disk-cipher.xml | 1 +
.../qemuxml2xmlout-luks-disks.xml | 1 +
tests/qemuxml2xmltest.c | 3 +
tests/secretxml2xmlin/usage-passphrase.xml | 7 +
tests/secretxml2xmltest.c | 1 +
tests/storagevolxml2argvtest.c | 3 +-
tests/storagevolxml2xmlin/vol-luks-cipher.xml | 23 ++
tests/storagevolxml2xmlin/vol-luks.xml | 21 ++
tests/storagevolxml2xmlout/vol-luks-cipher.xml | 23 ++
tests/storagevolxml2xmlout/vol-luks.xml | 21 ++
tests/storagevolxml2xmltest.c | 2 +
46 files changed, 1267 insertions(+), 105 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk-usage.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk-usage.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-luks-disk-cipher.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-luks-disk-cipher.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-luks-disks.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-luks-disks.xml
create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-encrypted-disk-usage.xml
create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-luks-disk-cipher.xml
create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-luks-disks.xml
create mode 100644 tests/secretxml2xmlin/usage-passphrase.xml
create mode 100644 tests/storagevolxml2xmlin/vol-luks-cipher.xml
create mode 100644 tests/storagevolxml2xmlin/vol-luks.xml
create mode 100644 tests/storagevolxml2xmlout/vol-luks-cipher.xml
create mode 100644 tests/storagevolxml2xmlout/vol-luks.xml
--
2.5.5
7 years, 10 months
[libvirt] [PATCH 0/6] bhyve: virConnectDomainXMLFromNative
by Fabian Freyer
Differences to v3:
functional changes:
- Throw an error when there is no bhyverun command (bhyve_argv == NULL)
- Parse the memory size in the same way bhyve does it, and adapt the
relevant
code (vm_parse_memsize) from the FreeBSD source tree.
Here I'm a bit unsure about attribution; the original function comes
from a
BSD 2-Clause Licenced file, and I'm not sure if I also have to
include the
BSD disclaimer to the header.
- Removed capability check for clock offset
- Fix a mixup of NMDM master and slave
- Fixed numbering of disks. When >25 disks are given, disks after
vdz/sdz no
longer get added.
- Fail completely should parsing fail.
bugfixes:
- Fix a possible Null-Pointer dereference in
bhyveParseCommandLineString when
no loader command is given.
- Fix an off-by-one in the string allocation (bhyve_parse_command.c:60)
style:
- Fix some indentation
- Move else-clauses on the same line as the closing bracket from the if
Link to v3:
https://www.redhat.com/archives/libvir-list/2016-June/msg01741.html
Link to v2:
https://www.redhat.com/archives/libvir-list/2016-June/msg00728.html
Link to v1:
https://www.redhat.com/archives/libvir-list/2016-June/msg00001.html
Fabian Freyer (6):
config-post.h: define __GNUC_PREREQ if not defined
gnulib: add getopt module
bhyve: implement virConnectDomainXMLFromNative
bhyve: implement bhyve argument parser
bhyve: implement argument parser for loader
Add some tests for bhyveParseCommandLineString
bootstrap.conf | 1 +
config-post.h | 18 +
m4/virt-driver-bhyve.m4 | 3 +
po/POTFILES.in | 1 +
src/Makefile.am | 2 +
src/bhyve/bhyve_driver.c | 42 +
src/bhyve/bhyve_parse_command.c | 892
+++++++++++++++++++++
src/bhyve/bhyve_parse_command.h | 30 +
tests/Makefile.am | 23 +-
.../bhyveargv2xmldata/bhyveargv2xml-acpiapic.args | 9 +
tests/bhyveargv2xmldata/bhyveargv2xml-acpiapic.xml | 20 +
tests/bhyveargv2xmldata/bhyveargv2xml-ahci-hd.args | 8 +
tests/bhyveargv2xmldata/bhyveargv2xml-ahci-hd.xml | 21 +
tests/bhyveargv2xmldata/bhyveargv2xml-base.args | 7 +
tests/bhyveargv2xmldata/bhyveargv2xml-base.xml | 16 +
.../bhyveargv2xml-bhyveload-bootorder.args | 13 +
.../bhyveargv2xml-bhyveload-bootorder.xml | 27 +
.../bhyveargv2xml-bhyveload-custom.args | 11 +
.../bhyveargv2xml-bhyveload-custom.xml | 18 +
.../bhyveargv2xml-bhyveload-mem-mismatch.args | 12 +
.../bhyveargv2xml-bhyveload-memsize-fail.args | 12 +
.../bhyveargv2xml-bhyveload-name-mismatch.args | 12 +
.../bhyveargv2xml-bhyveload-vda.args | 12 +
.../bhyveargv2xml-bhyveload-vda.xml | 21 +
.../bhyveargv2xml-bhyverun-mem-mismatch.args | 12 +
.../bhyveargv2xml-bhyverun-name-mismatch.args | 12 +
tests/bhyveargv2xmldata/bhyveargv2xml-cdrom.args | 8 +
tests/bhyveargv2xmldata/bhyveargv2xml-cdrom.xml | 21 +
tests/bhyveargv2xmldata/bhyveargv2xml-console.args | 10 +
tests/bhyveargv2xmldata/bhyveargv2xml-console.xml | 28 +
.../bhyveargv2xmldata/bhyveargv2xml-console2.args | 10 +
tests/bhyveargv2xmldata/bhyveargv2xml-console2.xml | 15 +
.../bhyveargv2xmldata/bhyveargv2xml-console3.args | 11 +
tests/bhyveargv2xmldata/bhyveargv2xml-console3.xml | 27 +
.../bhyveargv2xmldata/bhyveargv2xml-console4.args | 10 +
tests/bhyveargv2xmldata/bhyveargv2xml-console4.xml | 15 +
.../bhyveargv2xml-custom-loader.args | 8 +
.../bhyveargv2xml-custom-loader.xml | 18 +
.../bhyveargv2xml-disk-toomany.args | 34 +
.../bhyveargv2xml-disk-toomany.xml | 146 ++++
.../bhyveargv2xmldata/bhyveargv2xml-extraargs.args | 8 +
.../bhyveargv2xml-memsize-fail.args | 7 +
.../bhyveargv2xml-memsize-human.args | 7 +
.../bhyveargv2xml-memsize-human.xml | 16 +
.../bhyveargv2xml-memsize-large.args | 7 +
.../bhyveargv2xml-memsize-large.xml | 16 +
tests/bhyveargv2xmldata/bhyveargv2xml-name.args | 7 +
tests/bhyveargv2xmldata/bhyveargv2xml-name.xml | 16 +
tests/bhyveargv2xmldata/bhyveargv2xml-oneline.args | 1 +
tests/bhyveargv2xmldata/bhyveargv2xml-oneline.xml | 16 +
tests/bhyveargv2xmldata/bhyveargv2xml-utc.args | 8 +
tests/bhyveargv2xmldata/bhyveargv2xml-utc.xml | 16 +
tests/bhyveargv2xmldata/bhyveargv2xml-uuid.args | 8 +
tests/bhyveargv2xmldata/bhyveargv2xml-uuid.xml | 16 +
tests/bhyveargv2xmldata/bhyveargv2xml-uuid2.args | 8 +
tests/bhyveargv2xmldata/bhyveargv2xml-vcpus.args | 7 +
tests/bhyveargv2xmldata/bhyveargv2xml-vcpus.xml | 16 +
.../bhyveargv2xml-virtio-blk.args | 8 +
.../bhyveargv2xmldata/bhyveargv2xml-virtio-blk.xml | 21 +
.../bhyveargv2xml-virtio-net.args | 9 +
.../bhyveargv2xmldata/bhyveargv2xml-virtio-net.xml | 26 +
.../bhyveargv2xml-virtio-net2.args | 8 +
.../bhyveargv2xml-virtio-net2.xml | 16 +
.../bhyveargv2xml-virtio-net3.args | 8 +
.../bhyveargv2xml-virtio-net3.xml | 16 +
.../bhyveargv2xml-virtio-net4.args | 8 +
.../bhyveargv2xml-virtio-net4.xml | 21 +
tests/bhyveargv2xmlmock.c | 27 +
tests/bhyveargv2xmltest.c | 213 +++++
69 files changed, 2174 insertions(+), 3 deletions(-)
create mode 100644 src/bhyve/bhyve_parse_command.c
create mode 100644 src/bhyve/bhyve_parse_command.h
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-acpiapic.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-acpiapic.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-ahci-hd.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-ahci-hd.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-base.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-base.xml
create mode 100644
tests/bhyveargv2xmldata/bhyveargv2xml-bhyveload-bootorder.args
create mode 100644
tests/bhyveargv2xmldata/bhyveargv2xml-bhyveload-bootorder.xml
create mode 100644
tests/bhyveargv2xmldata/bhyveargv2xml-bhyveload-custom.args
create mode 100644
tests/bhyveargv2xmldata/bhyveargv2xml-bhyveload-custom.xml
create mode 100644
tests/bhyveargv2xmldata/bhyveargv2xml-bhyveload-mem-mismatch.args
create mode 100644
tests/bhyveargv2xmldata/bhyveargv2xml-bhyveload-memsize-fail.args
create mode 100644
tests/bhyveargv2xmldata/bhyveargv2xml-bhyveload-name-mismatch.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-bhyveload-vda.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-bhyveload-vda.xml
create mode 100644
tests/bhyveargv2xmldata/bhyveargv2xml-bhyverun-mem-mismatch.args
create mode 100644
tests/bhyveargv2xmldata/bhyveargv2xml-bhyverun-name-mismatch.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-cdrom.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-cdrom.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-console.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-console.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-console2.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-console2.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-console3.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-console3.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-console4.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-console4.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-custom-loader.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-custom-loader.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-disk-toomany.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-disk-toomany.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-extraargs.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-memsize-fail.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-memsize-human.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-memsize-human.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-memsize-large.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-memsize-large.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-name.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-name.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-oneline.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-oneline.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-utc.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-utc.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-uuid.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-uuid.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-uuid2.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-vcpus.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-vcpus.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-blk.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-blk.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-net.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-net.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-net2.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-net2.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-net3.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-net3.xml
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-net4.args
create mode 100644 tests/bhyveargv2xmldata/bhyveargv2xml-virtio-net4.xml
create mode 100644 tests/bhyveargv2xmlmock.c
create mode 100644 tests/bhyveargv2xmltest.c
--
2.5.5
7 years, 10 months
[libvirt] [PATCH v2 0/2] virsh expand virsh list command options
by Chen Hanxiao
Chen Hanxiao (2):
virsh: allow both --uuid and --name at same cmd
virsh: enable --table with --name or --uuid
tools/virsh-domain-monitor.c | 56 +++++++++++++++++++++++++++++++++++++-------
1 file changed, 47 insertions(+), 9 deletions(-)
--
2.5.0
7 years, 10 months
[libvirt] [PATCH REPOST 00/38] Introduce APIs to change daemon's logging settings
by Erik Skultety
Basically the same series as
https://www.redhat.com/archives/libvir-list/2016-March/msg01534.html, just
rebased onto the current HEAD.
Daniel pointed out in 31/38 maybe we do not want to expose an API to set
logging level. Despite the truth being that the functionality of logging levels
can be replaced by logging filters completely, I think that it still provides
us with more convenience than having to specify a big bunch of filters.
Erik Skultety (38):
virlog: Return void instead of int in virLogReset<Foo> methods
virlog: Convert virLogOutputs to a list of pointers to outputs
virlog: Convert virLogFilters to a list of pointers to filters
virlog: Export virLogOutputPtr through header
virlog: Export virLogFilterPtr through header
virlog: Introduce virLogSetFilters
virlog: Introduce virLogSetOutputs
daemon: Replace virLogParseOutputs with virLogSetOutputs in callers
daemon: Replace virLogParseFilters with virLogSetFilters in callers
virlog: Introduce virLogDefineOutputs
virlog: Introduce virLogDefineFilters
virlog: Rename virLogAddOutputTo to virLogNewOutput
virlog: Rename virLogDefineOutput to virLogOutputNew
virlog: Rename virLogDefineFilter to virLogFilterNew
virlog: Introduce virLogOutputFree
virlog: Introduce virLogOutputListFree
virlog: Introduce virLogFilterFree
virlog: Introduce virLogFilterListFree
virlog: Make virLogReset methods use of virLog(Output|Filter)ListFree
virlog: Split output parsing and output defining to separate
operations
virlog: Split filter parsing and filter defining to separate
operations
virlog: Split parsing and setting priority
virlog: Introduce virLogOutputExists
virlog: Make use of virLogOutputExists
virlog: Take a special care of syslog when setting new set of log
outputs
virlog: Swap the new copy of outputs with the global existing one
virlog: Rename virLogFiltersSerial to virLogSerial
virlog: Make virLogSetDefaultPriority trigger source update as well
virlog: Introduce an API mutex that serializes all setters
virlog: Acquire virLogAPILock in each setter API
admin: Introduce virAdmConnectGetLoggingLevel
admin: Introduce virAdmConnectGetLoggingFilters
admin: Introduce virAdmConnectGetLoggingOutputs
admin: Introduce virAdmConnectSetLoggingLevel
admin: Introduce virAdmConnectSetLoggingFilters
admin: Introduce virAdmConnectSetLoggingOutputs
admin: Export logging level constants via libvirt-admin.h
virt-admin: Wire-up the logging APIs
daemon/admin.c | 126 ++++++++
daemon/libvirtd.c | 8 +-
include/libvirt/libvirt-admin.h | 37 +++
src/admin/admin_protocol.x | 74 ++++-
src/admin/admin_remote.c | 86 +++++
src/admin_protocol-structs | 39 +++
src/libvirt-admin.c | 220 +++++++++++++
src/libvirt_admin_private.syms | 9 +
src/libvirt_admin_public.syms | 6 +
src/libvirt_private.syms | 14 +-
src/locking/lock_daemon.c | 8 +-
src/logging/log_daemon.c | 8 +-
src/util/virlog.c | 698 +++++++++++++++++++++++++++-------------
src/util/virlog.h | 50 +--
tests/eventtest.c | 3 +-
tests/testutils.c | 19 +-
tests/virlogtest.c | 12 +-
tools/virt-admin.c | 204 ++++++++++++
18 files changed, 1361 insertions(+), 260 deletions(-)
--
2.4.11
7 years, 10 months
