RFC - New option 'Serial Console' in the template UI
Hello everybody! I'd like to hear from you if it would be nice to have a new option in the Template UI to redirect the output to a serial console. Today, there is a field called 'Graphics' with two options [VNC, Spice]. What if we have [VNC, Spice, Serial Console (no-graphic)]? A drawback is the need of an external tool (like virsh console) to be able to take the console, as Kimchi doesn't provide one. What do you think? Thank you! -- Jose Ricardo Ziviani ----------------------------- Software Engineer Linux Technology Center - IBM
On Tue, 2015-03-24 at 17:10 -0300, Jose Ricardo Ziviani wrote:
Hello everybody!
I'd like to hear from you if it would be nice to have a new option in the Template UI to redirect the output to a serial console.
Today, there is a field called 'Graphics' with two options [VNC, Spice]. What if we have [VNC, Spice, Serial Console (no-graphic)]?
A drawback is the need of an external tool (like virsh console) to be able to take the console, as Kimchi doesn't provide one.
What do you think?
Thank you!
I would love an option like this. Typically when I need to watch the boot sequence I use the console much more often than VNC. To be able to see all the output in virsh console would be very helpful.
On 24-03-2015 17:10, Jose Ricardo Ziviani wrote:
Hello everybody!
I'd like to hear from you if it would be nice to have a new option in the Template UI to redirect the output to a serial console.
Today, there is a field called 'Graphics' with two options [VNC, Spice]. What if we have [VNC, Spice, Serial Console (no-graphic)]?
A drawback is the need of an external tool (like virsh console) to be able to take the console, as Kimchi doesn't provide one.
What do you think?
Thank you
I like the idea. At first, we could rely on the user accessing the console externally via something like virsh, but wouldn't it be possible to implement a console viewer on Kimchi as well? :-) Anyway, I'm looking forward for that feature.
I'm not sure, but I guess this topic was already discussed here and I don't remember why we postpone. Need check the history of ML or the logs of weekly scrum to check the reasons. Nevertheless, I think it's a nice feature and will help a lot users in some cases. Paulo Vital. On Tue, Mar 24, 2015 at 9:52 PM Crístian Viana <vianac@linux.vnet.ibm.com> wrote:
On 24-03-2015 17:10, Jose Ricardo Ziviani wrote:
Hello everybody!
I'd like to hear from you if it would be nice to have a new option in the Template UI to redirect the output to a serial console.
Today, there is a field called 'Graphics' with two options [VNC, Spice]. What if we have [VNC, Spice, Serial Console (no-graphic)]?
A drawback is the need of an external tool (like virsh console) to be able to take the console, as Kimchi doesn't provide one.
What do you think?
Thank you
I like the idea. At first, we could rely on the user accessing the console externally via something like virsh, but wouldn't it be possible to implement a console viewer on Kimchi as well? :-)
Anyway, I'm looking forward for that feature.
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 25/03/15 07:10, Jose Ricardo Ziviani wrote:
Hello everybody!
I'd like to hear from you if it would be nice to have a new option in the Template UI to redirect the output to a serial console.
Today, there is a field called 'Graphics' with two options [VNC, Spice]. What if we have [VNC, Spice, Serial Console (no-graphic)]?
A drawback is the need of an external tool (like virsh console) to be able to take the console, as Kimchi doesn't provide one.
It shouldn't be too hard to add it though, wiring up the console port to a websocket should need minimal changes, and there's a variety of javascript terminal emulators that are surprisingly decent these days. hterm, the one I'm most familiar with is part of the chromeos tree, and looks to be fairly trivial to wire up to a websocket. code: https://github.com/chromium/hterm
On 24/03/2015 17:10, Jose Ricardo Ziviani wrote:
Hello everybody!
I'd like to hear from you if it would be nice to have a new option in the Template UI to redirect the output to a serial console.
Today, there is a field called 'Graphics' with two options [VNC, Spice]. What if we have [VNC, Spice, Serial Console (no-graphic)]?
A drawback is the need of an external tool (like virsh console) to be able to take the console, as Kimchi doesn't provide one.
What do you think?
As Paulo said we have already started that discussion some time ago. The problem was in identifying a stable web tool to render the serial console on Kimchi using websockets. The thread discussion: http://lists.ovirt.org/pipermail/kimchi-devel/2014-October/008173.html We can also try to go deeper in the Julien's suggestion (https://github.com/chromium/hterm) About the original proposal itself, I don't think serial console should exclude the graphical console. We can have both simultaneously. So from a backend perspective, we should change Kimchi to also create the VM with both console types. And on UI, we should add a new option to render the serial console when available (as Kimchi must work with guests created by other tools).
Thank you!
Hello everybody! I tried PCI Hot Plug in Kimchi but it didn't work as expected. Once my VM was running I plugged my audio device into my VM successfully, I was able to use it flawlessly. However, if I reboot (or completely turn off/on), the VM will not boot anymore. It tries to exclusively get the device but for some reason (libvirt bug?) that device was not detached from the host. Then, I must to turn off the VM amd remove the PCI using Kimchi to be able to boot it again. Such behavior doesn't happen if I add the PCI when the VM is turned off. Also, virt-manager doesn't look to support hot plug, it throws a libvirt exception (libvirtmod.virDomainAttachDevice) if I try to add a PCI while VM is running. Does anybody have experienced it before, any advise? Thank you -- Jose Ricardo Ziviani ----------------------------- Software Engineer Linux Technology Center - IBM
On 03/27/2015 03:22 PM, Jose Ricardo Ziviani wrote:
Hello everybody!
I tried PCI Hot Plug in Kimchi but it didn't work as expected. Once my VM was running I plugged my audio device into my VM successfully, I was able to use it flawlessly.
However, if I reboot (or completely turn off/on), the VM will not boot anymore. It tries to exclusively get the device but for some reason (libvirt bug?) that device was not detached from the host. Then, I must to turn off the VM amd remove the PCI using Kimchi to be able to boot it again.
Unfortunately the only way to tell if it's Kimchi or libvirt's fault is to try to do the whole process without Kimchi. In other words, creating the VM and plug/unplug the PCI devices using virsh.
Such behavior doesn't happen if I add the PCI when the VM is turned off. Also, virt-manager doesn't look to support hot plug, it throws a libvirt exception (libvirtmod.virDomainAttachDevice) if I try to add a PCI while VM is running.
virt-manager can be a good benchmark of libvirt current capabilities ( I believe both are maintained by Red Hat). If latest virt-manager does not support PCI hot plug there is a good chance that libvirt support for this feature is not complete or it is in early stages. This only makes libvirt only testing more critical. We need to determine exactly where libvirt is as far as PCI Hot Plug is concerned.
Does anybody have experienced it before, any advise?
Thank you
On 30-03-2015 11:01, Daniel Henrique Barboza wrote:
On 03/27/2015 03:22 PM, Jose Ricardo Ziviani wrote:
Hello everybody!
I tried PCI Hot Plug in Kimchi but it didn't work as expected. Once my VM was running I plugged my audio device into my VM successfully, I was able to use it flawlessly.
However, if I reboot (or completely turn off/on), the VM will not boot anymore. It tries to exclusively get the device but for some reason (libvirt bug?) that device was not detached from the host. Then, I must to turn off the VM amd remove the PCI using Kimchi to be able to boot it again.
Unfortunately the only way to tell if it's Kimchi or libvirt's fault is to try to do the whole process without Kimchi. In other words, creating the VM and plug/unplug the PCI devices using virsh.
Such behavior doesn't happen if I add the PCI when the VM is turned off. Also, virt-manager doesn't look to support hot plug, it throws a libvirt exception (libvirtmod.virDomainAttachDevice) if I try to add a PCI while VM is running.
virt-manager can be a good benchmark of libvirt current capabilities ( I believe both are maintained by Red Hat). If latest virt-manager does not support PCI hot plug there is a good chance that libvirt support for this feature is not complete or it is in early stages.
This only makes libvirt only testing more critical. We need to determine exactly where libvirt is as far as PCI Hot Plug is concerned.
Does anybody have experienced it before, any advise?
Thank you
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Daniel, Thank you for all the information. I tested here again and it worked fine. In my VM I was running Debian with an older kernel. Now, with Ubuntu 10.10 it worked flawlessly. That problem reported seems to be the guest running an older kernel, nothing to do with libvirt or kimchi. I'll continue my testing using different combinations. I'll report here as soon as possible (unfortunately my network is not good today). Regards! -- Jose Ricardo Ziviani ----------------------------- Software Engineer Linux Technology Center - IBM
On 30-03-2015 16:44, Jose Ricardo Ziviani wrote:
On 30-03-2015 11:01, Daniel Henrique Barboza wrote:
On 03/27/2015 03:22 PM, Jose Ricardo Ziviani wrote:
Hello everybody!
I tried PCI Hot Plug in Kimchi but it didn't work as expected. Once my VM was running I plugged my audio device into my VM successfully, I was able to use it flawlessly.
However, if I reboot (or completely turn off/on), the VM will not boot anymore. It tries to exclusively get the device but for some reason (libvirt bug?) that device was not detached from the host. Then, I must to turn off the VM amd remove the PCI using Kimchi to be able to boot it again.
Unfortunately the only way to tell if it's Kimchi or libvirt's fault is to try to do the whole process without Kimchi. In other words, creating the VM and plug/unplug the PCI devices using virsh.
Such behavior doesn't happen if I add the PCI when the VM is turned off. Also, virt-manager doesn't look to support hot plug, it throws a libvirt exception (libvirtmod.virDomainAttachDevice) if I try to add a PCI while VM is running.
virt-manager can be a good benchmark of libvirt current capabilities ( I believe both are maintained by Red Hat). If latest virt-manager does not support PCI hot plug there is a good chance that libvirt support for this feature is not complete or it is in early stages.
This only makes libvirt only testing more critical. We need to determine exactly where libvirt is as far as PCI Hot Plug is concerned.
Does anybody have experienced it before, any advise?
Thank you
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Daniel,
Thank you for all the information. I tested here again and it worked fine.
In my VM I was running Debian with an older kernel. Now, with Ubuntu 10.10 it worked flawlessly. That problem reported seems to be the guest running an older kernel, nothing to do with libvirt or kimchi.
*Ubuntu 14.10
I'll continue my testing using different combinations. I'll report here as soon as possible (unfortunately my network is not good today).
Regards!
-- Jose Ricardo Ziviani ----------------------------- Software Engineer Linux Technology Center - IBM
participants (7)
-
Aline Manera -
Crístian Viana -
Daniel Henrique Barboza -
Jose Ricardo Ziviani -
Julien Goodwin -
Kevin Zander -
Paulo Ricardo Paz Vital