Re: [virt-tools-list] [PATCH virt-viewer] session-spice: Remove spice-gtk version checks
On Thu, Apr 2, 2015 at 9:18 AM, Fabiano Fidêncio fabi...@fidencio.org wrote:
On Thu, Apr 2, 2015 at 8:09 AM, Pavel Grunt pgr...@redhat.com wrote:
Since 77ac0d8892837a117f9ca10020c1ac7f1944fca7 virt-viewer requires
spice-gtk v0.28
---
src/virt-viewer-session-spice.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/src/virt-viewer-session-spice.c
b/src/virt-viewer-session-spice.c
index a0acba6..921e613 100644
--- a/src/virt-viewer-session-spice.c
+++ b/src/virt-viewer-session-spice.c
@@ -44,10 +44,6 @@
#include gbinding.c
#endif
-#ifndef SPICE_GTK_CHECK_VERSION
-#define SPICE_GTK_CHECK_VERSION(x, y, z) 0
-#endif
-
G_DEFINE_TYPE (VirtViewerSessionSpice, virt_viewer_session_spice,
VIRT_VIEWER_TYPE_SESSION)
@@ -546,14 +542,12 @@
virt_viewer_session_spice_main_channel_event(SpiceChannel *channel
G_GNUC_UNUSED
const GError *error = NULL;
g_debug(main channel: auth failure (wrong username/password?));
-#if SPICE_GTK_CHECK_VERSION(0, 26, 0)
{
error = spice_channel_get_error(channel);
username_required = g_error_matches(error,
SPICE_CLIENT_ERROR,
SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD_AND_USERNAME);
}
-#endif
if (self-priv-pass_try 0)
g_signal_emit_by_name(session, session-auth-failed,
@@ -594,7 +588,6 @@
virt_viewer_session_spice_main_channel_event(SpiceChannel *channel
G_GNUC_UNUSED
break;
}
case SPICE_CHANNEL_ERROR_CONNECT:
-#if SPICE_GTK_CHECK_VERSION(0, 23, 21)
{
const GError *error = spice_channel_get_error(channel);
@@ -619,10 +612,6 @@
virt_viewer_session_spice_main_channel_event(SpiceChannel *channel
G_GNUC_UNUSED
g_signal_emit_by_name(session, session-disconnected, error ?
error-message : NULL);
}
}
-#else
-g_debug(main channel: failed to connect);
-g_signal_emit_by_name(session, session-disconnected, NULL);
-#endif
break;
case SPICE_CHANNEL_ERROR_IO:
case SPICE_CHANNEL_ERROR_LINK:
--
2.3.4
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
ACK!
--
Fabiano Fidêncio
Pushed!
--
Fabiano Fidêncio
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [PATCH virt-viewer] session-spice: Remove spice-gtk version checks
Since 77ac0d8892837a117f9ca10020c1ac7f1944fca7 virt-viewer requires
spice-gtk v0.28
---
src/virt-viewer-session-spice.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/src/virt-viewer-session-spice.c b/src/virt-viewer-session-spice.c
index a0acba6..921e613 100644
--- a/src/virt-viewer-session-spice.c
+++ b/src/virt-viewer-session-spice.c
@@ -44,10 +44,6 @@
#include gbinding.c
#endif
-#ifndef SPICE_GTK_CHECK_VERSION
-#define SPICE_GTK_CHECK_VERSION(x, y, z) 0
-#endif
-
G_DEFINE_TYPE (VirtViewerSessionSpice, virt_viewer_session_spice,
VIRT_VIEWER_TYPE_SESSION)
@@ -546,14 +542,12 @@ virt_viewer_session_spice_main_channel_event(SpiceChannel
*channel G_GNUC_UNUSED
const GError *error = NULL;
g_debug(main channel: auth failure (wrong username/password?));
-#if SPICE_GTK_CHECK_VERSION(0, 26, 0)
{
error = spice_channel_get_error(channel);
username_required = g_error_matches(error,
SPICE_CLIENT_ERROR,
SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD_AND_USERNAME);
}
-#endif
if (self-priv-pass_try 0)
g_signal_emit_by_name(session, session-auth-failed,
@@ -594,7 +588,6 @@ virt_viewer_session_spice_main_channel_event(SpiceChannel
*channel G_GNUC_UNUSED
break;
}
case SPICE_CHANNEL_ERROR_CONNECT:
-#if SPICE_GTK_CHECK_VERSION(0, 23, 21)
{
const GError *error = spice_channel_get_error(channel);
@@ -619,10 +612,6 @@ virt_viewer_session_spice_main_channel_event(SpiceChannel
*channel G_GNUC_UNUSED
g_signal_emit_by_name(session, session-disconnected, error ?
error-message : NULL);
}
}
-#else
-g_debug(main channel: failed to connect);
-g_signal_emit_by_name(session, session-disconnected, NULL);
-#endif
break;
case SPICE_CHANNEL_ERROR_IO:
case SPICE_CHANNEL_ERROR_LINK:
--
2.3.4
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH virt-viewer v3] virt-viewer-window: Change zoom of the display only when it is possible
On Wed, Apr 1, 2015 at 8:25 AM, Pavel Grunt pgr...@redhat.com wrote:
On Tue, Mar 31, 2015 at 3:03 PM, Pavel Grunt pgr...@redhat.com
wrote:
Do not allow to zoom out if it is not possible due to the width of
the top menu. It avoids emitting size allocation events that will
change the display resolution of the spice guest.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1206460
---
v3:
- return when zoom level doesn't change
- more comments
v2:
- treatment of zoom level moved to _window_set_zoom_level() in
order to make it work in all cases (ie. with the command line
option '-z')
- _get_minimal_zoom_level() instead of _can_zoom_out()
- more debug logs
---
src/virt-viewer-window.c | 72
+++-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/src/virt-viewer-window.c b/src/virt-viewer-window.c
index 799adce..75966c3 100644
--- a/src/virt-viewer-window.c
+++ b/src/virt-viewer-window.c
@@ -34,9 +34,11 @@
#include locale.h
#include glib/gprintf.h
#include glib/gi18n.h
+#include math.h
#include virt-gtk-compat.h
#include virt-viewer-window.h
+#include virt-viewer-display.h
#include virt-viewer-session.h
#include virt-viewer-app.h
#include virt-viewer-util.h
@@ -67,6 +69,8 @@ static void
virt_viewer_window_disable_modifiers(VirtViewerWindow *self);
static void virt_viewer_window_resize(VirtViewerWindow *self,
gboolean keep_win_size);
static void virt_viewer_window_toolbar_setup(VirtViewerWindow
*self);
static GtkMenu*
virt_viewer_window_get_keycombo_menu(VirtViewerWindow *self);
+static void
virt_viewer_window_get_minimal_dimensions(VirtViewerWindow *self,
guint *width, guint *height);
+static gint
virt_viewer_window_get_minimal_zoom_level(VirtViewerWindow *self);
G_DEFINE_TYPE (VirtViewerWindow, virt_viewer_window,
G_TYPE_OBJECT)
@@ -1306,7 +1310,7 @@
virt_viewer_window_set_display(VirtViewerWindow *self,
VirtViewerDisplay *displa
if (display != NULL) {
priv-display = g_object_ref(display);
-
virt_viewer_display_set_zoom_level(VIRT_VIEWER_DISPLAY(priv-display),
priv-zoomlevel);
+virt_viewer_window_set_zoom_level(self, priv-zoomlevel);
virt_viewer_display_set_monitor(VIRT_VIEWER_DISPLAY(priv-display),
priv-fullscreen_monitor);
virt_viewer_display_set_fullscreen(VIRT_VIEWER_DISPLAY(priv-display),
priv-fullscreen);
@@ -1402,9 +1406,11 @@ void
virt_viewer_window_set_zoom_level(VirtViewerWindow *self, gint
zoom_level)
{
VirtViewerWindowPrivate *priv;
+gint min_zoom, old_zoom;
g_return_if_fail(VIRT_VIEWER_IS_WINDOW(self));
priv = self-priv;
+old_zoom = priv-zoomlevel;
if (zoom_level MIN_ZOOM_LEVEL)
zoom_level = MIN_ZOOM_LEVEL;
@@ -1415,6 +1421,17 @@
virt_viewer_window_set_zoom_level(VirtViewerWindow *self, gint
zoom_level)
if (!priv-display)
return;
+min_zoom = virt_viewer_window_get_minimal_zoom_level(self);
+if (min_zoom priv-zoomlevel) {
+g_debug(Cannot set zoom level %d, using %d,
priv-zoomlevel, min_zoom);
+priv-zoomlevel = min_zoom;
+}
+
+if (priv-zoomlevel == old_zoom) {
+g_debug(Zoom level not changed, using: %d,
priv-zoomlevel);
+return;
+}
+
virt_viewer_display_set_zoom_level(VIRT_VIEWER_DISPLAY(priv-display),
priv-zoomlevel);
virt_viewer_window_queue_resize(self);
@@ -1467,6 +1484,59 @@
virt_viewer_window_set_kiosk(VirtViewerWindow *self, gboolean
enabled)
g_debug(disabling kiosk not implemented yet);
}
+static void
+virt_viewer_window_get_minimal_dimensions(VirtViewerWindow *self,
+ guint *width,
+ guint *height)
+{
+GtkRequisition req;
+GtkWidget *top_menu;
+
+top_menu =
GTK_WIDGET(gtk_builder_get_object(virt_viewer_window_get_builder(self),
top-menu));
+#if !GTK_CHECK_VERSION(3, 0, 0)
+gtk_widget_get_child_requisition(top_menu, req);
+#else
+gtk_widget_get_preferred_size(top_menu, req, NULL);
+#endif
+/* minimal dimensions of the window are the maximum of
dimensions of the top-menu
+ * and minimal dimension of the display
+ */
+*height = MAX(MIN_DISPLAY_HEIGHT, req.height);
height can be MIN_DISPLAY_HEIGHT, no?
+*width = MAX(MIN_DISPLAY_WIDTH, req.width);
+}
+
+/**
+ * virt_viewer_window_get_minimal_zoom_level:
+ * @self: a #VirtViewerWindow
+ *
+ * Calculates the zoom level with respect to the desktop
dimensions
+ *
+ * Returns: minimal possible zoom level (multiple of ZOOM_STEP)
+ */
+static gint
+virt_viewer_window_get_minimal_zoom_level(VirtViewerWindow *self)
+{
+guint min_width, min_height;
+
Re: [virt-tools-list] [virt-manager PATCH] clone: keep the same image format on a cross-pool clone
Cole Robinson crobi...@redhat.com writes: On 04/01/2015 09:13 AM, Giuseppe Scrivano wrote: Cole Robinson crobi...@redhat.com writes: ACK, but I'm surprised the test suite doesn't need tweaking. maybe we should extend a clone test to use the fake qemu URI so we can validate format copying in the output disk XML as follow-up, I've added a test for the cloned disks. OK to push it? Thanks, Giuseppe From 66c1ace004d4f2dccf48cd00ab32c7aeee503691 Mon Sep 17 00:00:00 2001 From: Giuseppe Scrivano gscri...@redhat.com Date: Wed, 1 Apr 2015 15:07:51 +0200 Subject: [PATCH] tests: check that clone keeps the same image format for disks Signed-off-by: Giuseppe Scrivano gscri...@redhat.com --- tests/clone-xml/cross-pool-disks-out.xml | 22 ++ tests/clone-xml/cross-pool-out.xml | 2 +- tests/clonetest.py | 21 - 3 files changed, 39 insertions(+), 6 deletions(-) create mode 100644 tests/clone-xml/cross-pool-disks-out.xml diff --git a/tests/clone-xml/cross-pool-disks-out.xml b/tests/clone-xml/cross-pool-disks-out.xml new file mode 100644 index 000..8eb3acb --- /dev/null +++ b/tests/clone-xml/cross-pool-disks-out.xml @@ -0,0 +1,22 @@ +volume + namenew1.img/name + capacity1073/capacity + allocation1073/allocation + target +format type=qcow2/ +features + lazy_refcounts/ +/features + /target +/volume +volume + namenew2.img/name + capacity100/capacity + allocation5/allocation + target +format type=qcow2/ +features + lazy_refcounts/ +/features + /target +/volume diff --git a/tests/clone-xml/cross-pool-out.xml b/tests/clone-xml/cross-pool-out.xml index 4200dce..5541adf 100644 --- a/tests/clone-xml/cross-pool-out.xml +++ b/tests/clone-xml/cross-pool-out.xml @@ -22,7 +22,7 @@ target dev=hda bus=ide/ /disk disk type=file device=disk - source file=/dev/cross-pool/new2.img/ + source file=/dev/default-pool/new2.img/ target dev=hdb bus=ide/ /disk interface type=network diff --git a/tests/clonetest.py b/tests/clonetest.py index 0119201..5789d41 100644 --- a/tests/clonetest.py +++ b/tests/clonetest.py @@ -1,4 +1,4 @@ -# Copyright (C) 2013 Red Hat, Inc. +# Copyright (C) 2013, 2015 Red Hat, Inc. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -55,7 +55,8 @@ class TestClone(unittest.TestCase): os.unlink(f) def _clone_helper(self, filebase, disks=None, force_list=None, - skip_list=None, compare=True, useconn=None): + skip_list=None, compare=True, useconn=None, + clone_disks_file=None): Helper for comparing clone input/output from 2 xml files infile = os.path.join(clonexml_dir, filebase + -in.xml) in_content = utils.read_file(infile) @@ -70,7 +71,8 @@ class TestClone(unittest.TestCase): cloneobj = self._default_clone_values(cloneobj, disks) if compare: -self._clone_compare(cloneobj, filebase) +self._clone_compare(cloneobj, filebase, +clone_disks_file=clone_disks_file) self._clone_define(filebase) else: cloneobj.setup() @@ -90,13 +92,18 @@ class TestClone(unittest.TestCase): cloneobj.clone_paths = disks return cloneobj -def _clone_compare(self, cloneobj, outbase): +def _clone_compare(self, cloneobj, outbase, clone_disks_file=None): Helps compare output from passed clone instance with an xml file outfile = os.path.join(clonexml_dir, outbase + -out.xml) cloneobj.setup() utils.diff_compare(cloneobj.clone_xml, outfile) +if clone_disks_file: +xml_clone_disks = +for i in cloneobj.get_clone_disks(): +xml_clone_disks += i.get_vol_install().get_xml_config() +utils.diff_compare(xml_clone_disks, clone_disks_file) def _clone_define(self, filebase): Take the valid output xml and attempt to define it on the @@ -138,8 +145,12 @@ class TestClone(unittest.TestCase): def testCloneStorageCrossPool(self): base = cross-pool +useconn = utils.open_test_remote() +clone_disks_file = os.path.join(clonexml_dir, base + -disks-out.xml) self._clone_helper(base, [%s/new1.img % POOL2, - %s/new2.img % POOL2]) + %s/new2.img % POOL1], + clone_disks_file=clone_disks_file, + useconn=useconn) def testCloneStorageForce(self): base = force ACK pushed. Thanks, Giuseppe ___ virt-tools-list
Re: [virt-tools-list] [PATCH virt-viewer] session-spice: Remove spice-gtk version checks
On Thu, Apr 2, 2015 at 8:09 AM, Pavel Grunt pgr...@redhat.com wrote:
Since 77ac0d8892837a117f9ca10020c1ac7f1944fca7 virt-viewer requires
spice-gtk v0.28
---
src/virt-viewer-session-spice.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/src/virt-viewer-session-spice.c b/src/virt-viewer-session-spice.c
index a0acba6..921e613 100644
--- a/src/virt-viewer-session-spice.c
+++ b/src/virt-viewer-session-spice.c
@@ -44,10 +44,6 @@
#include gbinding.c
#endif
-#ifndef SPICE_GTK_CHECK_VERSION
-#define SPICE_GTK_CHECK_VERSION(x, y, z) 0
-#endif
-
G_DEFINE_TYPE (VirtViewerSessionSpice, virt_viewer_session_spice,
VIRT_VIEWER_TYPE_SESSION)
@@ -546,14 +542,12 @@
virt_viewer_session_spice_main_channel_event(SpiceChannel *channel
G_GNUC_UNUSED
const GError *error = NULL;
g_debug(main channel: auth failure (wrong username/password?));
-#if SPICE_GTK_CHECK_VERSION(0, 26, 0)
{
error = spice_channel_get_error(channel);
username_required = g_error_matches(error,
SPICE_CLIENT_ERROR,
SPICE_CLIENT_ERROR_AUTH_NEEDS_PASSWORD_AND_USERNAME);
}
-#endif
if (self-priv-pass_try 0)
g_signal_emit_by_name(session, session-auth-failed,
@@ -594,7 +588,6 @@ virt_viewer_session_spice_main_channel_event(SpiceChannel
*channel G_GNUC_UNUSED
break;
}
case SPICE_CHANNEL_ERROR_CONNECT:
-#if SPICE_GTK_CHECK_VERSION(0, 23, 21)
{
const GError *error = spice_channel_get_error(channel);
@@ -619,10 +612,6 @@
virt_viewer_session_spice_main_channel_event(SpiceChannel *channel
G_GNUC_UNUSED
g_signal_emit_by_name(session, session-disconnected, error ?
error-message : NULL);
}
}
-#else
-g_debug(main channel: failed to connect);
-g_signal_emit_by_name(session, session-disconnected, NULL);
-#endif
break;
case SPICE_CHANNEL_ERROR_IO:
case SPICE_CHANNEL_ERROR_LINK:
--
2.3.4
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
ACK!
--
Fabiano Fidêncio
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [PATCH] virt-manager: Don't allow an empty string for a network name
When starting the 'Create virtual network' wizard, you are allowed to proceed without specifying a Network Name. An error only occurs after all else is completed with the wizard. This patch stops the user from proceeding if a network name has not been specified. The check for an empty string is done in util.py which also effects storage pool names and guest names neither of which should have empty strings. Signed-off-by: Charles Arnold carn...@suse.com diff --git a/virtManager/create.py b/virtManager/create.py index b67af61..64d6eac 100644 --- a/virtManager/create.py +++ b/virtManager/create.py @@ -1743,7 +1743,10 @@ class vmmCreate(vmmGObjectUI): # HV + Arch selection name = self.get_config_name() if name != self.guest.name: -self.guest.name = name +try: +self.guest.name = name +except Exception, e: +return self.err.val_err(_(Invalid guest name), str(e)) if self.is_default_storage(): logging.debug(User changed VM name and using default storage, re-validating with new default storage path.) diff --git a/virtManager/createpool.py b/virtManager/createpool.py index 6641ce9..5d4558e 100644 --- a/virtManager/createpool.py +++ b/virtManager/createpool.py @@ -479,8 +479,6 @@ class vmmCreatePool(vmmGObjectUI): def _validate_page_name(self, usepool=None): name = self.get_config_name() -if not name: -return self.err.val_err(_(A name must be specified.)) try: if usepool: diff --git a/virtinst/util.py b/virtinst/util.py index baf671c..099b501 100644 --- a/virtinst/util.py +++ b/virtinst/util.py @@ -143,6 +143,9 @@ def validate_name(name_type, val): # Rather than try and match libvirt's regex, just forbid things we # know don't work forbid = [ ] +if not val: +raise ValueError( +_(A name must be specified for the %s) % name_type) for c in forbid: if c not in val: continue ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [PATCH virt-manager 1/5] virtinst: add new vmport domain feature
This should be available with libvirt 1.2.15
---
virtinst/domainfeatures.py | 3 +++
virtinst/support.py| 2 ++
2 files changed, 5 insertions(+)
diff --git a/virtinst/domainfeatures.py b/virtinst/domainfeatures.py
index bec538b..16d8ee2 100644
--- a/virtinst/domainfeatures.py
+++ b/virtinst/domainfeatures.py
@@ -45,3 +45,6 @@ class DomainFeatures(XMLBuilder):
hyperv_spinlocks = XMLProperty(./hyperv/spinlocks/@state, is_onoff=True)
hyperv_spinlocks_retries = XMLProperty(./hyperv/spinlocks/@retries,
is_int=True)
+
+vmport = XMLProperty(./vmport/@state, is_onoff=True,
+ default_name=default, default_cb=lambda s: False)
diff --git a/virtinst/support.py b/virtinst/support.py
index 0b11076..f7beeb1 100644
--- a/virtinst/support.py
+++ b/virtinst/support.py
@@ -303,6 +303,8 @@ SUPPORT_CONN_DOMAIN_CAPABILITIES = _make(
function=virConnect.getDomainCapabilities,
run_args=(None, None, None, None))
SUPPORT_CONN_VIDEO_NEW_RAM_OUTPUT = _make(version=1.2.11)
+SUPPORT_CONN_VMPORT = _make(
+version=1.2.15, hv_version={qemu: 2.2.0})
# Domain checks
--
2.1.0
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [virt-viewer][PATCH] Fix crash when disabling last enabled display
Using virt_viewer_signal_connect_object() instead of g_signal_connect() ensures that menu_display_visible_toggled_cb() won't be executed after the display object be disposed. Backtrace for the crash: #0 0x7070592b in g_type_check_instance_is_a (type_instance=0x8851f0, iface_type=optimized out) at gtype.c:4016 #1 0x0041ee06 in virt_viewer_display_get_session (self=0x8851f0) at ../../src/virt-viewer-display.c:702 #2 0x00417be7 in menu_display_visible_toggled_cb (checkmenuitem=0x93f790 [GtkCheckMenuItem], display=0x8851f0) at ../../src/virt-viewer-app.c:2187 #6 0x706fe29f in emit signal ??? on instance 0x93f790 [GtkCheckMenuItem] (instance=instance@entry=0x93f790, signal_id=optimized out, detail=detail@entry=0) at gsignal.c:3361 #3 0x706e3b9f in g_closure_invoke (closure=0x93faa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffc230, invocation_hint=invocation_hint@entry=0x7fffc1b0) at gclosure.c:768 #4 0x706f54c9 in signal_emit_unlocked_R (node=node@entry=0x6d73e0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffc230) at gsignal.c:3549 #5 0x706fded0 in g_signal_emit_valist (instance=optimized out, signal_id=optimized out, detail=optimized out, var_args=var_args@entry=0x7fffc3f0) at gsignal.c:3305 #7 0x75eb6158 in gtk_check_menu_item_activate (check_menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:299 #8 0x75eb6158 in gtk_check_menu_item_activate (menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:419 #12 0x706fe29f in emit signal ??? on instance 0x93f790 [GtkCheckMenuItem] (instance=optimized out, signal_id=optimized out, detail=optimized out) at gsignal.c:3361 #9 0x706e3b9f in g_closure_invoke (closure=closure@entry=0x6d5aa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffc6b0, invocation_hint=invocation_hint@entry=0x7fffc630) at gclosure.c:768 #10 0x706f51bd in signal_emit_unlocked_R (node=node@entry=0x6d5ba0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffc6b0) at gsignal.c:3479 #11 0x706fded0 in g_signal_emit_valist (instance=optimized out, signal_id=optimized out, detail=optimized out, var_args=var_args@entry=0x7fffc870) at gsignal.c:3305 #13 0x00417c5e in menu_display_visible_toggled_cb (checkmenuitem=0x93f790 [GtkCheckMenuItem], display=0x8851f0) at ../../src/virt-viewer-app.c:2200 #17 0x706fe29f in emit signal ??? on instance 0x93f790 [GtkCheckMenuItem] (instance=instance@entry=0x93f790, signal_id=optimized out, detail=detail@entry=0) at gsignal.c:3361 #14 0x706e3c45 in g_closure_invoke (closure=0x93faa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffcb50, invocation_hint=invocation_hint@entry=0x7fffcad0) at gclosure.c:768 #15 0x706f54c9 in signal_emit_unlocked_R (node=node@entry=0x6d73e0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffcb50) at gsignal.c:3549 #16 0x706fded0 in g_signal_emit_valist (instance=optimized out, signal_id=optimized out, detail=optimized out, var_args=var_args@entry=0x7fffcd10) at gsignal.c:3305 #18 0x75eb6158 in gtk_check_menu_item_activate (check_menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:299 #19 0x75eb6158 in gtk_check_menu_item_activate (menu_item=0x93f790 [GtkCheckMenuItem]) at gtkcheckmenuitem.c:419 #23 0x706fe29f in emit signal ??? on instance 0x93f790 [GtkCheckMenuItem] (instance=instance@entry=0x93f790, signal_id=optimized out, detail=detail@entry=0) at gsignal.c:3361 #20 0x706e3c45 in g_closure_invoke (closure=closure@entry=0x6d5aa0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7fffcfd0, invocation_hint=invocation_hint@entry=0x7fffcf50) at gclosure.c:768 #21 0x706f51bd in signal_emit_unlocked_R (node=node@entry=0x6d5ba0, detail=detail@entry=0, instance=instance@entry=0x93f790, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffcfd0) at gsignal.c:3479 #22 0x706fded0 in g_signal_emit_valist (instance=optimized out, signal_id=optimized out, detail=optimized out, var_args=var_args@entry=0x7fffd190) at gsignal.c:3305 #24 0x7608648e in IA__gtk_widget_activate (widget=widget@entry=0x93f790 [GtkCheckMenuItem]) at gtkwidget.c:5048 #25 0x75f6cacd in IA__gtk_menu_shell_activate_item (menu_shell=0x70ece0 [GtkMenu], menu_item=0x93f790
Re: [virt-tools-list] Nested VM images fail/freeze during booting
Hi Cole, Both the physical host, L1 VM, and L2 VM are CentOS 7.0 (3.10.0-123.20.1.el7.x86_64). Thanks, Steve Amerige Principal Software Developer, Fraud and Compliance Solutions Development SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617 On 4/2/2015 12:00 PM, Cole Robinson wrote: What distro is your physical host, L1 VM, and L2 VM running? - Cole On 04/02/2015 10:33 AM, Steve Amerige wrote: Hi all, *Problem:* Nested VM images fail/freeze during booting. *Details:* *Hardware:* * Model: Dell R620 * CPU: 2 x 6 x 2 (ht) Intel E5-2667 o flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl *vmx *smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid * Memory: 192GB * Disk: 7.0T local filesystem *Physical Hypervisor Configuration:* * /etc/modprobe.d/kvm-nested.conf (see below) * /etc/libvirt/qemu/virtual-hypervisor.xml (see below) o Runs without any problems o Includes: cpu ...feature policy='require' name='vmx'//cpu *Virtual Hypervisor Configuration:* * virt-manager opens without any problems * The virtual guest within the virtual hypervisor VM fails to boot o I see the screen in which the boot choices are shown. After the selection is made (either by waiting for the selection timeout, or by explicit selection), the next screen shows a screen dump (see below) * /etc/libvirt/qemu/virtual-guest.xml (see below) o Uses virbr0 o There is no /var/log/libvirt/qemu logfile as the boot up doesn't get far enough. I tried placing the virtual-guest.xml and image on the physical hypervisor and it does boot up without any problems. I've scoured the web and can't figure out why boot up is failing for the nested VM. Can anyone think of a solution or help out in any way? Thanks, Steve Amerige Principal Software Developer, Fraud and Compliance Solutions Development SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617 *Physical Hypervisor Configuration:* */etc/modprobe.d/kvm-nested.conf:* options kvm_intel nested=1 */etc/libvirt/qemu/virtual-hypervisor.xml:* domain type='kvm' namevirtual-hypervisor/name uuid5bded4c9-e00a-4c33-8d68-f79ef9bf6daa/uuid memory unit='KiB'16777216/memory currentMemory unit='KiB'33554432/currentMemory vcpu placement='static'4/vcpu os type arch='x86_64' machine='pc-i440fx-rhel7.0.0'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features cpu mode='custom' match='exact' model fallback='allow'SandyBridge/model vendorIntel/vendor feature policy='require' name='vmx'/ /cpu clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/libexec/qemu-kvm/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/var/lib/libvirt/images/virtual-hypervisor.qcow2'/ target dev='vda' bus='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='pci' index='0' model='pci-root'/ controller type='ide' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller interface type='bridge' mac address='52:54:00:7a:40:a6'/ source bridge='br0'/ model type='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' target port='0'/ /serial console type='pty' target type='serial' port='0'/ /console input type='tablet' bus='usb'/ input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes'/ sound model='ich6' address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /sound video model type='cirrus' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' address type='pci' domain='0x' bus='0x00' slot='0x06' function='0x0'/ /memballoon /devices /domain *Virtual Guest Configuration:*
Re: [virt-tools-list] Nested VM images fail/freeze during booting
What distro is your physical host, L1 VM, and L2 VM running? - Cole On 04/02/2015 10:33 AM, Steve Amerige wrote: Hi all, *Problem:* Nested VM images fail/freeze during booting. *Details:* *Hardware:* * Model: Dell R620 * CPU: 2 x 6 x 2 (ht) Intel E5-2667 o flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl *vmx *smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid * Memory: 192GB * Disk: 7.0T local filesystem *Physical Hypervisor Configuration:* * /etc/modprobe.d/kvm-nested.conf (see below) * /etc/libvirt/qemu/virtual-hypervisor.xml (see below) o Runs without any problems o Includes: cpu ...feature policy='require' name='vmx'//cpu *Virtual Hypervisor Configuration:* * virt-manager opens without any problems * The virtual guest within the virtual hypervisor VM fails to boot o I see the screen in which the boot choices are shown. After the selection is made (either by waiting for the selection timeout, or by explicit selection), the next screen shows a screen dump (see below) * /etc/libvirt/qemu/virtual-guest.xml (see below) o Uses virbr0 o There is no /var/log/libvirt/qemu logfile as the boot up doesn't get far enough. I tried placing the virtual-guest.xml and image on the physical hypervisor and it does boot up without any problems. I've scoured the web and can't figure out why boot up is failing for the nested VM. Can anyone think of a solution or help out in any way? Thanks, Steve Amerige Principal Software Developer, Fraud and Compliance Solutions Development SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617 *Physical Hypervisor Configuration:* */etc/modprobe.d/kvm-nested.conf:* options kvm_intel nested=1 */etc/libvirt/qemu/virtual-hypervisor.xml:* domain type='kvm' namevirtual-hypervisor/name uuid5bded4c9-e00a-4c33-8d68-f79ef9bf6daa/uuid memory unit='KiB'16777216/memory currentMemory unit='KiB'33554432/currentMemory vcpu placement='static'4/vcpu os type arch='x86_64' machine='pc-i440fx-rhel7.0.0'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features cpu mode='custom' match='exact' model fallback='allow'SandyBridge/model vendorIntel/vendor feature policy='require' name='vmx'/ /cpu clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/libexec/qemu-kvm/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/var/lib/libvirt/images/virtual-hypervisor.qcow2'/ target dev='vda' bus='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='pci' index='0' model='pci-root'/ controller type='ide' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller interface type='bridge' mac address='52:54:00:7a:40:a6'/ source bridge='br0'/ model type='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' target port='0'/ /serial console type='pty' target type='serial' port='0'/ /console input type='tablet' bus='usb'/ input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes'/ sound model='ich6' address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /sound video model type='cirrus' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' address type='pci' domain='0x' bus='0x00' slot='0x06' function='0x0'/ /memballoon /devices /domain *Virtual Guest Configuration:* domain type='kvm' namevirtual-guest.xml/name uuid863ffbe3-1d4e-4ca6-b86f-bb13e32fed6b/uuid memory unit='KiB'2097152/memory currentMemory unit='KiB'2097152/currentMemory vcpu placement='static'1/vcpu os type arch='x86_64'
[virt-tools-list] Nested VM images fail/freeze during booting
Hi all, *Problem:* Nested VM images fail/freeze during booting. *Details:* *Hardware:* * Model: Dell R620 * CPU: 2 x 6 x 2 (ht) Intel E5-2667 o flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl *vmx *smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid * Memory: 192GB * Disk: 7.0T local filesystem *Physical Hypervisor Configuration:* * /etc/modprobe.d/kvm-nested.conf (see below) * /etc/libvirt/qemu/virtual-hypervisor.xml (see below) o Runs without any problems o Includes: cpu ...feature policy='require' name='vmx'//cpu *Virtual Hypervisor Configuration:* * virt-manager opens without any problems * The virtual guest within the virtual hypervisor VM fails to boot o I see the screen in which the boot choices are shown. After the selection is made (either by waiting for the selection timeout, or by explicit selection), the next screen shows a screen dump (see below) * /etc/libvirt/qemu/virtual-guest.xml (see below) o Uses virbr0 o There is no /var/log/libvirt/qemu logfile as the boot up doesn't get far enough. I tried placing the virtual-guest.xml and image on the physical hypervisor and it does boot up without any problems. I've scoured the web and can't figure out why boot up is failing for the nested VM. Can anyone think of a solution or help out in any way? Thanks, Steve Amerige Principal Software Developer, Fraud and Compliance Solutions Development SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617 *Physical Hypervisor Configuration:* */etc/modprobe.d/kvm-nested.conf:* options kvm_intel nested=1 */etc/libvirt/qemu/virtual-hypervisor.xml:* domain type='kvm' namevirtual-hypervisor/name uuid5bded4c9-e00a-4c33-8d68-f79ef9bf6daa/uuid memory unit='KiB'16777216/memory currentMemory unit='KiB'33554432/currentMemory vcpu placement='static'4/vcpu os type arch='x86_64' machine='pc-i440fx-rhel7.0.0'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features cpu mode='custom' match='exact' model fallback='allow'SandyBridge/model vendorIntel/vendor feature policy='require' name='vmx'/ /cpu clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/libexec/qemu-kvm/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/var/lib/libvirt/images/virtual-hypervisor.qcow2'/ target dev='vda' bus='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='pci' index='0' model='pci-root'/ controller type='ide' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller interface type='bridge' mac address='52:54:00:7a:40:a6'/ source bridge='br0'/ model type='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' target port='0'/ /serial console type='pty' target type='serial' port='0'/ /console input type='tablet' bus='usb'/ input type='mouse' bus='ps2'/ graphics type='vnc' port='-1' autoport='yes'/ sound model='ich6' address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /sound video model type='cirrus' vram='9216' heads='1'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' address type='pci' domain='0x' bus='0x00' slot='0x06' function='0x0'/ /memballoon /devices /domain *Virtual Guest Configuration:* domain type='kvm' namevirtual-guest.xml/name uuid863ffbe3-1d4e-4ca6-b86f-bb13e32fed6b/uuid memory unit='KiB'2097152/memory currentMemory unit='KiB'2097152/currentMemory vcpu placement='static'1/vcpu os type arch='x86_64' machine='pc-i440fx-rhel7.0.0'hvm/type boot dev='hd'/ /os features acpi/ apic/ pae/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/libexec/qemu-kvm/emulator disk
Re: [virt-tools-list] Failure to update CPU usage display
On 04/02/2015 02:04 PM, Charles Arnold wrote: On 4/1/2015 at 05:14 PM, Cole Robinson crobi...@redhat.com wrote: On 04/01/2015 05:42 PM, Charles Arnold wrote: Under certain conditions I see the guest CPU usage display not being updated. The problem seems most prevalent when Xen is the underlying hypervisor but I have seen it occasionally with KVM. What appears to be happening is that when a VM is created, the engine's _handle_tick_queue() calls the connection tick() method which in turn calls _tick(). In here it calls _update_vms() which gets a new vmmDomain object. Then it spawns a new thread to call tick_send_signals() where if 'pollvm' is True then 'self._vms' will get the newly create vmmDomain object. The problem (I think) is that under certain conditions the thread spun up by self.idle_add(tick_send_signals) doesn't run quickly enough (and therefore doesn't set self._vms) until after _tick() returns and is called again and second vmmDomain object is created. At this point it appears that the first vmmDomain object collects the cpu stats from libvirt while the second vmmDomain object updates the display which doesn't have the stats and therefore nothing appears. That analysis sounds reasonable. Since tick() is running in a thread, if the mainloop is handling lots of UI stuff or similar it seems possible that tick() could be invoked twice before the mainloop handles tick_send_signals. Unfortunately our threading model is pretty hacky here since we have threads touch a bunch of shared state without any locking, but it's simple and generally works out fine. Below are a couple approaches to solving the problem (assuming my analysis is correct). This first one simply yields to give the tick_send_signals thread a chance to run. diff --git a/virtManager/connection.py b/virtManager/connection.py index a907a3f..af27141 100644 --- a/virtManager/connection.py +++ b/virtManager/connection.py @@ -1240,6 +1240,9 @@ class vmmConnection(vmmGObject): self._change_state(self._STATE_ACTIVE) self.idle_add(tick_send_signals) +if len(self._vms) len(vms): +# Allow time for tick_send_signals to run +time.sleep(.1) ticklist = [] def add_to_ticklist(l, args=()): Obviously a timeout is sketchy since it might just make it less likely to trigger. This second solution doesn't wait for the thread and sets self._vms if pollvm is True. diff --git a/virtManager/connection.py b/virtManager/connection.py index a907a3f..96c208e 100644 --- a/virtManager/connection.py +++ b/virtManager/connection.py @@ -1240,6 +1240,8 @@ class vmmConnection(vmmGObject): self._change_state(self._STATE_ACTIVE) self.idle_add(tick_send_signals) +if pollvm: +self._vms = vms ticklist = [] def add_to_ticklist(l, args=()): Any thoughts on this problem and the potential solutions? We can't update any of the conn lists in the thread since it's possible the self._vms is in use by the mainloop, which can cause weird errors if it's updated while another part of the code is iterating over it or similar. I think the proper thing to do short of some larger refactoring is to use a threading.Lock(). conn.tick() will grab the lock at the start, tick_send_signals will release the Lock when it's updated the conn state. So tick() can't run until the previous tick_send_signals has finished. If you can reproduce easily, does this patch fix it (and not cause issues?). I only did light testing. Not pushed yet Thanks for the patch. I have a machine that reproduces the problem easily. I've tested your patch for both KVM and Xen and it fixes the problem without any adverse side effects that I was able to see. I started about a dozen installs on each (same machine booted either KVM or Xen) with a mix of ISO and network installation sources for KVM, Xen PV, and Xen HVM. I would say the patch is good. Thanks for testing, pushed now: commit ce74cd772647ca8a062c696f296b8afb2bd8efdf Author: Cole Robinson crobi...@redhat.com Date: Wed Apr 1 19:10:16 2015 -0400 connection: Protect conn state tick() updates with a lock - Cole ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] Failure to update CPU usage display
On 4/1/2015 at 05:14 PM, Cole Robinson crobi...@redhat.com wrote: On 04/01/2015 05:42 PM, Charles Arnold wrote: Under certain conditions I see the guest CPU usage display not being updated. The problem seems most prevalent when Xen is the underlying hypervisor but I have seen it occasionally with KVM. What appears to be happening is that when a VM is created, the engine's _handle_tick_queue() calls the connection tick() method which in turn calls _tick(). In here it calls _update_vms() which gets a new vmmDomain object. Then it spawns a new thread to call tick_send_signals() where if 'pollvm' is True then 'self._vms' will get the newly create vmmDomain object. The problem (I think) is that under certain conditions the thread spun up by self.idle_add(tick_send_signals) doesn't run quickly enough (and therefore doesn't set self._vms) until after _tick() returns and is called again and second vmmDomain object is created. At this point it appears that the first vmmDomain object collects the cpu stats from libvirt while the second vmmDomain object updates the display which doesn't have the stats and therefore nothing appears. That analysis sounds reasonable. Since tick() is running in a thread, if the mainloop is handling lots of UI stuff or similar it seems possible that tick() could be invoked twice before the mainloop handles tick_send_signals. Unfortunately our threading model is pretty hacky here since we have threads touch a bunch of shared state without any locking, but it's simple and generally works out fine. Below are a couple approaches to solving the problem (assuming my analysis is correct). This first one simply yields to give the tick_send_signals thread a chance to run. diff --git a/virtManager/connection.py b/virtManager/connection.py index a907a3f..af27141 100644 --- a/virtManager/connection.py +++ b/virtManager/connection.py @@ -1240,6 +1240,9 @@ class vmmConnection(vmmGObject): self._change_state(self._STATE_ACTIVE) self.idle_add(tick_send_signals) +if len(self._vms) len(vms): +# Allow time for tick_send_signals to run +time.sleep(.1) ticklist = [] def add_to_ticklist(l, args=()): Obviously a timeout is sketchy since it might just make it less likely to trigger. This second solution doesn't wait for the thread and sets self._vms if pollvm is True. diff --git a/virtManager/connection.py b/virtManager/connection.py index a907a3f..96c208e 100644 --- a/virtManager/connection.py +++ b/virtManager/connection.py @@ -1240,6 +1240,8 @@ class vmmConnection(vmmGObject): self._change_state(self._STATE_ACTIVE) self.idle_add(tick_send_signals) +if pollvm: +self._vms = vms ticklist = [] def add_to_ticklist(l, args=()): Any thoughts on this problem and the potential solutions? We can't update any of the conn lists in the thread since it's possible the self._vms is in use by the mainloop, which can cause weird errors if it's updated while another part of the code is iterating over it or similar. I think the proper thing to do short of some larger refactoring is to use a threading.Lock(). conn.tick() will grab the lock at the start, tick_send_signals will release the Lock when it's updated the conn state. So tick() can't run until the previous tick_send_signals has finished. If you can reproduce easily, does this patch fix it (and not cause issues?). I only did light testing. Not pushed yet Thanks for the patch. I have a machine that reproduces the problem easily. I've tested your patch for both KVM and Xen and it fixes the problem without any adverse side effects that I was able to see. I started about a dozen installs on each (same machine booted either KVM or Xen) with a mix of ISO and network installation sources for KVM, Xen PV, and Xen HVM. I would say the patch is good. - Charles ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [PATCH virt-manager 2/5] virtinst: add features.vmport option
--- virtinst/cli.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/virtinst/cli.py b/virtinst/cli.py index 93aae3d..44504b0 100644 --- a/virtinst/cli.py +++ b/virtinst/cli.py @@ -1406,6 +1406,8 @@ class ParserFeatures(VirtCLIParser): self.set_param(features.hyperv_spinlocks_retries, hyperv_spinlocks_retries) +self.set_param(features.vmport, vmport, is_onoff=True) + ### # --clock parsing # -- 2.1.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [PATCH virt-manager 0/5] Disable vmport with Spice
Hi, This is a small series introducing the vmport feature configuration with virt-install (the patches are yet to be reviewed for libvirt). By default, vmport will be disable when the VM is using Spice, since it prevents a Spice client from switching between absolute and relative pointer. Marc-André Lureau (5): virtinst: add new vmport domain feature virtinst: add features.vmport option virtinst: set_graphics_defaults() first virtinst: set vmport off by default when has_spice() tests: add some vmport tests tests/cli-test-xml/compare/virt-install-singleton-config-2.xml | 2 ++ tests/clitest.py | 2 +- tests/xmlparse-xml/change-guest-in.xml | 1 + tests/xmlparse-xml/change-guest-out.xml| 1 + tests/xmlparse.py | 1 + virtinst/cli.py| 2 ++ virtinst/domainfeatures.py | 3 +++ virtinst/guest.py | 10 +- virtinst/support.py| 2 ++ 9 files changed, 22 insertions(+), 2 deletions(-) -- 2.1.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [PATCH virt-manager 3/5] virtinst: set_graphics_defaults() first
Some later options may require Spice (or other) to be enabled, so call set_graphics_defaults() earlier. --- virtinst/guest.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/virtinst/guest.py b/virtinst/guest.py index 678f675..6f42775 100644 --- a/virtinst/guest.py +++ b/virtinst/guest.py @@ -682,6 +682,9 @@ class Guest(XMLBuilder): dev.path = None def _set_defaults(self): +# some options check for has_spice() which is resolved after this: +self._set_graphics_defaults() + self._set_osxml_defaults() self._set_clock_defaults() self._set_emulator_defaults() @@ -695,7 +698,6 @@ class Guest(XMLBuilder): self._add_implied_controllers() self._set_net_defaults() self._set_input_defaults() -self._set_graphics_defaults() self._set_video_defaults() self._set_sound_defaults() -- 2.1.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
[virt-tools-list] [PATCH virt-manager 4/5] virtinst: set vmport off by default when has_spice()
Spice is better off without vmport enabled, to be able to switch between absolute and relative mouse mode easily. --- virtinst/guest.py | 6 ++ 1 file changed, 6 insertions(+) diff --git a/virtinst/guest.py b/virtinst/guest.py index 6f42775..9eb53b5 100644 --- a/virtinst/guest.py +++ b/virtinst/guest.py @@ -849,6 +849,12 @@ class Guest(XMLBuilder): if self.features.hyperv_spinlocks_retries is None: self.features.hyperv_spinlocks_retries = 8191 +if (self.features.vmport == default and +self.has_spice() and +self.conn.check_support(self.conn.SUPPORT_CONN_VMPORT)): +self.features.vmport = False + + def _add_implied_controllers(self): has_spapr_scsi = False has_virtio_scsi = False -- 2.1.0 ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
