[libvirt] [PATCH v2] libxl: Support PV consoles
Currently the driver only exposes the ability to connect to the serial console of a Xen guest, which doesn't work for a PV guest. Since for an HVM guest the serial devices are duplicated as consoles it is sufficient to just use the console devices unconditionally. Tested with the following bit of config XML: <domain type='xen'> ... <devices> <console type='pty'> <target type='xen'/> </console> </devices> </domain> I have observed and tested this on ARM but I believe it also applies to x86 PV guests. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jim Fehlig <jfehlig@suse.com> Cc: Dario Faggioli <dario.faggioli@citrix.com> Cc: Clark Laughlin <clark.laughlin@linaro.org> --- v2: Just use nconsoles unconditionally, they contain serial too --- src/libxl/libxl_driver.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index a6ae8a1..535e7da 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -3780,6 +3780,7 @@ libxlDomainOpenConsole(virDomainPtr dom, { virDomainObjPtr vm = NULL; int ret = -1; + libxl_console_type console_type = LIBXL_CONSOLE_TYPE_UNKNOWN; virDomainChrDefPtr chr = NULL; libxlDomainObjPrivatePtr priv; char *console = NULL; @@ -3807,8 +3808,8 @@ libxlDomainOpenConsole(virDomainPtr dom, priv = vm->privateData; - if (vm->def->nserials) - chr = vm->def->serials[0]; + if (vm->def->nconsoles) + chr = vm->def->consoles[0]; if (!chr) { virReportError(VIR_ERR_INTERNAL_ERROR, @@ -3824,7 +3825,12 @@ libxlDomainOpenConsole(virDomainPtr dom, goto cleanup; } - ret = libxl_primary_console_get_tty(priv->ctx, vm->def->id, &console); + console_type = + (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ? + LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV); + + ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port, + console_type, &console); if (ret) goto cleanup; -- 1.7.10.4
On Fri, Apr 25, 2014 at 04:54:20PM +0100, Ian Campbell wrote:
Currently the driver only exposes the ability to connect to the serial console of a Xen guest, which doesn't work for a PV guest. Since for an HVM guest the serial devices are duplicated as consoles it is sufficient to just use the console devices unconditionally.
Tested with the following bit of config XML:
<domain type='xen'> ... <devices> <console type='pty'> <target type='xen'/> </console> </devices> </domain>
I have observed and tested this on ARM but I believe it also applies to x86 PV guests.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jim Fehlig <jfehlig@suse.com> Cc: Dario Faggioli <dario.faggioli@citrix.com> Cc: Clark Laughlin <clark.laughlin@linaro.org> --- v2: Just use nconsoles unconditionally, they contain serial too --- src/libxl/libxl_driver.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index a6ae8a1..535e7da 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -3780,6 +3780,7 @@ libxlDomainOpenConsole(virDomainPtr dom, { virDomainObjPtr vm = NULL; int ret = -1; + libxl_console_type console_type = LIBXL_CONSOLE_TYPE_UNKNOWN; virDomainChrDefPtr chr = NULL; libxlDomainObjPrivatePtr priv; char *console = NULL; @@ -3807,8 +3808,8 @@ libxlDomainOpenConsole(virDomainPtr dom,
priv = vm->privateData;
- if (vm->def->nserials) - chr = vm->def->serials[0]; + if (vm->def->nconsoles) + chr = vm->def->consoles[0];
if (!chr) { virReportError(VIR_ERR_INTERNAL_ERROR, @@ -3824,7 +3825,12 @@ libxlDomainOpenConsole(virDomainPtr dom, goto cleanup; }
- ret = libxl_primary_console_get_tty(priv->ctx, vm->def->id, &console); + console_type = + (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ? + LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV); + + ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port, + console_type, &console); if (ret) goto cleanup;
ACK to this Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Ian Campbell wrote:
Currently the driver only exposes the ability to connect to the serial console of a Xen guest, which doesn't work for a PV guest. Since for an HVM guest the serial devices are duplicated as consoles it is sufficient to just use the console devices unconditionally.
Tested with the following bit of config XML:
<domain type='xen'> ... <devices> <console type='pty'> <target type='xen'/> </console> </devices> </domain>
I have observed and tested this on ARM but I believe it also applies to x86 PV guests.
Yep, I think you are right. ACK to the patch. I'll push it, after a bit of testing. Regards, Jim
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jim Fehlig <jfehlig@suse.com> Cc: Dario Faggioli <dario.faggioli@citrix.com> Cc: Clark Laughlin <clark.laughlin@linaro.org> --- v2: Just use nconsoles unconditionally, they contain serial too --- src/libxl/libxl_driver.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index a6ae8a1..535e7da 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -3780,6 +3780,7 @@ libxlDomainOpenConsole(virDomainPtr dom, { virDomainObjPtr vm = NULL; int ret = -1; + libxl_console_type console_type = LIBXL_CONSOLE_TYPE_UNKNOWN; virDomainChrDefPtr chr = NULL; libxlDomainObjPrivatePtr priv; char *console = NULL; @@ -3807,8 +3808,8 @@ libxlDomainOpenConsole(virDomainPtr dom,
priv = vm->privateData;
- if (vm->def->nserials) - chr = vm->def->serials[0]; + if (vm->def->nconsoles) + chr = vm->def->consoles[0];
if (!chr) { virReportError(VIR_ERR_INTERNAL_ERROR, @@ -3824,7 +3825,12 @@ libxlDomainOpenConsole(virDomainPtr dom, goto cleanup; }
- ret = libxl_primary_console_get_tty(priv->ctx, vm->def->id, &console); + console_type = + (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ? + LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV); + + ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port, + console_type, &console); if (ret) goto cleanup;
Jim Fehlig wrote:
Ian Campbell wrote:
Currently the driver only exposes the ability to connect to the serial console of a Xen guest, which doesn't work for a PV guest. Since for an HVM guest the serial devices are duplicated as consoles it is sufficient to just use the console devices unconditionally.
Tested with the following bit of config XML:
<domain type='xen'> ... <devices> <console type='pty'> <target type='xen'/> </console> </devices> </domain>
I have observed and tested this on ARM but I believe it also applies to x86 PV guests.
Yep, I think you are right.
ACK to the patch. I'll push it, after a bit of testing.
Regards, Jim
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jim Fehlig <jfehlig@suse.com> Cc: Dario Faggioli <dario.faggioli@citrix.com> Cc: Clark Laughlin <clark.laughlin@linaro.org> --- v2: Just use nconsoles unconditionally, they contain serial too --- src/libxl/libxl_driver.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index a6ae8a1..535e7da 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -3780,6 +3780,7 @@ libxlDomainOpenConsole(virDomainPtr dom, { virDomainObjPtr vm = NULL; int ret = -1; + libxl_console_type console_type = LIBXL_CONSOLE_TYPE_UNKNOWN;
This doesn't compile with Xen 4.2.x libxl/libxl_driver.c: In function 'libxlDomainOpenConsole': libxl/libxl_driver.c:3783:39: error: 'LIBXL_CONSOLE_TYPE_UNKNOWN' undeclared (first use in this function) libxl/libxl_driver.c:3783:39: note: each undeclared identifier is reported only once for each function it appears in xen.git commit 166bb0fe introduced UNKNOWN in the enum. I suppose it is best to initialize console_type with 0, along with a comment? Regards, Jim
virDomainChrDefPtr chr = NULL; libxlDomainObjPrivatePtr priv; char *console = NULL; @@ -3807,8 +3808,8 @@ libxlDomainOpenConsole(virDomainPtr dom,
priv = vm->privateData;
- if (vm->def->nserials) - chr = vm->def->serials[0]; + if (vm->def->nconsoles) + chr = vm->def->consoles[0];
if (!chr) { virReportError(VIR_ERR_INTERNAL_ERROR, @@ -3824,7 +3825,12 @@ libxlDomainOpenConsole(virDomainPtr dom, goto cleanup; }
- ret = libxl_primary_console_get_tty(priv->ctx, vm->def->id, &console); + console_type = + (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ? + LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV); + + ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port, + console_type, &console); if (ret) goto cleanup;
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Apr 25, 2014 at 11:24:07AM -0600, Jim Fehlig wrote:
Jim Fehlig wrote:
Ian Campbell wrote:
Currently the driver only exposes the ability to connect to the serial console of a Xen guest, which doesn't work for a PV guest. Since for an HVM guest the serial devices are duplicated as consoles it is sufficient to just use the console devices unconditionally.
Tested with the following bit of config XML:
<domain type='xen'> ... <devices> <console type='pty'> <target type='xen'/> </console> </devices> </domain>
I have observed and tested this on ARM but I believe it also applies to x86 PV guests.
Yep, I think you are right.
ACK to the patch. I'll push it, after a bit of testing.
Regards, Jim
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jim Fehlig <jfehlig@suse.com> Cc: Dario Faggioli <dario.faggioli@citrix.com> Cc: Clark Laughlin <clark.laughlin@linaro.org> --- v2: Just use nconsoles unconditionally, they contain serial too --- src/libxl/libxl_driver.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index a6ae8a1..535e7da 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -3780,6 +3780,7 @@ libxlDomainOpenConsole(virDomainPtr dom, { virDomainObjPtr vm = NULL; int ret = -1; + libxl_console_type console_type = LIBXL_CONSOLE_TYPE_UNKNOWN;
This doesn't compile with Xen 4.2.x
Hey Jim! The development version of Xen is 4.5. The latest stable is Xen 4.4. If you want to backport it - then your suggestion is correct. Or just backport the relevant patches ?
libxl/libxl_driver.c: In function 'libxlDomainOpenConsole': libxl/libxl_driver.c:3783:39: error: 'LIBXL_CONSOLE_TYPE_UNKNOWN' undeclared (first use in this function) libxl/libxl_driver.c:3783:39: note: each undeclared identifier is reported only once for each function it appears in
xen.git commit 166bb0fe introduced UNKNOWN in the enum. I suppose it is best to initialize console_type with 0, along with a comment?
Regards, Jim
virDomainChrDefPtr chr = NULL; libxlDomainObjPrivatePtr priv; char *console = NULL; @@ -3807,8 +3808,8 @@ libxlDomainOpenConsole(virDomainPtr dom,
priv = vm->privateData;
- if (vm->def->nserials) - chr = vm->def->serials[0]; + if (vm->def->nconsoles) + chr = vm->def->consoles[0];
if (!chr) { virReportError(VIR_ERR_INTERNAL_ERROR, @@ -3824,7 +3825,12 @@ libxlDomainOpenConsole(virDomainPtr dom, goto cleanup; }
- ret = libxl_primary_console_get_tty(priv->ctx, vm->def->id, &console); + console_type = + (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL ? + LIBXL_CONSOLE_TYPE_SERIAL : LIBXL_CONSOLE_TYPE_PV); + + ret = libxl_console_get_tty(priv->ctx, vm->def->id, chr->target.port, + console_type, &console); if (ret) goto cleanup;
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Fri, 2014-04-25 at 13:32 -0400, Konrad Rzeszutek Wilk wrote:
The development version of Xen is 4.5. The latest stable is Xen 4.4.
If you want to backport it - then your suggestion is correct. Or just backport the relevant patches ?
This patch is against libvirt, which wishes to support Xen versions back to Xen 4.2, this is not a patch against Xen. Or maybe I've missed your point? Ian.
On Fri, Apr 25, 2014 at 07:52:55PM +0100, Ian Campbell wrote:
On Fri, 2014-04-25 at 13:32 -0400, Konrad Rzeszutek Wilk wrote:
The development version of Xen is 4.5. The latest stable is Xen 4.4.
If you want to backport it - then your suggestion is correct. Or just backport the relevant patches ?
This patch is against libvirt, which wishes to support Xen versions back to Xen 4.2, this is not a patch against Xen.
Ah, that makes more sense.
Or maybe I've missed your point?
No, I just assumed it would be only applicable to Xen - didn't think that API promises this. <blushes>
Ian.
On Fri, 2014-04-25 at 11:24 -0600, Jim Fehlig wrote:
Jim Fehlig wrote:
Ian Campbell wrote:
Currently the driver only exposes the ability to connect to the serial console of a Xen guest, which doesn't work for a PV guest. Since for an HVM guest the serial devices are duplicated as consoles it is sufficient to just use the console devices unconditionally.
Tested with the following bit of config XML:
<domain type='xen'> ... <devices> <console type='pty'> <target type='xen'/> </console> </devices> </domain>
I have observed and tested this on ARM but I believe it also applies to x86 PV guests.
Yep, I think you are right.
ACK to the patch. I'll push it, after a bit of testing.
Regards, Jim
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jim Fehlig <jfehlig@suse.com> Cc: Dario Faggioli <dario.faggioli@citrix.com> Cc: Clark Laughlin <clark.laughlin@linaro.org> --- v2: Just use nconsoles unconditionally, they contain serial too --- src/libxl/libxl_driver.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index a6ae8a1..535e7da 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -3780,6 +3780,7 @@ libxlDomainOpenConsole(virDomainPtr dom, { virDomainObjPtr vm = NULL; int ret = -1; + libxl_console_type console_type = LIBXL_CONSOLE_TYPE_UNKNOWN;
This doesn't compile with Xen 4.2.x
libxl/libxl_driver.c: In function 'libxlDomainOpenConsole': libxl/libxl_driver.c:3783:39: error: 'LIBXL_CONSOLE_TYPE_UNKNOWN' undeclared (first use in this function) libxl/libxl_driver.c:3783:39: note: each undeclared identifier is reported only once for each function it appears in
xen.git commit 166bb0fe introduced UNKNOWN in the enum. I suppose it is best to initialize console_type with 0, along with a comment?
Yes, I think that would be appropriate. Or possibly not initialising the variable at all will work, in any code path which uses it it is initialised (it is set iff chr is set I think). Ian.
Ian Campbell wrote:
On Fri, 2014-04-25 at 11:24 -0600, Jim Fehlig wrote:
Jim Fehlig wrote:
Ian Campbell wrote:
Currently the driver only exposes the ability to connect to the serial console of a Xen guest, which doesn't work for a PV guest. Since for an HVM guest the serial devices are duplicated as consoles it is sufficient to just use the console devices unconditionally.
Tested with the following bit of config XML:
<domain type='xen'> ... <devices> <console type='pty'> <target type='xen'/> </console> </devices> </domain>
I have observed and tested this on ARM but I believe it also applies to x86 PV guests.
Yep, I think you are right.
ACK to the patch. I'll push it, after a bit of testing.
Regards, Jim
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jim Fehlig <jfehlig@suse.com> Cc: Dario Faggioli <dario.faggioli@citrix.com> Cc: Clark Laughlin <clark.laughlin@linaro.org> --- v2: Just use nconsoles unconditionally, they contain serial too --- src/libxl/libxl_driver.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index a6ae8a1..535e7da 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -3780,6 +3780,7 @@ libxlDomainOpenConsole(virDomainPtr dom, { virDomainObjPtr vm = NULL; int ret = -1; + libxl_console_type console_type = LIBXL_CONSOLE_TYPE_UNKNOWN;
This doesn't compile with Xen 4.2.x
libxl/libxl_driver.c: In function 'libxlDomainOpenConsole': libxl/libxl_driver.c:3783:39: error: 'LIBXL_CONSOLE_TYPE_UNKNOWN' undeclared (first use in this function) libxl/libxl_driver.c:3783:39: note: each undeclared identifier is reported only once for each function it appears in
xen.git commit 166bb0fe introduced UNKNOWN in the enum. I suppose it is best to initialize console_type with 0, along with a comment?
Yes, I think that would be appropriate. Or possibly not initialising the variable at all will work, in any code path which uses it it is initialised (it is set iff chr is set I think).
Doh, right. I dropped initializing the variable and pushed the patch. Thanks! Regards, Jim
On Fri, 2014-04-25 at 14:12 -0600, Jim Fehlig wrote:
I dropped initializing the variable and pushed the patch. Thanks!
Thanks! I rebased to current master (no additional patches on my end) tried to test and suddenly libvirtd is segfaulting in libxl when I run virsh create. The fault is at "nexus->ev = 0" in osevent_release_nexus. I haven't changed my Xen and I updated libvirt from cc92ee32cde8d0ce0092d3ff30aece90af7b1781 + this patch to eec2f65946388102f8acdd63f13c21a8b9aae806, nothing in that range looks relevant. Any ideas? Ian. 2014-04-28 11:02:44.719+0000: 3029: info : libvirt version: 1.2.4 2014-04-28 11:02:44.719+0000: 3029: error : dnsmasqCapsRefreshInternal:726 : Cannot check dnsmasq binary dnsmasq: No such file or directory 2014-04-28 11:02:44.723+0000: 3029: error : virFirewallValidateBackend:156 : direct firewall backend requested, but /sbin/ebtables is not available: No such file or directory 2014-04-28 11:02:44.753+0000: 3029: error : virExec:417 : Cannot find 'pm-is-supported' in path: No such file or directory 2014-04-28 11:02:44.753+0000: 3029: warning : virQEMUCapsInit:946 : Failed to get host power management capabilities [Thread 0xb1553420 (LWP 3029) exited] 2014-04-28 11:02:45.679+0000: 3022: error : libxlDomainStart:1189 : internal error: libxenlight failed to create new domain 'libvirt-test' Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb5017420 (LWP 3022)] 0xb1706324 in osevent_release_nexus (gc=0xb5016904, nexi_idle=0x2a0b5c74, nexus=0x0) at libxl_event.c:119 119 libxl_event.c: No such file or directory. (gdb) bt #0 0xb1706324 in osevent_release_nexus (gc=0xb5016904, nexi_idle=0x2a0b5c74, nexus=0x0) at libxl_event.c:119 #1 0xb1706e60 in osevent_hook_pre_release (nexus=0x2a0b5ccc, nexi_idle=<optimized out>, ev=0x2a0b5cb8, gc=0xb5016904) at libxl_event.c:149 #2 libxl__ev_fd_deregister (gc=0xb5016904, ev=0x2a0b5cb8) at libxl_event.c:231 #3 0xb16dd2b4 in libxl_ctx_free (ctx=0x2a0b5c00) at libxl.c:156 #4 0xb173cbd6 in libxlDomainObjPrivateDispose () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so #5 0xb6c8745a in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0 #6 0xb173cc5a in libxlDomainObjPrivateFree () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so #7 0xb6cb39ee in virDomainObjDispose () from /opt/libvirt/lib/libvirt.so.0 #8 0xb6c8745a in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0 #9 0xb6cb4342 in virDomainObjListRemove () from /opt/libvirt/lib/libvirt.so.0 #10 0xb173ffb4 in libxlDomainCreateXML () from /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so #11 0xb6d389d0 in virDomainCreateXML () from /opt/libvirt/lib/libvirt.so.0 #12 0x2a018b8a in remoteDispatchDomainCreateXML () #13 0x2a018ac8 in remoteDispatchDomainCreateXMLHelper () #14 0x2a054cee in virNetServerProgramDispatchCall () #15 0x2a05493a in virNetServerProgramDispatch () #16 0x2a04efc8 in virNetServerProcessMsg () #17 0x2a04f080 in virNetServerHandleJob () #18 0xb6c9d318 in virThreadPoolWorker () from /opt/libvirt/lib/libvirt.so.0 #19 0xb6c9cd9c in virThreadHelper () from /opt/libvirt/lib/libvirt.so.0 #20 0xb6be3ebc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0 #21 0xb6b517f8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 #22 0xb6b517f8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
On Mon, 2014-04-28 at 12:17 +0100, Ian Campbell wrote:
On Fri, 2014-04-25 at 14:12 -0600, Jim Fehlig wrote:
I dropped initializing the variable and pushed the patch. Thanks!
Thanks! I rebased to current master (no additional patches on my end) tried to test and suddenly libvirtd is segfaulting in libxl when I run virsh create. The fault is at "nexus->ev = 0" in osevent_release_nexus. I haven't changed my Xen and I updated libvirt from cc92ee32cde8d0ce0092d3ff30aece90af7b1781 + this patch to eec2f65946388102f8acdd63f13c21a8b9aae806, nothing in that range looks relevant.
Any ideas?
As soon as a wrote this and moved onto something else I realised that I had clearer out some "cruft" from /boot -- including the kernel which my cfg file was referencing.... Fixing that I can now confirm that your modification to my patch was correct and that consoles work for me on ARM. Ian.
participants (5)
-
Daniel P. Berrange -
Ian Campbell -
Ian Campbell
-
Jim Fehlig -
Konrad Rzeszutek Wilk