[libvirt] [PATCH] qemuBuildVideoCommandLine: Don't access def->videos without check
by Michal Privoznik
This function can be called over a domain definition that has no
video configured. The
tests/qemuxml2argvdata/qemuxml2argv-minimal.xml file could serve
as an example. Problem is, before the check that domain has some
or none video configured, def->videos is dereferenced causing a
segmentation fault in case there's none video configured.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_command.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index ba8c216..32d32b1 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3809,7 +3809,7 @@ qemuBuildVideoCommandLine(virCommandPtr cmd,
virQEMUCapsPtr qemuCaps)
{
size_t i;
- int primaryVideoType = def->videos[0]->type;
+ int primaryVideoType;
if (!def->nvideos) {
/* If we have -device, then we set -nodefaults already */
@@ -3819,6 +3819,8 @@ qemuBuildVideoCommandLine(virCommandPtr cmd,
return 0;
}
+ primaryVideoType = def->videos[0]->type;
+
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIDEO_PRIMARY) &&
((primaryVideoType == VIR_DOMAIN_VIDEO_TYPE_VGA &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VGA)) ||
--
2.4.10
8 years, 8 months
[libvirt] Enhancement: Random Clock Offset
by bancfc＠openmailbox.org
For better system anonymity (to decouple VM OS timestamps leaked in
traffic from host ones) a feature can be added to the clock offset
variable to select randomly from a specified range of seconds from
instead of a fixed number of seconds. That way a guest's clock can vary
unpredictably from the host's and confuse correlation by network
adversaries.
Full Disclosure: I am from the Tor centric Whonix Project - whonix.org
and this would be a very useful feature for us.
8 years, 8 months
[libvirt] [PATCH REPOST 0/9] Reorganize qemu_command.c in smaller piles
by John Ferlan
Rather than hope for a review of 25 patches or creating some remote
place to place a branch - I'll repost the original:
http://www.redhat.com/archives/libvir-list/2016-February/msg00975.html
in smaller chunks. No differences in these patches other than a rebase
to top of tree a short while ago (commit id 'cf091094a'). There were also
no conflicts from changes since initial posting.
John Ferlan (9):
qemu: Introduce qemuBuildClockCommandLine
qemu: Introduce qemuBuildPMCommandLine
qemu: Introduce qemuBuildBootCommandLine
qemu: Introduce qemuBuildGlobalControllerCommandLine
qemu: Introduce qemuBuildControllerDevCommandLine
qemu: Introduce qemuBuildHubCommandLine
qemu: Introduce qemuBuildDiskDriveCommandLine
qemu: Introduce qemuBuildFSDevCommandLine
qemu: Introduce qemuBuildNetCommandLine
src/conf/domain_conf.c | 14 +-
src/conf/domain_conf.h | 8 +-
src/qemu/qemu_command.c | 5488 +++++++++++++++++++++-------------------
src/qemu/qemu_command.h | 15 +-
src/qemu/qemu_domain_address.c | 2 +-
src/qemu/qemu_domain_address.h | 2 +-
6 files changed, 2843 insertions(+), 2686 deletions(-)
--
2.5.0
8 years, 8 months
[libvirt] [PATCH 0/2] Fix building with clang (again)
by Martin Kletzander
*** SOME VERY RANDOM BLURB HERE ***
Martin Kletzander (2):
Skip pdwtags-related tests when compiling with clang
Fix build with clang
src/Makefile.am | 4 +++-
tests/qemuxml2argvmock.c | 28 ++++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 1 deletion(-)
--
2.7.3
8 years, 8 months
[libvirt] any better way to treat device-detach timeout ?
by Zhangbo (Oscar)
Hi,all:
I find that we remove devices only after DEVICE_DELETED event.(patch:3fbf78bd).
And it treats TIMEOUT as success. The detailed codes are shown as below:
rc = qemuDomainWaitForDeviceRemoval(vm);
if (rc == 0 || rc == 1)
ret = qemuDomainRemoveDiskDevice(driver, vm, detach);
else
ret = 0;
Here comes the problem:
If
1. We pass flags=3(VIR_DOMAIN_AFFECT_LIVE|VIR_DOMAIN_AFFECT_CONFIG) to virDomainDetachDeviceFlags,
2. It timed out to receive DEVICE_DELETED event, virDomainDetachDeviceFlags api will return 0(succeed).
Please be aware that: vm->newdef(persistent) removes the device while vm->def(transient) keeps it untouched.
3. Then we try to attach the same device with flag 3, because it differs in newDef and def, the API virDomainDetachDeviceFlags() returns ERROR.
Consequent attach/detach jobs all fail after then.
So, shall we make it return FAIL when it fails in qemuDomainWaitForDeviceRemoval()? Or just remove the device in def after we get the DEVICE_DELETED event?
Any ideas, thanks!
8 years, 8 months
[libvirt] [PATCH REPOST 0/8] Reorganize qemu_command.c in smaller piles (round 2)
by John Ferlan
Rather than hope for a review of 25 patches or creating some remote
place to place a branch - I'll repost the original:
http://www.redhat.com/archives/libvir-list/2016-February/msg00975.html
in smaller chunks. Differences in this set of patches vs. original series
includes handling merge conflicts for logManager series plus a few minor
edits/tweaks for better formatting/flow. This series was based off of
git head commit 'ef2ab8fdc' which is the round 1 of the split:
http://www.redhat.com/archives/libvir-list/2016-March/msg00288.html
John Ferlan (8):
qemu: Introduce qemuBuildSmartcardCommandLine
qemu: Introduce qemuBuildSerialCommandLine
qemu: Introduce qemuBuildParallelsCommandLine
qemu: Introduce qemuBuildChannelsCommandLine
qemu: Introduce qemuBuildConsoleCommandLine
qemu: Modify qemuBuildTPMCommandLine
qemu: Introduce qemuBuildInputCommandLine
qemu: Introduce qemuBuildVideoCommandLine
src/qemu/qemu_capabilities.c | 2 +-
src/qemu/qemu_capabilities.h | 2 +-
src/qemu/qemu_command.c | 1410 +++++++++++++++++++++++-------------------
src/qemu/qemu_command.h | 6 +-
4 files changed, 760 insertions(+), 660 deletions(-)
--
2.5.0
8 years, 8 months
[libvirt] [libvirt-glib v2 0/9] gconfig: Add hostdev support
by Christophe Fergeau
Hey,
While reviewing Zeeshan's libvirt-gconfig hostdev series, I fixed up a few
things, and added a few additional helpers/getters in order to simplify the
code/make the test case more complete.
This series contains this new code. The changes I made to Zeeshan's initial
patches are in separate fixup! commits to make reviewing them easier (for you Zeeshan ;).
I expect these to be squashed in the main commits before being pushed.
Zeeshan's commits are unchanged from v1.
Christophe
8 years, 8 months
[libvirt] [libvirt-glib v3 1/5] gconfig: Add gvir_config_object_has_child
by Christophe Fergeau
---
libvirt-gconfig/libvirt-gconfig-object-private.h | 2 ++
libvirt-gconfig/libvirt-gconfig-object.c | 13 +++++++++++++
2 files changed, 15 insertions(+)
diff --git a/libvirt-gconfig/libvirt-gconfig-object-private.h b/libvirt-gconfig/libvirt-gconfig-object-private.h
index e91c4ef..7a0d21f 100644
--- a/libvirt-gconfig/libvirt-gconfig-object-private.h
+++ b/libvirt-gconfig/libvirt-gconfig-object-private.h
@@ -117,6 +117,8 @@ GVirConfigObject *gvir_config_object_get_child(GVirConfigObject *object,
GVirConfigObject *gvir_config_object_get_child_with_type(GVirConfigObject *object,
const gchar *child_name,
GType child_type);
+gboolean gvir_config_object_has_child(GVirConfigObject *object,
+ const gchar *child_name);
G_END_DECLS
diff --git a/libvirt-gconfig/libvirt-gconfig-object.c b/libvirt-gconfig/libvirt-gconfig-object.c
index bf328f3..6225de2 100644
--- a/libvirt-gconfig/libvirt-gconfig-object.c
+++ b/libvirt-gconfig/libvirt-gconfig-object.c
@@ -970,3 +970,16 @@ gvir_config_object_get_child(GVirConfigObject *object,
child_name,
GVIR_CONFIG_TYPE_OBJECT);
}
+
+G_GNUC_INTERNAL gboolean
+gvir_config_object_has_child(GVirConfigObject *object, const gchar *child_name)
+{
+ xmlNodePtr node;
+
+ g_return_val_if_fail(GVIR_CONFIG_IS_OBJECT(object), FALSE);
+ g_return_val_if_fail(child_name != NULL, FALSE);
+
+ node = gvir_config_xml_get_element(object->priv->node, child_name, NULL);
+
+ return (node != NULL);
+}
--
2.5.0
8 years, 8 months
Re: [libvirt] dist-git build problem on epel-6-x86_64 chroot
by Jean-Marc LIGER
Le 19/02/2016 11:40, Miroslav Suchý a écrit :
> Dne 19.1.2016 v 17:01 Jean-Marc LIGER napsal(a):
>> Hy,
>>
>> I'm facing the problem below on epel-6-x86_64 chroot for both from URL and upload SRPM :
>>
>> [2016-01-19 15:16:26,790][ INFO][PID:3241] Setting up builder: 172.25.94.167
>> [2016-01-19 15:16:27,991][ INFO][PID:3241] marking build dir with build_id,
>> [2016-01-19 15:16:27,992][ INFO][PID:3241] Start build: BuildJob<id: 154509, owner: jmliger, project: virt6-upstream,
>> git branch: el6, git_hash: acef5efd6153aa8f9ea760f468333e65c9b46a4e, status: 3 >
>> [2016-01-19 15:16:27,993][ INFO][PID:3241] putting into minimal buildroot of epel-6-x86_64
>> [2016-01-19 15:16:28,902][ INFO][PID:3241] Cloning Dist Git repo jmliger/virt6-upstream/libvirt, branch
>> acef5efd6153aa8f9ea760f468333e65c9b46a4e, hash el6
>> [2016-01-19 15:16:30,906][ ERROR][PID:3241] Failed to obtain srpm from dist-git
>> Traceback (most recent call last):
>> File "/usr/share/copr/backend/mockremote/builder.py", line 209, in download_job_pkg_to_builder
>> self.remote_pkg_path = list(results["contacted"].values())[0][u"stdout"].split("Wrote: ")[1]
>> IndexError: list index out of range
>> [2016-01-19 15:16:30,911][ ERROR][PID:3241] builder.build error building pkg `libvirt`: BuildError: Failed to obtain
>> srpm from dist-git: ansible results {'dark': {}, 'contacted': {'172.25.94.167': {'cmd': 'rm -rf /tmp/build_package_repo
>> && mkdir /tmp/build_package_repo && cd /tmp/build_package_repo && git clone
>> http://copr-dist-git.fedorainfracloud.org/git/jmliger/virt6-upstream/libv... && cd libvirt && git checkout
>> acef5efd6153aa8f9ea760f468333e65c9b46a4e && fedpkg-copr --dist el6 srpm', 'end': '2016-01-19 15:16:30.308282', 'stdout':
>> 'Downloading libvirt-1.3.1.tar.gz\n\r
>> 0.0%\r
>> 100.0%\r######################################################################## 100.0%', 'changed': True, 'start':
>> '2016-01-19 15:16:28.758321', 'delta': '0:00:01.549961', 'stderr': "Cloning into 'libvirt'...\nNote: checking out
>> 'acef5efd6153aa8f9ea760f468333e65c9b46a4e'.\n\nYou are in 'detached HEAD' state. You can look around, make
>> experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any
>> branches by performing another checkout.\n\nIf you want to create a new branch to retain commits you create, you may\ndo
>> so (now or later) by using -b with the checkout command again. Example:\n\n git checkout -b <new-branch-name>\n\nHEAD
>> is now at acef5ef... import_srpm\nerror: line 1800: Trigger fired by the same package is already defined in spec file:
>> %post daemon-config-network\n\nerror: query of specfile /tmp/build_package_repo/libvirt/libvirt.spec failed, can't
>> parse\n\nCould not execute srpm: Could not get n-v-r-e from '\\n\\n'", 'rc': 1, 'invocation': {'module_name': 'shell',
>> 'module_complex_args': {}, 'module_args': u'rm -rf /tmp/build_package_repo && mkdir /tmp/build_package_repo && cd
>> /tmp/build_package_repo && git clone http://copr-dist-git.fedorainfracloud.org/git/jmliger/virt6-upstream/libv... &&
>> cd libvirt && git checkout acef5efd6153aa8f9ea760f468333e65c9b46a4e && fedpkg-copr --dist el6 srpm'}, 'warnings':
>> ['Consider using file module with state=absent rather than running rm']}}}
>> [2016-01-19 15:16:31,759][ INFO][PID:3241] End Build: BuildJob<id: 154509, owner: jmliger, project: virt6-upstream, git
>> branch: el6, git_hash: acef5efd6153aa8f9ea760f468333e65c9b46a4e, status: 3 >
>>
>> https://copr.fedoraproject.org/coprs/jmliger/virt6-upstream/builds/
>>
>> Regards,
>> Jean-Marc LIGER
>>
>>
>> _______________________________________________
>> copr-devel mailing list
>> copr-devel(a)lists.fedorahosted.org
>> https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org
> It is some problem with your spec file.
> You can reproduce it by installing fedpkg-copr from our Copr project and
> git clone http://copr-dist-git.fedorainfracloud.org/git/jmliger/virt6-upstream/libv...
> cd libvirt
> git checkout acef5efd6153aa8f9ea760f468333e65c9b46a4e
> fedpkg-copr -vvv --dist el6 srpm
>
> Which will fails on:
>
> rpm --define '_sourcedir /tmp/libvirt' --define '_specdir /tmp/libvirt' --define '_builddir /tmp/libvirt' --define
> '_srcrpmdir /tmp/libvirt' --define '_rpmdir /tmp/libvirt' --define 'dist .el6' --define 'rhel 6' --eval '%undefine
> fedora' --define 'el6 1' --eval '%undefine fc23' -q --qf "%{NAME} %{EPOCH} %{VERSION} %{RELEASE}??" --specfile
> /tmp/libvirt/libvirt.spec
>
> error: line 1800: Trigger fired by the same package is already defined in spec file: %post daemon-config-network
> error: query of specfile /tmp/libvirt/libvirt.spec failed, can't parse
>
> And your spec file is so complex that I have no idea why it is failing. You may ask on RPM mailing list.
>
Thanks for your reply, I'm addressing this problem to the libvirt list.
8 years, 8 months
