[vdsm] new API verb: getVersionInfo()
… New verb proposal: getVersionInfo() Background Right now VDSM has only one possibility to discover the peer VDSM version — it is to call getVdsCapabilities(). All would be nice, but the verb does a lot of stuff, including disk I/O (rpm data query). It is a serious issue for high-loaded hosts, that can even trigger call timeout. Rationale Working in an environment with multiple VDSM versions, it is inevitable to fall in a simple choice: * always operate with one API, described once and forever * use different protocol versions. It is a common practice to reserve something in a protocol, that will represent the protocol version. Any protocols w/o version info sooner or later face the need to guess a version, that is much worse. On the other hand, involving rpm queries and CPU topology calculation into the protocol version discovery is an overkill. So the simplest way is to reserve a new verb for it. Usecases It can be used in the future in *any* VDSM communication that can expose version difference. Implementation Obviously, the usage of a new verb in the current release, e.g. RHEV-3.1 can be done only in try/catch way, 'cause RHEV-3.0 does not support it. But to be able to use it in RHEV-3.2, we should already have it in 3.1. Even if we will not use it yet, the future usecases are pretty straightforward. So pls comment it: http://gerrit.ovirt.org/#/c/8431/ -- Peter V. Saveliev ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] vdsClient error after reinstalling vdsm
Hi! This is a low priority problem. Each time I reinstall vdsm from rpm, I get this error when running vdsClient: Traceback (most recent call last): File /usr/lib64/python2.6/runpy.py, line 122, in _run_module_as_main __main__, fname, loader, pkg_name) File /usr/lib64/python2.6/runpy.py, line 34, in _run_code exec code in run_globals File /usr/share/vdsm/vdsClient.py, line 28, in module from vdsm import vdscli ImportError: cannot import name vdscli And after a reboot it works fine again. Very strange behavior. Anyone knows how to make it work without reboot? Thx, Laszlo ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsClient error after reinstalling vdsm
I have found that I cannot run vdsClient from within the vdsm source tree. Is it possible that this is the problem you see as well? Perhaps after rebooting you logged in and were in a different directory? On Wed, Oct 17, 2012 at 10:53:04AM -0400, Laszlo Hornyak wrote: Hi! This is a low priority problem. Each time I reinstall vdsm from rpm, I get this error when running vdsClient: Traceback (most recent call last): File /usr/lib64/python2.6/runpy.py, line 122, in _run_module_as_main __main__, fname, loader, pkg_name) File /usr/lib64/python2.6/runpy.py, line 34, in _run_code exec code in run_globals File /usr/share/vdsm/vdsClient.py, line 28, in module from vdsm import vdscli ImportError: cannot import name vdscli And after a reboot it works fine again. Very strange behavior. Anyone knows how to make it work without reboot? Thx, Laszlo ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Adam Litke a...@us.ibm.com IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsClient error after reinstalling vdsm
- Original Message - From: Adam Litke a...@us.ibm.com To: Laszlo Hornyak lhorn...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, October 17, 2012 5:09:12 PM Subject: Re: [vdsm] vdsClient error after reinstalling vdsm I have found that I cannot run vdsClient from within the vdsm source tree. Is it possible that this is the problem you see as well? Perhaps after rebooting you logged in and were in a different directory? Ah yes, I remember python confuses the [whatever the python word is for classpath] when you are in the source tree. I hope I did not make that mistake :) On Wed, Oct 17, 2012 at 10:53:04AM -0400, Laszlo Hornyak wrote: Hi! This is a low priority problem. Each time I reinstall vdsm from rpm, I get this error when running vdsClient: Traceback (most recent call last): File /usr/lib64/python2.6/runpy.py, line 122, in _run_module_as_main __main__, fname, loader, pkg_name) File /usr/lib64/python2.6/runpy.py, line 34, in _run_code exec code in run_globals File /usr/share/vdsm/vdsClient.py, line 28, in module from vdsm import vdscli ImportError: cannot import name vdscli And after a reboot it works fine again. Very strange behavior. Anyone knows how to make it work without reboot? Thx, Laszlo ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Adam Litke a...@us.ibm.com IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] Network related hooks in vdsm
On 10/16/2012 09:31 AM, Livnat Peer wrote: On 16/10/12 08:52, Mike Kolesnik wrote: - Original Message - On 10/10/12 16:47, Igor Lvovsky wrote: Hi everyone, As you know vdsm has hooks mechanism and we already support dozen of hooks for different needs. Now it's a network's time. We would like to get your comments regarding our proposition for network related hooks. In general we are planning to prepare framework for future support of bunch network related hooks. Some of them already proposed by Itzik Brown [1] and Dan Yasny [2]. Below you can find the additional hooks list that we propose: Many of the API calls bellow are deprecated. Why do we want to add hooks before/after to deprecated APIs? They are actually still very much in use with the REST API. Deprecate does not mean not in use but not using it going forward. Today if a user is using 3.1 cluster/DC in the UI or the setupNetwork API (which is the recommended way to configure your network in 3.1 and in future versions) the hooks for add/edit-Network won't get activated and that is confusing to the users (and the developers). Perhaps we should address just the logical entry points instead of specific commands. A command such as setup networks can trigger multiple logical events in which hooks can be planted (same goes for edit network in a smaller scale). What you are suggesting above is to deviate from the current hook mechanism we have in VDSM and add some logic to where/when we activate hooks. That's an interesting suggestion, I suggest to write a wiki page and start thinking of the implementation implications of it. Since I like the idea I'll work with you on the wiki and we'll see if we can get something more useful to the users and send a formal proposal. question is there is any high demand/priority for network hooks other than hotplug nic, and do we have a clear vision of a stable api for them. one thing to consider is allowing to define custom properties at logical network and virtual nic level though. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC]about the implement of text-based console
On 10/16/2012 12:18 AM, David Jaša wrote: Ewoud Kohl van Wijngaarden píše v Po 15. 10. 2012 v 22:46 +0200: On Tue, Oct 16, 2012 at 12:51:23AM +0800, Xu He Jie wrote: [SNIP] Hi, Adam, Could you explain more detail about how streaming API can survive a VM migration? If we want to support migration, I think we should implement console server out of vdsm. Actually, It will work like proxy. So we call it as consoleProxy now. That consoleProxy can deploy on same machine with engine, or standalone, or virtual machine. I think its' working flow as below: 1. user request open console to engine. 2. engine setTicket(uuid, ticket, hostofvm) to consoleProxy. consoleProxy need provide api to engine. 3. engine return ticket to user. 4. user 'ssh UUID@consoleProxy' with ticket. 5. consoleProxy connect 'virsh -c qemu+tls://hostofvm/system console'. the host of running consoleProxy should have certificates of all vdsm host. 6. consoleProxy redirect output of 'virsh -c qemu+tls://hostofvm/system console' with ssh protocol. Same with currently implement. we can use system sshd or paramiko. If we use paramiko, it almost reuse the code of consoleServer that I have already writen. After vm migrated: 1. engine tell consoleProxy that vm was migrated. I guess engine can know vm finished migration? And engine how to push the event of vm finished migration to consoleProxy? Engine only have rest api didn't support event push? Is streaming api can resolve this problem? 2. consoleProxy kill 'virsh console'. 3. reconnect to new host of vm with 'virsh console' again. There will missing some character if the reconnection isn't enough fast. This is hardly to resolve except implement ssh in qemu. I guess streaming api have some problem too. 4. continue redirect 'virsh console'. Actually if we implement consoleProxy out of vdsm, we don't need decide it will run on physical machine or virtual machine now. A lot detail need to think. I'm not cover all problem. And I haven't code to prove that work now. Just depend on thinking. Is this make sense? How is this handled with current displays like VNC and Spice? Extending spice to provide just serial console remoting actually seems the easiest way to provide remote text-only console because most of the code path is already mature (used for client to guest agent communication) and e.g. spicy to just provide a device where e.g. screen could connect or just provide the console itself. CCing spice-devel would it allow users to script with/over it like they can with ssh? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
