[libvirt] [PATCH] Change string form of VIR_ARCH_ITANIUM back to ia64
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
Historically there was an inconsistency in handling of the
itanium arch. The xen driver & CPU model code treated it
as 'ia64' but the QEMU capabilities code used 'itanium'. On
the grounds that no one has ever seriously used itanium
with QEMU, while RHEL shipped itanium with Xen, we should
favour 'ia64' as the canonical format
Pushed as a test breaker fix from virArch fallout
---
src/qemu/qemu_capabilities.c | 4 ----
src/util/virarch.c | 4 +---
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index ae75bc6..50d999a 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -251,8 +251,6 @@ VIR_ONCE_GLOBAL_INIT(qemuCaps)
static virArch qemuCapsArchFromString(const char *arch)
{
- if (STREQ(arch, "ia64"))
- return VIR_ARCH_ITANIUM;
if (STREQ(arch, "i386"))
return VIR_ARCH_I686;
if (STREQ(arch, "arm"))
@@ -266,8 +264,6 @@ static const char *qemuCapsArchToString(virArch arch)
{
if (arch == VIR_ARCH_I686)
return "i386";
- else if (arch == VIR_ARCH_ITANIUM)
- return "ia64";
else if (arch == VIR_ARCH_ARMV7L)
return "arm";
diff --git a/src/util/virarch.c b/src/util/virarch.c
index 5458b74..1376887 100644
--- a/src/util/virarch.c
+++ b/src/util/virarch.c
@@ -39,7 +39,7 @@ static const struct virArchData {
{ "cris", 32, VIR_ARCH_LITTLE_ENDIAN },
{ "i686", 32, VIR_ARCH_LITTLE_ENDIAN },
- { "itanium", 64, VIR_ARCH_LITTLE_ENDIAN },
+ { "ia64", 64, VIR_ARCH_LITTLE_ENDIAN },
{ "lm32", 32, VIR_ARCH_BIG_ENDIAN },
{ "m68k", 32, VIR_ARCH_BIG_ENDIAN },
{ "microblaze", 32, VIR_ARCH_BIG_ENDIAN },
@@ -159,8 +159,6 @@ virArch virArchFromHost(void)
ut.machine[3] == '6' &&
ut.machine[4] == '\0') {
arch = VIR_ARCH_I686;
- } else if (STREQ(ut.machine, "ia64")) {
- arch = VIR_ARCH_ITANIUM;
} else if (STREQ(ut.machine, "amd64")) {
arch = VIR_ARCH_X86_64;
} else {
--
1.7.11.7
12 years
[libvirt] [PATCH] Fix CPU baseline to not hardcode arch
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
Prior to the virArch changes, the CPU baseline method would
free the arch string in the returned CPU. Fix the regression
by setting arch to VIR_ARCH_NONE at the end
Pushed as a test breaker fix from virArch fallout
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
src/cpu/cpu_x86.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 2001b99..cb21910 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -1715,6 +1715,8 @@ x86Baseline(virCPUDefPtr *cpus,
if (!outputVendor)
VIR_FREE(cpu->vendor);
+ cpu->arch = VIR_ARCH_NONE;
+
cleanup:
x86ModelFree(base_model);
x86MapFree(map);
--
1.7.11.7
12 years
[libvirt] [PATCH] Fix SELinux security label test
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
If securityselinuxtest was run on a system with newer SELinux
policy it would fail, due to using svirt_tcg_t instead of
svirt_t. Fixing the domain type to be KVM avoids this issue.
Pushed as a build fix
---
tests/securityselinuxtest.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/securityselinuxtest.c b/tests/securityselinuxtest.c
index 8bcf3a1..0fa70ba 100644
--- a/tests/securityselinuxtest.c
+++ b/tests/securityselinuxtest.c
@@ -77,6 +77,7 @@ testBuildDomainDef(bool dynamic,
if (VIR_ALLOC(secdef) < 0)
goto no_memory;
+ def->virtType = VIR_DOMAIN_VIRT_KVM;
def->seclabels[0] = secdef;
def->seclabels[0]->type = dynamic ? VIR_DOMAIN_SECLABEL_DYNAMIC : VIR_DOMAIN_SECLABEL_STATIC;
--
1.7.11.7
12 years
[libvirt] [PATCH 0/8 v7] Unprivileged SG_IO support
by Osier Yang
As a result of RFC [1], this implements the unprivleged SG_IO
support.
v6 - v7:
* No restoring of unpriv_sgio per Daniel's thought.
* Use "major:minor" as the hash key per Jirka's suggestion.
Osier Yang (8):
util: Prepare helpers for unpriv_sgio setting
qemu: Add a hash table for the shared disks
docs: Add docs and rng schema for new XML cdbfilter
conf: Parse and format the new XML tag cdbfilter
qemu: set unpriv_sgio when domain starting
qemu: Check if the shared disk's cdbfilter conflicts with others
qemu: Set unpriv_sgio when attaching disk
qemu: Error out if the shared disk conf conflicts with others when
attaching
docs/formatdomain.html.in | 13 ++-
docs/schemas/domaincommon.rng | 52 ++++--
src/conf/domain_conf.c | 58 +++++--
src/conf/domain_conf.h | 10 +
src/libvirt_private.syms | 4 +
src/qemu/qemu_conf.c | 92 ++++++++++
src/qemu/qemu_conf.h | 12 ++
src/qemu/qemu_driver.c | 38 ++++
src/qemu/qemu_process.c | 75 ++++++++
src/qemu/qemu_process.h | 2 +
src/util/util.c | 180 ++++++++++++++++++++
src/util/util.h | 8 +
...ml2argv-disk-scsi-lun-passthrough-cdbfilter.xml | 32 ++++
tests/qemuxml2xmltest.c | 1 +
14 files changed, 547 insertions(+), 30 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-lun-passthrough-cdbfilter.xml
[1] https://www.redhat.com/archives/libvir-list/2012-November/msg00988.html
[2] https://www.redhat.com/archives/libvir-list/2012-December/msg00325.html
Regards,
Osier
12 years
[libvirt] VirtualBox 4.2 Drivers Complete?
by Arslan Waqar
I was using a VM on Vbox (Ubuntu 12.04) and from the virsh I tried:
virsh # dommemstat 2
and I got the following errors:
error: Failed to get memory statistics for domain 2
error: this function is not supported by the connection driver:
virDomainMemoryStats
Are the Drivers for Vbox 4.2 incomplete?
--
Regards,
Arslan Waqar.
12 years
[libvirt] [PATCH 0/6] Use enum for tracking valid architectures
by Daniel P. Berrange
Different operating systems have different names for architectures.
eg x86_64 x64, amd64. This can cause inconsistency in libvirt code
dealing with architectures. To deal with this define an enum for
valid architectures and a canonical string mapping. Update all
code internally to use the enum instead of 'char *' for arch
data.
12 years
[libvirt] [PATCH] spec: Do not install *.py[co] in python examples
by Jiri Denemark
Unfortunately, rpm is stupid enough to bytycompile python scripts even
though they are located in /usr/share/doc/libvirt-python-*/examples and
it does so after %install phase is finished. Thus there's no way we
could remove those files from BUILDROOT. As a workaround, we may safely
remove the examples subdirectory completely without losing anything. The
python scripts that were installed there are also copied directly into
/usr/share/doc/libvirt-python-*/ by
%doc python/tests/*.py
rule. And yes, the files are actually tests, not examples.
---
libvirt.spec.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 7457a48..13cc8a2 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1392,6 +1392,8 @@ rm -f $RPM_BUILD_ROOT%{_datadir}/augeas/lenses/tests/test_libvirtd_lxc.aug
%if ! %{with_python}
rm -rf $RPM_BUILD_ROOT%{_datadir}/doc/libvirt-python-%{version}
+%else
+rm -rf $RPM_BUILD_ROOT%{_datadir}/doc/libvirt-python-%{version}/examples
%endif
%if ! %{with_qemu}
--
1.8.0.2
12 years
[libvirt] [PATCH 00/28] Rename files in src/util to have a 'vir' prefix
by Daniel P. Berrange
Currently the files in src/util are 50/50 split between those
having a 'vir' prefix and those which don't. Finish the job
by remaining all remaining files to have a 'vir' prefix too,
guaranteeing that they can't clash with system headers[1].
The only case which was not a plain rename, was merging
processinfo.{c,h} into the virprocess.{c,h} since the
functionality logically belongs together.
At the end src/Makefile.am is updated to sort util files
alphabetically.
Left as further work - make sure all functions in these
files also have a 'vir' prefix. eg dnsmasq, ebtables,
iptables, usb and pci files are violators in this regard.
Also left, much of virutil.c should move into virfile.c
Daniel
[1] Not a theoretical problem - we already hit a clsah
on 'usb.h' before forcing us to use 'hostusb.h'
and 'memory.h' clashes with a system header but we
never noticed so far.
12 years
[libvirt] Important question
by Gene Czarcinski
OK, so maybe I an nuts but it seems to me that there is this 800 pound
gorilla wondering around the Fedora 18 tent and its name is firewalld!
Or it with respect to virtual guests and libvirt (since libvirt is a
critical part of networking support).
Maybe I am missing some critical information as to how to configure
firewalld so that guests can perform functions which the same guest can
do on a Fedora 17 host. She only firewalld configuration I have been
able to come up with is to configure it disabled.
https://bugzilla.redhat.com/show_bug.cgi?id=888288
I have test this problem on different hardware and with/without mu usual
updates of libvirt-1.0.1 and NetworkManager-git20121130. Please tell me
that there is just this little thing I need to do and everything will work.
With Fedora 18 to be released "real soon now", this is a very big
problem! I remember with SELinux first appeared ... most people
disabled it. Is this what is going to happen with firewalld?
A big part of my problem is that I see little notice that there is a
problem.
I do not like cross posting but this needs to be on a couple of lists so
I will be sending each a copy of this message.
Gene
12 years
