- Devel - libvirt List Archives

[libvirt] [PATCH] qemu: Add support for overriding max threads per process limit
by Jim Fehlig 12 Jun '19

12 Jun '19

Some VM configurations may result in a large number of threads created by the associated qemu process which can exceed the system default limit. The maximum number of threads allowed per process is controlled by the pids cgroup controller and is set to 16k when creating VMs with systemd's machined service. The maximum number of threads per process is recorded in the pids.max file under the machine's pids controller cgroup hierarchy, e.g. $cgrp-mnt/pids/machine.slice/machine-qemu\\x2d1\\x2dtest.scope/pids.max Maximum threads per process is controlled with the TasksMax property of the systemd scope for the machine. This patch adds an option to qemu.conf which can be used to override the maximum number of threads allowed per qemu process. If the value of option is greater than zero, it will be set in the TasksMax property of the machine's scope after creating the machine. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/lxc/lxc_cgroup.c | 1 + src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf | 10 ++++++++++ src/qemu/qemu_cgroup.c | 1 + src/qemu/qemu_conf.c | 2 ++ src/qemu/qemu_conf.h | 1 + src/qemu/test_libvirtd_qemu.aug.in | 1 + src/util/vircgroup.c | 6 +++++- src/util/vircgroup.h | 1 + src/util/virsystemd.c | 24 +++++++++++++++++++++++- src/util/virsystemd.h | 3 ++- tests/virsystemdtest.c | 12 ++++++------ 12 files changed, 54 insertions(+), 9 deletions(-) diff --git a/src/lxc/lxc_cgroup.c b/src/lxc/lxc_cgroup.c index d93a19d684..76014f3bfd 100644 --- a/src/lxc/lxc_cgroup.c +++ b/src/lxc/lxc_cgroup.c @@ -455,6 +455,7 @@ virCgroupPtr virLXCCgroupCreate(virDomainDefPtr def, nnicindexes, nicindexes, def->resource->partition, -1, + 0, &cgroup) < 0) goto cleanup; diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug index b311f02da6..c70b903fed 100644 --- a/src/qemu/libvirtd_qemu.aug +++ b/src/qemu/libvirtd_qemu.aug @@ -94,6 +94,7 @@ module Libvirtd_qemu = | limits_entry "max_core" | bool_entry "dump_guest_core" | str_entry "stdio_handler" + | int_entry "max_threads_per_process" let device_entry = bool_entry "mac_filter" | bool_entry "relaxed_acs_check" diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf index 5a85789d81..ab044c9cf3 100644 --- a/src/qemu/qemu.conf +++ b/src/qemu/qemu.conf @@ -608,6 +608,16 @@ #max_processes = 0 #max_files = 0 +# If max_threads_per_process is set to a positive integer, libvirt +# will use it to set the maximum number of threads that can be +# created by a qemu process. Some VM configurations can result in +# qemu processes with tens of thousands of threads. systemd-based +# systems typically limit the number of threads per process to +# 16k. max_threads_per_process can be used to override default +# limits in the host OS. +# +#max_threads_per_process = 0 + # If max_core is set to a non-zero integer, then QEMU will be # permitted to create core dumps when it crashes, provided its # RAM size is smaller than the limit set. diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c index ca76c4fdfa..9603f33e8a 100644 --- a/src/qemu/qemu_cgroup.c +++ b/src/qemu/qemu_cgroup.c @@ -930,6 +930,7 @@ qemuInitCgroup(virDomainObjPtr vm, nnicindexes, nicindexes, vm->def->resource->partition, cfg->cgroupControllers, + cfg->maxThreadsPerProc, &priv->cgroup) < 0) { if (virCgroupNewIgnoreError()) goto done; diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index daea11dacb..8ac2dc92b5 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -687,6 +687,8 @@ virQEMUDriverConfigLoadProcessEntry(virQEMUDriverConfigPtr cfg, return -1; if (virConfGetValueUInt(conf, "max_files", &cfg->maxFiles) < 0) return -1; + if (virConfGetValueUInt(conf, "max_threads_per_process", &cfg->maxThreadsPerProc) < 0) + return -1; if (virConfGetValueType(conf, "max_core") == VIR_CONF_STRING) { if (virConfGetValueString(conf, "max_core", &corestr) < 0) diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h index 983e74a3cf..48b8711cbd 100644 --- a/src/qemu/qemu_conf.h +++ b/src/qemu/qemu_conf.h @@ -171,6 +171,7 @@ struct _virQEMUDriverConfig { unsigned int maxProcesses; unsigned int maxFiles; + unsigned int maxThreadsPerProc; unsigned long long maxCore; bool dumpGuestCore; diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in index fea1d308b7..ac7ad59ba8 100644 --- a/src/qemu/test_libvirtd_qemu.aug.in +++ b/src/qemu/test_libvirtd_qemu.aug.in @@ -75,6 +75,7 @@ module Test_libvirtd_qemu = { "set_process_name" = "1" } { "max_processes" = "0" } { "max_files" = "0" } +{ "max_threads_per_process" = "0" } { "max_core" = "unlimited" } { "dump_guest_core" = "1" } { "mac_filter" = "1" } diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c index f58e336404..c31c34e5f8 100644 --- a/src/util/vircgroup.c +++ b/src/util/vircgroup.c @@ -1106,6 +1106,7 @@ virCgroupNewMachineSystemd(const char *name, int *nicindexes, const char *partition, int controllers, + unsigned int maxthreads, virCgroupPtr *group) { int rv; @@ -1122,7 +1123,8 @@ virCgroupNewMachineSystemd(const char *name, isContainer, nnicindexes, nicindexes, - partition)) < 0) + partition, + maxthreads)) < 0) return rv; if (controllers != -1) @@ -1234,6 +1236,7 @@ virCgroupNewMachine(const char *name, int *nicindexes, const char *partition, int controllers, + unsigned int maxthreads, virCgroupPtr *group) { int rv; @@ -1250,6 +1253,7 @@ virCgroupNewMachine(const char *name, nicindexes, partition, controllers, + maxthreads, group)) == 0) return 0; diff --git a/src/util/vircgroup.h b/src/util/vircgroup.h index 377e0fd870..3fb99f70ef 100644 --- a/src/util/vircgroup.h +++ b/src/util/vircgroup.h @@ -99,6 +99,7 @@ int virCgroupNewMachine(const char *name, int *nicindexes, const char *partition, int controllers, + unsigned int maxthreads, virCgroupPtr *group) ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3); diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c index 3f03e3bd63..497d100a5c 100644 --- a/src/util/virsystemd.c +++ b/src/util/virsystemd.c @@ -238,12 +238,14 @@ int virSystemdCreateMachine(const char *name, bool iscontainer, size_t nnicindexes, int *nicindexes, - const char *partition) + const char *partition, + unsigned int maxthreads) { int ret; DBusConnection *conn; char *creatorname = NULL; char *slicename = NULL; + char *scopename = NULL; static int hasCreateWithNetwork = 1; if ((ret = virSystemdHasMachined()) < 0) @@ -389,11 +391,31 @@ int virSystemdCreateMachine(const char *name, goto cleanup; } + if (maxthreads > 0) { + if (!(scopename = virSystemdMakeScopeName(name, drivername, false))) + goto cleanup; + + if (virDBusCallMethod(conn, + NULL, + NULL, + "org.freedesktop.systemd1", + "/org/freedesktop/systemd1", + "org.freedesktop.systemd1.Manager", + "SetUnitProperties", + "sba(sv)", + scopename, + true, + 1, + "TasksMax", "t", maxthreads) < 0) + goto cleanup; + } + ret = 0; cleanup: VIR_FREE(creatorname); VIR_FREE(slicename); + VIR_FREE(scopename); return ret; } diff --git a/src/util/virsystemd.h b/src/util/virsystemd.h index 7d9c0ebd62..bdce3b2e9d 100644 --- a/src/util/virsystemd.h +++ b/src/util/virsystemd.h @@ -37,7 +37,8 @@ int virSystemdCreateMachine(const char *name, bool iscontainer, size_t nnicindexes, int *nicindexes, - const char *partition); + const char *partition, + unsigned int maxthreads); int virSystemdTerminateMachine(const char *name); diff --git a/tests/virsystemdtest.c b/tests/virsystemdtest.c index 82c02decd1..478fa844fa 100644 --- a/tests/virsystemdtest.c +++ b/tests/virsystemdtest.c @@ -172,7 +172,7 @@ static int testCreateContainer(const void *opaque ATTRIBUTE_UNUSED) 123, true, 0, NULL, - "highpriority.slice") < 0) { + "highpriority.slice", 0) < 0) { fprintf(stderr, "%s", "Failed to create LXC machine\n"); return -1; } @@ -205,7 +205,7 @@ static int testCreateMachine(const void *opaque ATTRIBUTE_UNUSED) 123, false, 0, NULL, - NULL) < 0) { + NULL, 0) < 0) { fprintf(stderr, "%s", "Failed to create KVM machine\n"); return -1; } @@ -242,7 +242,7 @@ static int testCreateNoSystemd(const void *opaque ATTRIBUTE_UNUSED) 123, false, 0, NULL, - NULL)) == 0) { + NULL, 0)) == 0) { unsetenv("FAIL_NO_SERVICE"); fprintf(stderr, "%s", "Unexpected create machine success\n"); return -1; @@ -276,7 +276,7 @@ static int testCreateSystemdNotRunning(const void *opaque ATTRIBUTE_UNUSED) 123, false, 0, NULL, - NULL)) == 0) { + NULL, 0)) == 0) { unsetenv("FAIL_NOT_REGISTERED"); fprintf(stderr, "%s", "Unexpected create machine success\n"); return -1; @@ -310,7 +310,7 @@ static int testCreateBadSystemd(const void *opaque ATTRIBUTE_UNUSED) 123, false, 0, NULL, - NULL)) == 0) { + NULL, 0)) == 0) { unsetenv("FAIL_BAD_SERVICE"); fprintf(stderr, "%s", "Unexpected create machine success\n"); return -1; @@ -345,7 +345,7 @@ static int testCreateNetwork(const void *opaque ATTRIBUTE_UNUSED) 123, true, nnicindexes, nicindexes, - "highpriority.slice") < 0) { + "highpriority.slice", 0) < 0) { fprintf(stderr, "%s", "Failed to create LXC machine\n"); return -1; } -- 2.21.0

1 1

[libvirt] [PATCH] build: fix linking libqemutestdriver with LTO enabled
by Jim Fehlig 12 Jun '19

12 Jun '19

openSUSE Factory is in the process of enabling Link Time Optimization [0] and stumbled upon missing symbols when linking libqemutestdriver libtool: link: gcc -shared -fPIC -DPIC ../src/libvirt_qemu_probes.o \ -Wl,--whole-archive ../src/.libs/libvirt_driver_qemu_impl.a \ ../src/.libs/libvirt_driver_network_impl.a \ ../src/.libs/libvirt_driver_storage_impl.a -Wl,--no-whole-archive \ -lcap-ng -lgnutls -lnl-route-3 -lnl-3 -ldbus-1 -lselinux -lapparmor \ /usr/lib/libxml2.so -ldl -lz -llzma -lm -lblkid -ltirpc \ -fstack-protector-strong -O2 -fstack-protector-strong -flto=16 -g -O2 \ -fstack-protector-strong -flto=16 -g \ -Wl,-soname -Wl,libqemutestdriver.so -o .libs/libqemutestdriver.so ... /usr/lib/gcc/i586-suse-linux/9/../../../../i586-suse-linux/bin/ld: ./.libs/libqemutestdriver.so: undefined reference to `mdir_name' /usr/lib/gcc/i586-suse-linux/9/../../../../i586-suse-linux/bin/ld: ./.libs/libqemutestdriver.so: undefined reference to `rpl_ioctl' /usr/lib/gcc/i586-suse-linux/9/../../../../i586-suse-linux/bin/ld: ./.libs/libqemutestdriver.so: undefined reference to `rpl_pipe2' /usr/lib/gcc/i586-suse-linux/9/../../../../i586-suse-linux/bin/ld: ./.libs/libqemutestdriver.so: undefined reference to `recvfd' /usr/lib/gcc/i586-suse-linux/9/../../../../i586-suse-linux/bin/ld: ./.libs/libqemutestdriver.so: undefined reference to `c_strcasecmp' The missing symbols are provided by GNUlib. Add it when linking libqemutestdriver. [0] https://en.opensuse.org/openSUSE:LTO Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- tests/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 46d94d2236..1d80647c9f 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -557,7 +557,7 @@ endif WITH_DTRACE_PROBES libqemutestdriver_la_SOURCES = libqemutestdriver_la_LDFLAGS = $(DRIVERLIB_LDFLAGS) -libqemutestdriver_la_LIBADD = $(qemu_LDADDS) +libqemutestdriver_la_LIBADD = $(qemu_LDADDS) $(GNULIB_LIBS) qemucpumock_la_SOURCES = \ qemucpumock.c testutilshostcpus.h @@ -729,7 +729,7 @@ lxcconf2xmltest_SOURCES = \ lxcconf2xmltest_LDADD = $(lxc_LDADDS) else ! WITH_LXC EXTRA_DIST += lxcxml2xmltest.c testutilslxc.c testutilslxc.h -endif ! WITH_LXC +-endif ! WITH_LXC if WITH_OPENVZ openvzutilstest_SOURCES = \ -- 2.21.0

3 8

[libvirt] [PATCH] test_driver: implement virDomainGetLaunchSecurityInfo
by Ilias Stamatis 12 Jun '19

12 Jun '19

Since this is the test driver and this is tied to AMD CPUs at the moment, we can pretend that the domain doesn't have launch security and always return 0 parameters. Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com> --- src/test/test_driver.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index 1aa79ce898..213f17808b 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -2284,6 +2284,18 @@ testDomainGetOSType(virDomainPtr dom ATTRIBUTE_UNUSED) } +static int +testDomainGetLaunchSecurityInfo(virDomainPtr domain ATTRIBUTE_UNUSED, + virTypedParameterPtr *params ATTRIBUTE_UNUSED, + int *nparams, + unsigned int flags) +{ + virCheckFlags(0, -1); + *nparams = 0; + return 0; +} + + static unsigned long long testDomainGetMaxMemory(virDomainPtr domain) { @@ -7011,6 +7023,7 @@ static virHypervisorDriver testHypervisorDriver = { .domainDestroy = testDomainDestroy, /* 0.1.1 */ .domainDestroyFlags = testDomainDestroyFlags, /* 4.2.0 */ .domainGetOSType = testDomainGetOSType, /* 0.1.9 */ + .domainGetLaunchSecurityInfo = testDomainGetLaunchSecurityInfo, /* 5.5.0 */ .domainGetMaxMemory = testDomainGetMaxMemory, /* 0.1.4 */ .domainSetMaxMemory = testDomainSetMaxMemory, /* 0.1.1 */ .domainSetMemory = testDomainSetMemory, /* 0.1.4 */ -- 2.21.0

2 1

[libvirt] [PATCH] tests: qemumonitorjson: Replace use of virReportError
by Peter Krempa 12 Jun '19

12 Jun '19

Use VIR_TEST_VERBOSE instead. This fixes the following syntax check problem: tests/qemumonitorjsontest.c:1409: virReportError(VIR_ERR_INTERNAL_ERROR, "arr should have been cleared"); Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- Pushed under the build-breaker rule. tests/qemumonitorjsontest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/qemumonitorjsontest.c b/tests/qemumonitorjsontest.c index 68b115fa89..e087d1c256 100644 --- a/tests/qemumonitorjsontest.c +++ b/tests/qemumonitorjsontest.c @@ -1406,7 +1406,7 @@ testQemuMonitorJSONqemuMonitorJSONMergeBitmaps(const void *opaque) return -1; if (arr) { - virReportError(VIR_ERR_INTERNAL_ERROR, "arr should have been cleared"); + VIR_TEST_VERBOSE("arr should have been cleared"); return -1; } -- 2.21.0

1 0

[libvirt] [PATCH 0/3] tests: uri: Improve uri testing and add test for urlencoded uris
by Peter Krempa 11 Jun '19

11 Jun '19

Peter Krempa (3): tests: uri: Use VIR_TEST_DEBUG instead of VIR_DEBUG tests: uri: Run all test cases on a single URI tests: uri: Add test for urlencoded URIs tests/viruritest.c | 80 +++++++++++++++++++++++++++------------------- 1 file changed, 47 insertions(+), 33 deletions(-) -- 2.21.0

2 4

[libvirt] [PATCH 0/3] qemu: Fix two block-job related regressions (blockdev-add saga)
by Peter Krempa 11 Jun '19

11 Jun '19

Peter Krempa (3): qemu: domain: Fix logic bug in qemuDomainStorageSourceAccessAllow qemu: domain: Allow overriding images to read-write in qemuDomainStorageSourceAccessAllow qemu: Use proper block job name when reconnecting to VM src/qemu/qemu_domain.c | 21 ++++++++++++++------- src/qemu/qemu_migration.c | 2 +- src/qemu/qemu_monitor.c | 7 ++++--- src/qemu/qemu_monitor.h | 3 ++- src/qemu/qemu_monitor_json.c | 12 ++++++++---- src/qemu/qemu_monitor_json.h | 3 ++- src/qemu/qemu_process.c | 2 +- 7 files changed, 32 insertions(+), 18 deletions(-) -- 2.21.0

2 6

[libvirt] [PATCH v2 0/4] test_driver: implement virDomainSaveImageGetXMLDesc and virDomainSaveImageDefineXML
by Ilias Stamatis 11 Jun '19

11 Jun '19

Changed in v2: * in testDomainSaveImageDefineXML check first that a saved image already exists before parsing the new file * reordered the arguments of testDomainSaveImageWrite in order for its signature to be consistent with testDomainSaveImageOpen While implementing virDomainSaveImageGetXMLDesc and virDomainSaveImageDefineXML for the test driver, I realized that there exists already code for saving and loading test images which can be reused. However, it needed to be extracted from testDomainSaveFlags and testDomainRestoreFlags into separate functions. The new functions are inspired by the corresponding QEMU driver code where e.g. qemuDomainSaveImageOpen serves as a helper used by other functions. This series of patches initially extracts the code mentioned above into separate functions and then provides the test driver with implementations for virDomainSaveImageGetXMLDesc and virDomainSaveImageDefineXML which make use of the newly introduced functions. Ilias Stamatis (4): test_driver: extract image saving code into a separate function test_driver: extract image loading code into a separate function test_driver: implement virDomainSaveImageDefineXML test_driver: implement virDomainSaveImageGetXMLDesc src/test/test_driver.c | 293 ++++++++++++++++++++++++++++------------- 1 file changed, 205 insertions(+), 88 deletions(-) -- 2.21.0

2 6

[libvirt] [jenkins-ci PATCH] lcitool: Don't warn when using package manager directly
by Andrea Bolognani 11 Jun '19

11 Jun '19

We only do this when performing operations that the corresponding Ansible module doesn't support, so we know what we're doing and don't want warnings to show up. Note that while only the dnf and yum modules complain at the moment, we might as well use warn=no everywhere so that we're already covered in case in the future the pkgng module starts detecting this as well. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- guests/playbooks/update/tasks/base.yml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/guests/playbooks/update/tasks/base.yml b/guests/playbooks/update/tasks/base.yml index 8fe114e..e0efe5d 100644 --- a/guests/playbooks/update/tasks/base.yml +++ b/guests/playbooks/update/tasks/base.yml @@ -52,11 +52,15 @@ - name: Update installed packages shell: '{{ package_manager }} update && {{ package_manager }} upgrade -y' + args: + warn: no when: - package_format == 'pkg' - name: Clean up packages after update shell: '{{ package_manager }} clean packages -y && {{ package_manager }} autoremove -y' + args: + warn: no when: - package_format == 'rpm' @@ -69,6 +73,8 @@ - name: Clean up packages after update shell: '{{ package_manager }} clean -y && {{ package_manager }} autoremove -y' + args: + warn: no when: - package_format == 'pkg' -- 2.21.0

2 4

Re: [libvirt] [Qemu-devel] PCI(e): Documentation "io-reserve" and related properties?
by Andrea Bolognani 11 Jun '19

11 Jun '19

On Thu, 2019-06-06 at 14:20 -0400, Michael S. Tsirkin wrote: > On Thu, Jun 06, 2019 at 06:19:43PM +0200, Kashyap Chamarthy wrote: > > Hi folks, > > > > Today I learnt about some obscure PCIe-related properties, in context of > > the adding PCIe root ports to a guest, namely: > > > > io-reserve > > mem-reserve > > bus-reserve > > pref32-reserve > > pref64-reserve > > > > Unfortunately, the commit[*] that added them provided no documentation > > whatsover. > > > > In my scenario, I was specifically wondering about what does > > "io-reserve" mean, in what context to use it, etc. (But documentation > > about other properties is also welcome.) > > > > Anyone more well-versed in this area care to shed some light? > > > > > > [*] 6755e618d0 (hw/pci: add PCI resource reserve capability to legacy > > PCI bridge, 2018-08-21) > > So normally bios would reserve just enough io space to satisfy all > devices behind a bridge. What if you intend to hotplug more devices? > These properties allow you to ask bios to reserve extra space. Is it fair to say that setting io-reserve=0 for a pcie-root-port would be a way to implement the requirements set forth in https://bugzilla.redhat.com/show_bug.cgi?id=1408810 ? I tested this on aarch64 and it seems to work as expected, but then again without documentation it's hard to tell. More specifically, I created an aarch64/virt guest with several pcie-root-ports and it couldn't boot much further than GRUB when the number of ports exceeded 24, but as soon as I added the io-reserve=0 option I could get the same guest to boot fine with 32 or even 64 pcie-root-ports. I'm attaching the boot log for reference: there are a bunch of messages about the topic but they would appear to be benign. Hotplug seemed to work too: I tried with a single virtio-net-pci and I could access the network. My understanding is that PCIe devices are required to work without IO space, so this behavior matches my expectations. I wonder, though, what would happen if I had something like -device pcie-root-port,io-reserve=0,id=pci.1 -device pcie-pci-bridge,bus=pci.1 Would I be able to hotplug conventional PCI devices into the pcie-pci-bridge, or would the lack of IO space reservation for the pcie-root-port cause issues with that? -- Andrea Bolognani / Red Hat / Virtualization

2 1

[libvirt] Question about Windows builds
by Christopher Loyd Nugent 11 Jun '19

11 Jun '19

My name is Christopher Nugent. This is my first time posting to the mailing list, and I am still adjusting to the community norms. If I do anything out of line, please let me know. Anyway, on to the question: I am attempting to use libvirt in a Windows application I am developing, and came upon the following in the documentation: Libvirt is known to work as a client (not server) on Windows XP (32-bit), and Windows 7 (64-bit). I am a bit confused as to what this means. Does it mean that I won't be able to use libvirt in a host configuration, Hyper-V acting as the underlying hypervisor? I am posting to the development list because, if I am right, I would like to donate my time to amend the situation. My application will be cross-platform and will support multiple hypervisors, so using libvirt will help me not have to duplicate functionality. Thank you for your time. --Chris Nugent.

2 1