Created attachment 1092788 [details] engine's sosreport Description of problem: Can't connect to guest-VM created from template via serial console. Available Serial Consoles: 00 RHEL_7_2_VM2[3c0bb6b7-43e1-427c-9575-f58b50a72dae] 01 RHEL_7_2_VM2[3c0bb6b7-43e1-427c-9575-f58b50a72dae] 02 RHEL7_2_VM_1[ea857677-f6d2-4d16-a40a-a44222670482] 03 RHEL7_2_VM_1[ea857677-f6d2-4d16-a40a-a44222670482] SELECT> 01 ERROR: Console '3c0bb6b7-43e1-427c-9575-f58b50a72dae.sock' is not available debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow reply 0 Connection to alma02.qa.lab.tlv.redhat.com closed. debug1: channel 0: free: client-session, nchannels 1 Connection to 10.35.160.204 closed. Transferred: sent 4184, received 4784 bytes, in 5.5 seconds Bytes per second: sent 755.0, received 863.2 debug1: Exit status 1 The VM 01 RHEL_7_2_VM2[3c0bb6b7-43e1-427c-9575-f58b50a72dae] was created from the template, made from RHEL7_2_VM_1[ea857677-f6d2-4d16-a40a-a44222670482]. I can connect to the original VM, but not to the RHEL_7_2_VM2. The permissions and console settings were inherited from the RHEL7_2_VM_1. I see difference between two VMs in WEBUI, for the original VM in "VM Devices" there is "{enableSocket=true}" under "Spec Params" for the Console, while for VM created from template, there is "{}" under the "Spec Params". Version-Release number of selected component (if applicable): Engine: ovirt-vmconsole-proxy-1.0.0-1.el6ev.noarch ovirt-engine-extension-aaa-jdbc-1.0.1-1.el6ev.noarch ovirt-host-deploy-1.4.0-1.el6ev.noarch ovirt-host-deploy-java-1.4.0-1.el6ev.noarch ovirt-vmconsole-1.0.0-1.el6ev.noarch rhevm-3.6.0.3-0.1.el6.noarch Linux version 2.6.32-573.7.1.el6.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Thu Sep 10 13:42:16 EDT 2015 Host: Linux version 3.10.0-327.el7.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Thu Oct 29 17:29:29 EDT 2015 libvirt-client-1.2.17-13.el7.x86_64 vdsm-4.17.10.1-0.el7.centos.noarch sanlock-3.2.4-1.el7.x86_64 mom-0.5.1-2.el7.noarch qemu-kvm-rhev-2.3.0-31.el7.x86_64 ovirt-vmconsole-host-1.0.1-0.0.master.20151105234454.git3e5d52e.el7.noarch ovirt-release36-snapshot-001-2.noarch ovirt-vmconsole-1.0.1-0.0.master.20151105234454.git3e5d52e.el7.noarch ovirt-release36-001-2.noarch How reproducible: 100% Steps to Reproduce: 1.Create serial-console working environment on 3.6 engine with at least one host and one RHEL7.2 guest VM, to which you was able to connect via serial console. 2.Create template from guest-VM, inheriting the original permissions and settings from it. 3.Create new VM based on template. 4.Start the new VM and connect to it via serial-console. Actual results: ERROR: Console '3c0bb6b7-43e1-427c-9575-f58b50a72dae.sock' is not available Expected results: Serial connection should be established. Additional info: sosreports from host and engine attached.
Created attachment 1092791 [details] missing spec params image
Created attachment 1092792 [details] correct spec params image
Wrong component again. Not sure why there are dups in list.
(In reply to Alon Bar-Lev from comment #3) > Wrong component again. > > Not sure why there are dups in list. Dups are because of the https://bugzilla.redhat.com/show_bug.cgi?id=1279339
VDSM intentionally creates the unix domain socket that allows to connect to the guest only if Engine asks him, to preserve backward compatibility to older Engine. So behaviour of VDSM looks correct. But it seems that the specParams are not copied from the base VM in the template VM, and I found this surprising. Tomas, can you have a look? Is that indeed the case? Is it intentional that specParams are not copied?
Created attachment 1092808 [details] sosreports from engine and host
Just reproduced the issue to give a better logs, as original sosreport from the host didn't fit the Bugzilla space limitation.
There is a WA, after creating the VM from the template, customer should edit the VM, manually clear the "Enable VirtIO serial console" mark, then save, then do all this again to enable the functionality and then start the VM. It's OK for one VM, but will be a bit problematic for a large group of VMs.
(In reply to Francesco Romani from comment #5) > VDSM intentionally creates the unix domain socket that allows to connect to > the guest only if Engine asks him, to preserve backward compatibility to > older Engine. > > So behaviour of VDSM looks correct. But it seems that the specParams are not > copied from the base VM in the template VM, and I found this surprising. > > Tomas, can you have a look? Is that indeed the case? Is it intentional that > specParams are not copied? Nevermind and sorry for the noise: seems just a bug, patch coming
@Francesco: yes, the console's spec params are not copied. Look at VmDeviceUtils.copyVmDevices() into "case CONSOLE" - this results in addConsoleDevice() which uses as spec params the getConsoleDeviceSpecParams() which always creates new ones. I don't think there is any particular reason not to copy the spec params the same way as for example the balloon device does.
decreasing severity since there is a within-UI workaround
this is not actually modified yet, we need the backport to branch 3.6 (and maybe 3.6.1)
wrong product, patches are for ovirt-engine and not vdsm - changed. wrong target milestone - the patch is merged and included in ovirt-engine-3.6.1, see https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs%2Fheads%2Fovirt-engine-3.6.1 moving to ON_QA since this was in the build.
Works for me on these components: ovirt-host-deploy-java-1.4.1-1.el6ev.noarch ovirt-vmconsole-1.0.0-1.el6ev.noarch ovirt-host-deploy-1.4.1-1.el6ev.noarch ovirt-vmconsole-proxy-1.0.0-1.el6ev.noarch ovirt-engine-extension-aaa-jdbc-1.0.4-1.el6ev.noarch rhevm-3.6.1.1-0.1.el6.noarch Available Serial Consoles: 00 vm1[2feb7c67-0875-4407-a64e-bd3d7a2120bd] 01 vm2[69da8388-1f81-46e8-8565-32a71a52580f] SELECT> 01 Red Hat Enterprise Linux Server 7.2 (Maipo) Kernel 3.10.0-327.el7.x86_64 on an x86_64 RHEL7 login: debug1: channel 0: free: client-session, nchannels 1 Connection to <engine's FQDN here> closed. Transferred: sent 4168, received 4384 bytes, in 17.8 seconds Bytes per second: sent 234.2, received 246.3 debug1: Exit status -1
According to verification status and target milestone this issue should be fixed in oVirt 3.6.1. Closing current release.