Re: [vdsm] new API verb: getVersionInfo()
On Wed, Oct 17, 2012 at 10:07:43AM -0500, Adam Litke wrote:
Thanks for posting your idea on the list here. I like the idea of a more
fine-grained version query API. getVdsCapabilities has become too much of a
catch-all and I agree that something lighter is useful. I do think vdsm will
want to add a real capabilities mechanism and it could probably go here as
well.
As we work to make the vdsm API evolve in a stable, compatible manner,
capabilities/feature-bits will come into play. Since you're proposing a
structure return value, we can easily add the capabilities field to it in a
future release, but it might make sense to have it there now to reduce
client-side complexity of figuring out if the return value has a capabilities
item.
To avoid the bloat that we have with the current getVdsCapabilities API, I
propose a simple format for the new capabilities:
{'enum': 'Capabilities',
'data': ['StorageDomain_30', 'StorageDomain_22', 'Sanlock', ...]}
and then add the following to the return type for your new API:
'capabilities': ['Capabilities']
This is essentially an expandable bitmask of features where a feature is
present
by its presense in the 'capabilities' array. This will be extensible by
simply
adding new capabilities to the enum as we find them to be necessary.
Thoughts on this? The reason I am bringing it up now is it would be nice to
restrict the pain of migrating to this new version API to just one time.
I fully agree - that's what I've ment in my
http://gerrit.ovirt.org/#/c/8431/4/vdsm_api/vdsmapi-schema.json comment
on a bag of capability flags.
On Wed, Oct 17, 2012 at 01:37:08PM +0200, Peter V. Saveliev wrote:
…
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
--
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
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsClient error after reinstalling vdsm
On Wed, Oct 17, 2012 at 11:44:54AM -0400, Laszlo Hornyak wrote: - 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 :) It's PYTHONPATH, and fixing this annoyance is the laster bullet on http://wiki.ovirt.org/wiki/Vdsm_TODO#Cleanup 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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
currently getVdsCaps() does a lot of unrelated things most of them have no
relation to capabilites.
This was done because of HTTP overhead. Instead of calling multiple commands we
will call one that does everything.
I agree with the suggestion that getVdsCaps() will actually return the
capabilities.
Capabilities being:
- storage core version supported domain formats
- VM core version and supported host capabilites.
- network core and capabilities.
- etc...
These all should be mostly static and set at boot.
As to the query API. I personally dislike the idea of a bag API. Now that we
are moving away from HTTP, call overhead is no longer an issue so we can have
multiple verbs and call them sequentially. In actuality we already do.
Internally getVdsCaps() just aggregates other APIs.
This makes return values of the method easier to handle and makes changing the
results of an API call not affect users that don't care about that change.
This also has better performance as storage APIs tend to slow the response and
sending multiple commands would mean that you can get the Network stats even
though the storage server is down.
- Original Message -
From: Dan Kenigsberg dan...@redhat.com
To: Adam Litke a...@us.ibm.com
Cc: vdsm-devel@lists.fedorahosted.org, Michal Skrivanek
mskri...@redhat.com
Sent: Thursday, October 18, 2012 4:38:16 AM
Subject: Re: [vdsm] new API verb: getVersionInfo()
On Wed, Oct 17, 2012 at 10:07:43AM -0500, Adam Litke wrote:
Thanks for posting your idea on the list here. I like the idea of
a more
fine-grained version query API. getVdsCapabilities has become too
much of a
catch-all and I agree that something lighter is useful. I do think
vdsm will
want to add a real capabilities mechanism and it could probably go
here as well.
As we work to make the vdsm API evolve in a stable, compatible
manner,
capabilities/feature-bits will come into play. Since you're
proposing a
structure return value, we can easily add the capabilities field to
it in a
future release, but it might make sense to have it there now to
reduce
client-side complexity of figuring out if the return value has a
capabilities
item.
To avoid the bloat that we have with the current getVdsCapabilities
API, I
propose a simple format for the new capabilities:
{'enum': 'Capabilities',
'data': ['StorageDomain_30', 'StorageDomain_22', 'Sanlock', ...]}
and then add the following to the return type for your new API:
'capabilities': ['Capabilities']
This is essentially an expandable bitmask of features where a
feature is present
by its presense in the 'capabilities' array. This will be
extensible by simply
adding new capabilities to the enum as we find them to be
necessary.
Thoughts on this? The reason I am bringing it up now is it would
be nice to
restrict the pain of migrating to this new version API to just one
time.
I fully agree - that's what I've ment in my
http://gerrit.ovirt.org/#/c/8431/4/vdsm_api/vdsmapi-schema.json
comment
on a bag of capability flags.
On Wed, Oct 17, 2012 at 01:37:08PM +0200, Peter V. Saveliev wrote:
…
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
--
Adam Litke
Re: [vdsm] [Spice-devel] [RFC]about the implement of text-based console
On 10/18/2012 12:13 PM, Alon Levy wrote: 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? If I understand correctly the idea is to add another channel for spice that would connect to a char device in qemu that in turn connects to a serial port. The result is a spice client that can display and interact, but not a scripting extension. We could also create a unix domain socket to expose this connection on the client, and the client could then use that for scripting (but this will be instead of displaying, since you can't multiplex the console in a meaningful way - unless you run screen/tmux over it maybe): remote-viewer --spice-console-unix-domain-socket /tmp/spice.uds (This option assumes we want a single console channel - if we have multiple we will need to name them too) Anyone will be able to script it using for instance: socat UNIX-CONNECT:/tmp/spice.uds SYSTEM:echo hello world We could also turn it into a pty (socat can do that). i think using spice this way may be a very good solution, to proxy a serial console. only caveat is it requires client to install spice, vs. just using ssh. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
On 10/18/2012 06:03 PM, Saggi Mizrahi wrote: currently getVdsCaps() does a lot of unrelated things most of them have no relation to capabilites. This was done because of HTTP overhead. Instead of calling multiple commands we will call one that does everything. I agree with the suggestion that getVdsCaps() will actually return the capabilities. Capabilities being: - storage core version supported domain formats - VM core version and supported host capabilites. - network core and capabilities. - etc... These all should be mostly static and set at boot. As to the query API. I personally dislike the idea of a bag API. Now that we are moving away from HTTP, call overhead is no longer an issue so we can have multiple verbs and call them sequentially. In actuality we already do. Internally getVdsCaps() just aggregates other APIs. This makes return values of the method easier to handle and makes changing the results of an API call not affect users that don't care about that change. This also has better performance as storage APIs tend to slow the response and sending multiple commands would mean that you can get the Network stats even though the storage server is down. i thought getVdsCaps return the storage results from cache, which is refreshed by another thread, to make sure getVdsCaps has no latency. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
On 10/18/2012 08:34 PM, Itamar Heim wrote: On 10/18/2012 06:03 PM, Saggi Mizrahi wrote: currently getVdsCaps() does a lot of unrelated things most of them have no relation to capabilites. This was done because of HTTP overhead. Instead of calling multiple commands we will call one that does everything. I agree with the suggestion that getVdsCaps() will actually return the capabilities. Capabilities being: - storage core version supported domain formats - VM core version and supported host capabilites. - network core and capabilities. - etc... These all should be mostly static and set at boot. As to the query API. I personally dislike the idea of a bag API. Now that we are moving away from HTTP, call overhead is no longer an issue so we can have multiple verbs and call them sequentially. In actuality we already do. Internally getVdsCaps() just aggregates other APIs. This makes return values of the method easier to handle and makes changing the results of an API call not affect users that don't care about that change. This also has better performance as storage APIs tend to slow the response and sending multiple commands would mean that you can get the Network stats even though the storage server is down. i thought getVdsCaps return the storage results from cache, which is refreshed by another thread, to make sure getVdsCaps has no latency. Well this is what it should do but it still doesn't do it. At least from what I have seen so far. I am currently working on a PoC implementation for caching packages and having so pyinotify based trigger for refreshing the cache. I plan to really cache everything and we'll have a background thread running for updating the cached data on changes. I will be sending the proposed solution for it to the list. So we can discuss it into more details. -- Regards, Vinzenz Feenstra Senior Software Engineer IRC: vfeenstr or evilissimo ___ 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/18/2012 09:13 PM, Dave Allan wrote: On Thu, Oct 18, 2012 at 02:21:44AM +0200, Itamar Heim wrote: On 10/15/2012 07:41 PM, Dave Allan wrote: On Fri, Oct 12, 2012 at 11:25:47AM -0500, Ryan Harper wrote: * Adam Litke a...@us.ibm.com [2012-10-12 08:13]: On Fri, Oct 12, 2012 at 04:55:20PM +0800, Zhou Zheng Sheng wrote: on 09/04/2012 22:19, Ryan Harper wrote: * Dan Kenigsberg dan...@redhat.com [2012-09-04 05:53]: On Tue, Sep 04, 2012 at 03:05:37PM +0800, Xu He Jie wrote: On 09/03/2012 10:33 PM, Dan Kenigsberg wrote: On Thu, Aug 30, 2012 at 04:26:31PM -0500, Adam Litke wrote: On Thu, Aug 30, 2012 at 11:32:02AM +0800, Xu He Jie wrote: Hi, I submited a patch for text-based console http://gerrit.ovirt.org/#/c/7165/ the issue I want to discussing as below: 1. fix port VS dynamic port Use fix port for all VM's console. connect console with 'ssh vmUUID@ip -p port'. Distinguishing VM by vmUUID. The current implement was vdsm will allocated port for console dynamically and spawn sub-process when VM creating. In sub-process the main thread responsible for accept new connection and dispatch output of console to each connection. When new connection is coming, main processing create new thread for each new connection. Dynamic port will allocated port for each VM and use range port. It isn't good for firewall rules. so I got a suggestion that use fix port. and connect console with 'ssh vmuuid@hostip -p fixport'. this is simple for user. We need one process for accept new connection from fix port and when new connection is coming, spawn sub-process for each vm. But because the console only can open by one process, main process need responsible for dispatching console's output of all vms and all connection. So the code will be a little complex then dynamic port. So this is dynamic port VS fix port and simple code VS complex code. From a usability point of view, I think the fixed port suggestion is nicer. This means that a system administrator needs only to open one port to enable remote console access. If your initial implementation limits console access to one connection per VM would that simplify the code? Yes, using a fixed port for all consoles of all VMs seems like a cooler idea. Besides the firewall issue, there's user experience: instead of calling getVmStats to tell the vm port, and then use ssh, only one ssh call is needed. (Taking this one step further - it would make sense to add another layer on top, directing console clients to the specific host currently running the Vm.) I did not take a close look at your implementation, and did not research this myself, but have you considered using sshd for this? I suppose you can configure sshd to collect the list of known users from `getAllVmStats`, and force it to run a command that redirects VM's console to the ssh client. It has a potential of being a more robust implementation. I have considered using sshd and ssh tunnel. They can't implement fixed port and share console. Would you elaborate on that? Usually sshd listens to a fixed port 22, and allows multiple users to have independet shells. What do you mean by share console? Current implement we can do anything that what we want. Yes, it is completely under our control, but there are down sides, too: we have to maintain another process, and another entry point, instead of configuring a universally-used, well maintained and debugged application. Think of the security implications of having another remote shell access point to a host. I'd much rather trust sshd if we can make it work. Dan. At first glance, the standard sshd on the host is stronger and more robust than a custom ssh server, but the risk using the host sshd is high. If we implement this feature via host ssd, when a hacker attacks the sshd successfully, he will get access to the host shell. After all, the custom ssh server is not for accessing host shell, but just for forwarding the data from the guest console (a host /dev/pts/X device). If we just use a custom ssh server, the code in this server only does 1. auth, 2. data forwarding, when the hacker attacks, he just gets access to that virtual machine. Notice that there is no code written about login to the host in the custom ssh server, and the custom ssh server can be protected under selinux, only allowing it to access /dev/pts/X. In fact using a custom VNC server in qemu is as risky as a custom ssh server in vdsm. If we accepts the former one, then I can accepts the latter one. The consideration is how robust of the custom ssh server, and the difficulty to maintain it. In He Jie's current patch, the ssh auth and transport library is an open-source third-party project, unless the project is well maintained and well proven, using it can be risky. So my opinion is using neither the host sshd, nor a custom ssh server. Maybe we can apply the suggestion from Dan Yasny, running a standard sshd in a very small VM in every host, and forward data from this
Re: [vdsm] new API verb: getVersionInfo()
I don't see how pyinotify is even related to storage stats. It doesn't work with NFS and is a bit flaky when it comes to VFSs like proc or dev. Also it doesn't check liveness or latency so the events don't really give us anything useful. The data is being taken from cache. I assume there is a prepare call there that makes everything slower. This will only be fixed with new style domains that don't have a built in sdUUID. - Original Message - From: Vinzenz Feenstra vfeen...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Michal Skrivanek mskri...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 18, 2012 3:15:47 PM Subject: Re: [vdsm] new API verb: getVersionInfo() On 10/18/2012 08:34 PM, Itamar Heim wrote: On 10/18/2012 06:03 PM, Saggi Mizrahi wrote: currently getVdsCaps() does a lot of unrelated things most of them have no relation to capabilites. This was done because of HTTP overhead. Instead of calling multiple commands we will call one that does everything. I agree with the suggestion that getVdsCaps() will actually return the capabilities. Capabilities being: - storage core version supported domain formats - VM core version and supported host capabilites. - network core and capabilities. - etc... These all should be mostly static and set at boot. As to the query API. I personally dislike the idea of a bag API. Now that we are moving away from HTTP, call overhead is no longer an issue so we can have multiple verbs and call them sequentially. In actuality we already do. Internally getVdsCaps() just aggregates other APIs. This makes return values of the method easier to handle and makes changing the results of an API call not affect users that don't care about that change. This also has better performance as storage APIs tend to slow the response and sending multiple commands would mean that you can get the Network stats even though the storage server is down. i thought getVdsCaps return the storage results from cache, which is refreshed by another thread, to make sure getVdsCaps has no latency. Well this is what it should do but it still doesn't do it. At least from what I have seen so far. I am currently working on a PoC implementation for caching packages and having so pyinotify based trigger for refreshing the cache. I plan to really cache everything and we'll have a background thread running for updating the cached data on changes. I will be sending the proposed solution for it to the list. So we can discuss it into more details. -- Regards, Vinzenz Feenstra Senior Software Engineer IRC: vfeenstr or evilissimo ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
18.10.2012 18:03, Saggi Mizrahi kirjoitti: currently getVdsCaps() does a lot of unrelated things most of them have no relation to capabilites. This was done because of HTTP overhead. Instead of calling multiple commands we will call one that does everything. skip / Can I please make a small note, before we went too deeply into getVdsCapabilities() discussion. What the getVdsCapabilities returns now, it is, literally speaking, *host*info*. That means some reasonable description of the host — installed packages, cpu topology, so on, so forth. … What I propose, is just a dedicated call, that will not carry «all-in-one» info, but only the *version* information. By historical reason there are several meanings of the «version» term in the context of the VDSM — that is VDSM version, RHEV version, cluster versions… But nevertheless. I would stress again: * *not* the host info * *not* the installed packages list * *not* the installed hardware specifications Maybe even not the current weather conditions outside of the datacenter. But only supported *versions* of VDSM *protocols* (API versions). … Returning the version can be done in a fast, reliable manner — yes, I know that one can implement fast cache for rpm queries and so on, but please think: can *any* caching be more reliable and more fast than returning several constant literals? The version information is the basic and vital info in the mixed environment with several versions of the same software. It can be queried often, it must be as simple as it can be at all. That's why I proposed a dedicated API call, that does nothing but returns the version. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] new API verb: getVersionInfo()
… Just to be clear: yes, I think, that getVdsCapabilities() can and should be optimized, but as well it has quite different meaning for different purposes. And what about capabilities «bag» — its format also can be a subject of a change (e.g. long int bitmask ⇒ list of literals), but the version can always remain the version. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Change in vdsm[master]: schema: New type VmParameters
On Thu, Oct 18, 2012 at 02:12:58AM -0400, lvro...@linux.vnet.ibm.com wrote: Royce Lv has posted comments on this change. Change subject: schema: New type VmParameters .. Patch Set 4: Adam, I saw 3 kinds of vm related description spread in the code: (1)vm.conf: query via vm.status()(vm.py), used as return value when changed vm's conf(changeCD, hotplugDisk) (2)vm.stats: query via vm.getStats()(vm.py), which is VM's live stats and used when calling getVmStats.(also used by MOM) (3)vm.parameter: parameter passed to vm.create().(API.py) You are trying to split is (3) from (1); But the live info should be (2) from (1) according to me. To me, VmDefinition contains the hardware properties of the VM (things like devices, amount of memory, number of cpus). It also contains things that can only be known at runtime (VNC display port, device bus information (if not specified in advance), current cdrom disk, etc). VmStatistics are different because they are measured (network activity, cpu usage, etc). VmParameters is like a streamlined VmDefinition where we remove items that cannot be specified at create time. -- To view, visit http://gerrit.ovirt.org/7839 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I00d1b9aed55cbfc2210c1a4091bce17d45b90e67 Gerrit-PatchSet: 4 Gerrit-Project: vdsm Gerrit-Branch: master Gerrit-Owner: Adam Litke a...@us.ibm.com Gerrit-Reviewer: Adam Litke a...@us.ibm.com Gerrit-Reviewer: Federico Simoncelli fsimo...@redhat.com Gerrit-Reviewer: Royce Lv lvro...@linux.vnet.ibm.com Gerrit-Reviewer: Saggi Mizrahi smizr...@redhat.com -- 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
