[libvirt] [PATCHv2] qemu: Do fake auto-allocation of ports when generating native command
by Peter Krempa
When attempting to generate the native command line from an XML file
that uses graphics port auto allocation, the generated commandline
wouldn't be valid.
This patch adds fake autoallocation of ports as done when starting the
actual machine.
---
Notes:
Version 2:
- rebased after context-conflict with 11fc1beab6e018a88182f80056d35217c150b3de
src/qemu/qemu_driver.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 9492850..45fcf05 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -5274,6 +5274,58 @@ static char *qemuConnectDomainXMLToNative(virConnectPtr conn,
if (qemuDomainAssignAddresses(def, qemuCaps, NULL) < 0)
goto cleanup;
+ /* do fake auto-alloc of graphics ports, if such config is used */
+ for (i = 0 ; i < def->ngraphics; ++i) {
+ virDomainGraphicsDefPtr graphics = def->graphics[i];
+ if (graphics->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC &&
+ !graphics->data.vnc.socket && graphics->data.vnc.autoport) {
+ graphics->data.vnc.port = 5900;
+ } else if (graphics->type == VIR_DOMAIN_GRAPHICS_TYPE_SPICE) {
+ int j;
+ bool needTLSPort = false;
+ bool needPort = false;
+ int defaultMode = graphics->data.spice.defaultMode;
+
+ if (graphics->data.spice.autoport) {
+ /* check if tlsPort or port need allocation */
+ for (j = 0 ; j < VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_LAST ; j++) {
+ switch (graphics->data.spice.channels[j]) {
+ case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_SECURE:
+ needTLSPort = true;
+ break;
+
+ case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_INSECURE:
+ needPort = true;
+ break;
+
+ case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_ANY:
+ switch (defaultMode) {
+ case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_SECURE:
+ needTLSPort = true;
+ break;
+
+ case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_INSECURE:
+ needPort = true;
+ break;
+
+ case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_ANY:
+ needTLSPort = true;
+ needPort = true;
+ break;
+ }
+ break;
+ }
+ }
+ }
+
+ if (needPort || graphics->data.spice.port == -1)
+ graphics->data.spice.port = 5901;
+
+ if (needTLSPort || graphics->data.spice.tlsPort == -1)
+ graphics->data.spice.tlsPort = 5902;
+ }
+ }
+
if (!(cmd = qemuBuildCommandLine(conn, driver, def,
&monConfig, monitor_json, qemuCaps,
NULL, -1, NULL, VIR_NETDEV_VPORT_PROFILE_OP_NO_OP)))
--
1.8.2.1
12 years
[libvirt] Static Route for IPv6
by Gene Czarcinski
In the process of adding the code to support static routes for IPv4 and
IPv6, I hit a problem when I tried to specify a static route for ::/0
(that is "default") ... the error was "file exists." and the problem is
that this is a feature and not a bug. Here is the comment from the
bugzilla report which explains things:
-------------------------------------------------------------------------------------------------------------
yeah, this isn't a bug as far as I can see. The magic that your looking for is
in fib6_add_rt2node(). When adding a new route, we search for duplicate
routes, and should we find one, we compare them to ensure that when the ipv6
stack does a route lookup, they have some way to select which route should be
used. To do that they use the metric/preference number (I admit that use of
the term metric in the iproute2 tool is a bit misleading, but if you check the
ip-route(8) man page, you'll see its a synonym for preference). At any rate,
since you already have a default gateway (which the stack sees as a duplicate
for the one your adding), and the existing route has the same metric/preference
as the one you are adding, you get the EXIST error.
Ways to work around this:
1) Use the src option in the ip route add command to differentiate and prevent
the existing default gw from being used (might be useful if you want different
virt guests to use different default gw).
2) instead of using ip route add, use ip route replace, which will overwrite
the existing default gw.
3) Use a different metric value than the existing default gw. Both routes will
be added, but only the higest priority route will be used.
-----------------------------------------------------------------------------------------
As I understand the situation now, the error I got for ::/0 was valid
and should not be ignored or overriden by default. However, there is
bound to be someone who has a valid reason to do this so there needs to
be a way to do it.
Proposal:
Add a new attribute metric to the <route> subelement. The default for
metric will be metric='1' so that it will be the same as it is now.
However, the use will be able to specify an arbitrary unsigned 32 bit
number.
There are two other suggestions up there. Any comments?
When I started this, my goal was simply to get some static routes for
"regular" networks so that the virtualization host would know where to
route packets. I am not sure that it is a good idea that folks fiddle
with default routes in libvirt virtual-network definitions but I am sure
that someone, sometime will have a valid reason to do so.
BTW, just because some static route variation is not implemented as part
of the libvirt definition does not mean that a user cannot issue the
ip-route-add command manually.
Gene
12 years
[libvirt] [PATCH 0/2] spec file fixups
by Eric Blake
Here's a couple of spec file cleanups that should go in prior to
1.0.5, particularly since the FPC recently changed packaging
guidelines because of an issue highlighted in libvirt's spec file.
Eric Blake (2):
spec: collect all BuildRequires into one area
spec: proper soft static allocation of qemu uid
libvirt.spec.in | 29 +++++++++++++++++++----------
1 file changed, 19 insertions(+), 10 deletions(-)
--
1.8.1.4
12 years
[libvirt] [PATCH] build: always include libvirt_lxc.syms in tarball
by Eric Blake
On a mingw build, 'make distcheck' fails with:
GEN libvirt_qemu.def
make[3]: *** No rule to make target `../../src/libvirt_lxc.syms', needed by `libvirt_lxc.def'. Stop.
I traced it to a missing entry in EXTRA_DIST. But rather than keep
the entire list in sync, it is easier to list the three syms files
that drive .so files directly, and then reuse existing makefile
variables for the remaining files (that is, I validated that all
remaining files are added to SYM_FILES, possibly via USED_SYM_FILES,
according to makefile conditionals).
* src/Makefile.am (EXTRA_DIST): Ensure all syms files are shipped.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
src/Makefile.am | 19 +++++--------------
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 299b8fd..6c2788c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1548,20 +1548,11 @@ SYM_FILES += $(srcdir)/libvirt_atomic.syms
endif
EXTRA_DIST += \
- libvirt_public.syms \
- libvirt_private.syms \
- libvirt_atomic.syms \
- libvirt_driver_modules.syms \
- libvirt_daemon.syms \
- libvirt_linux.syms \
- libvirt_esx.syms \
- libvirt_openvz.syms \
- libvirt_qemu.syms \
- libvirt_sasl.syms \
- libvirt_gnutls.syms \
- libvirt_vmx.syms \
- libvirt_xenxs.syms \
- libvirt_libssh2.syms
+ libvirt_public.syms \
+ libvirt_lxc.syms \
+ libvirt_qemu.syms \
+ $(SYM_FILES) \
+ $(NULL)
GENERATED_SYM_FILES = \
libvirt.syms libvirt.def libvirt_qemu.def libvirt_lxc.def
--
1.8.1.4
12 years
[libvirt] [PATCH qom-cpu-next 0/3] X86CPU: "feature-words"/"filtered-features" properties (v12)
by Eduardo Habkost
Resubmitting after a rebase and a few trivial changes.
Changes v11 -> v12:
* Remove unnecessary entries from .gitignore
* Fix indentation of x86_cpu_get_feature_words() declaration
* Rebase on top of qom-cpu-next
(commit bd87d2a - target-i386: Use FeatureWord loop on filter_features_for_kvm())
Git tree for reference:
git://github.com/ehabkost/qemu-hacks.git work/cpu-raw-features.v12
Eduardo Habkost (3):
target-i386: Add "feature-words" property
target-i386: Introduce X86CPU.filtered_features field
target-i386: Add "filtered-features" property to X86CPU
Makefile.objs | 7 ++++-
qapi-schema.json | 32 ++++++++++++++++++++
target-i386/cpu-qom.h | 3 ++
target-i386/cpu.c | 82 +++++++++++++++++++++++++++++++++++++++++----------
4 files changed, 108 insertions(+), 16 deletions(-)
--
1.8.1.4
12 years
[libvirt] [PATCH qom-cpu 0/9] x86: feature words array (v11) + "feature-words" property
by Eduardo Habkost
This series includes the previous "replace cpuid_*features fields with a feature
word array" series.
The first 4 patches already have a Reviewed-by from Igor, they correspond to v10
plus a small indent fix requested by him.
As the cpuid_*features series was holding my "feature-words"/"filtered-features"
series (previously sent as RFC), I am now sending both as a single series, to
try to get "feature-words"/"filtered-features" some attention and try to get it
included in 1.5.
The "feature-words"/"filtered-features" mechanism is very important for libvirt,
to allow it to ensure the guest is getting the required set of CPU features, as
configured by the user.
Eduardo Habkost (9):
target-i386: cleanup: Group together level, xlevel, xlevel2 fields
target-i386/kvm.c: Code formatting changes
target-i386/cpu.c: Break lines so they don't get too long
target-i386: Replace cpuid_*features fields with a feature word array
target-i386: Add ECX information to FeatureWordInfo
target-i386: Add "feature-words" property
target-i386: Use FeatureWord loop on filter_features_for_kvm()
target-i386: Introduce X86CPU.filtered_features field
target-i386: Add "filtered-features" property to X86CPU
.gitignore | 2 +
Makefile.objs | 7 +-
bsd-user/elfload.c | 2 +-
bsd-user/main.c | 4 +-
hw/i386/kvm/clock.c | 2 +-
linux-user/elfload.c | 2 +-
linux-user/main.c | 4 +-
qapi-schema.json | 31 +++
target-i386/cpu-qom.h | 3 +
target-i386/cpu.c | 501 +++++++++++++++++++++++++++++-----------------
target-i386/cpu.h | 15 +-
target-i386/helper.c | 4 +-
target-i386/kvm.c | 5 +-
target-i386/misc_helper.c | 14 +-
target-i386/translate.c | 10 +-
15 files changed, 385 insertions(+), 221 deletions(-)
--
1.8.1.4
12 years
[libvirt] IPv6 iscsi targets
by Ján Tomko
Hello.
Before running iscsiadm, libvirt translates the source host to an IP address
for the --portal option. However, it only resolves to IPv4 and only uses the
first address.
iscsiadm allows a hostname to be specified [1][2], but specifying a hostname
instead of the address doesn't work if the hostname translates to an
unreachable IPv6 address first.
Would it be reasonable to go through all the addresses returned by
getaddrinfo() in libvirt, try to connect() to it and pass the address to
iscsiadm when the connection succeeds?
Or we should just pass the hostname and make iscsiadm deal with it?
Jan
[1] https://github.com/mikechristie/open-iscsi/commit/4d045cd
[2] https://bugzilla.redhat.com/show_bug.cgi?id=624437
12 years
[libvirt] [PATCH v1 0/8] Chardev hotplug
by Michal Privoznik
The first round. For some reasons, I am still unable to hotplug any king of
chardev. For instance:
<console type='pty'>
<source path='/dev/pts/4'/>
<target port='0'/>
</console>
Doesn't work. On the other hand, any domain with such device coldpluged refuse
to start anyway :)
Michal Privoznik (8):
domain_conf: Introduce chardev hotplug helpers
qemu: Implement chardev hotplug on config level
qemu_monitor_json: Move InetSocketAddress build to a separate function
qemu_monitor: Introduce qemuMonitorAttachCharDev
qemu_monitor: Introduce qemuMonitorDetachCharDev
qemu_command: Honour chardev alias assignment with a function
qemu: Introduce qemuBuildChrDeviceStr
qemu: Implement chardev hotplug on live level
src/conf/domain_conf.c | 174 +++++++++++++++++++++++++++-
src/conf/domain_conf.h | 11 ++
src/libvirt_private.syms | 4 +
src/qemu/qemu_command.c | 262 +++++++++++++++++++++++++++++++++++--------
src/qemu/qemu_command.h | 14 ++-
src/qemu/qemu_driver.c | 43 ++++++-
src/qemu/qemu_hotplug.c | 97 ++++++++++++++++
src/qemu/qemu_hotplug.h | 6 +
src/qemu/qemu_monitor.c | 41 +++++++
src/qemu/qemu_monitor.h | 5 +
src/qemu/qemu_monitor_json.c | 261 +++++++++++++++++++++++++++++++++++++++---
src/qemu/qemu_monitor_json.h | 5 +
12 files changed, 850 insertions(+), 73 deletions(-)
--
1.8.1.5
12 years
