Proposal VDSM <=> Engine Data Statistics Retrieval Optimization
by Vinzenz Feenstra
Please find the prettier version on the wiki:
http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval
Proposal VDSM - Engine Data Statistics Retrieval
VDSM <=> Engine data retrieval optimization
Motivation:
Currently the RHEVM engine is polling the a lot of data from VDSM every
15 seconds. This should be optimized and the amount of data requested
should be more specific.
For each VM the data currently contains much more information than
actually needed which blows up the size of the XML content quite big. We
could optimize this by splitting the reply on the getVmStats based on
the request of the engine into sections. For this reason Omer Frenkel
and me have split up the data into parts based on their usage.
This data can and usually does change during the lifetime of the VM.
Rarely Changed:
This data is change not very frequent and it should be enough to update
this only once in a while. Most commonly this data changes after changes
made in the UI or after a migration of the VM to another Host.
*Status* = Running
*acpiEnable* = true
*vmType* = kvm
*guestName* = W864GUESTAGENTT
*displayType* = qxl
*guestOs* = Win 8
*kvmEnable* = true #/*this should be constant and never changed*/
*pauseCode* = NOERR
*monitorResponse* = 0
*session* = Locked # unused
*netIfaces* = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': ['10.34.60.148'], 'hw': '00:1a:4a:22:3c:db'}]
*appsList* = ['RHEV-Tools 3.2.4', 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 3.2.2', 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2']
*pid* = 11314
*guestIPs* = 10.34.60.148 # duplicated info
*displayIp* = 0
*displayPort* = 5902
*displaySecurePort* = 5903
*username* = user@W864GUESTAGENTT
*clientIp* =
*lastLogin* = 1361976900.67
Often Changed:
This data is changed quite often however it is not necessary to update
this data every 15 seconds. As this is cumulative data and reflects the
current status, and it does not need to be snapshotted every 15 seconds
to retrieve statistics. The data can be retrieved in much more generous
time slices. (e.g. Every 5 minutes)
*network* = {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': 'vnet1'}}
*disksUsage* = [{'path': 'c:\\', 'total': '64055406592', 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': '3490912256', 'fs': 'UDF', 'used': '3490912256'}]
*timeOffset* = 14422
*elapsedTime* = 68591
*hash* = 2335461227228498964
*statsAge* = 0.09 # unused
Often Changed but unused
This data does not seem to be used in the engine at all. It is *not*
even used in the data warehouse.
*memoryStats* = {'swap_out': '0', 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', 'pageflt': '0', 'mem_total': '2096736', 'mem_unused': '1466884'}
*balloonInfo* = {'balloon_max': 2097152, 'balloon_cur': 2097152}
*disks* = {'vda': {'readLatency': '0', 'apparentsize': '64424509440', 'writeLatency': '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', 'flushLatency': '156549', 'readRate': '0.00', 'truesize': '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': '0', 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}}
Very frequent uppdates needed by webadmin portal:
This data is mostly needed for the webadmin portal and might be required
to be updated quite often. An exception here is the statsAge field,
which seems to be unused by the Engine. This data could be requested
every 15 seconds to keep things as they are now.
*cpuSys* = 2.32
*cpuUser* = 1.34
*memUsage* = 30
Proposed Solution for VDSM & Engine:
We will introduce new optional parameters to getVmStats, getAllVmStats
and list to allow a finer grained specification of data which should be
included.
*Parameter:* *statsType*=/*<string>*/ (getVmStats, getAllVmStats only)
*Allowed values:*
* full (default to keep backwards compatibility)
* app-list (Just send the application list)
* rare (include everything from rarely changed to very frequent)
* often (include everything from often changed to very frequent)
* frequent (only send the very frequently changed items)
*Parameter:* *clientId*=*<string>* The client id is specified by the
client and should be unique however constantly used.
*Parameter:* *diff*=*<boolean>* In combination with the clientId VDSM
will send only differences to the previous request from the named
clientId. (if diff=true)
Additional Change:
Besides the introduction of the new parameters for list, getVmStats and
getAllVmStats it might make sense to include a hash for the appList into
the rarely changed section of the response which would allow to identify
changes and avoid having to sent the complete appList every so often and
only if the hash known to the client is outdated.
*Note:* The appList (Application List) reported by the guest agent could
be fully implemented on request only, as long as the guest agent
installed supports this. As there seems to be a request to have the
complete list of installed applications on all guests this data could be
quite extensive and a huge list. On the other hand this data is only
rarely visible and therefore it should not be requested all the time and
only on demand.
Improvement of the Guest Agent:
As part of the proposed solution it is necessary to improve the guest
agent as well. For the full application list there should be implemented
a caching system which will be fully reactive and should not poll the
application list for example all the time. The guest can create a
prepared data file containing all data in the JSON format (as used for
the communication with VDSM via VIO) and just have to read that file
from disk and directly sends it to VDSM. However it is quite possible
that this list is to big and it might have to be chunked into pieces.
(Multiple messages, which would have to be supported by VDSM then as
well) The solution for this is to make VDSM request this data and it
will retrieve the data necessary on request only.
--
Regards,
Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 11 months
Re: [vdsm] [Users] questions about vdsm supervdsmserver
by ybronhei＠redhat.com
Hey bigclouds,
Supervdsm allows vdsm to run root commands, like mount, dmidecode, lsblk, scan folders that are unprivileged for vdsm user, and more. Due to this method we avoid executing root commands using execv with sudo, that way we don't create subprocess for each operation.
We have to have supervdsm as external deamon, as it runs as different user (root, vdsm runs as user vdsm). Supervdsm deamon doesn't related to libvirt or uses libvirt at all, most of supervdsm functionality is used by vdsm in different flows. you can check supervdsm API in supervdsmServer.py and see where we call it.
We need to have only one instance of supervdsm with a socket file under /var/run/vdsm/ , supervdsm creates this file and vdsm communicate with it.
Due to your netstat output, most of the time you should have 2 or 3 entries
unix 2 [ ACC ] STREAM LISTENING 18895145 /var/run/vdsm/svdsm.sock
unix 2 [ ] STREAM CONNECTED 18895172 /var/run/vdsm/svdsm.sock
unix 3 [ ] STREAM CONNECTED 18895158 /var/run/vdsm/svdsm.sock
(multiprocessing package implementation, you can check there)
might be that other subprocesses or subthreads also hold a request to svdsm.sock at the time you checked,
I don't understand the reason for /var/run/mcvda folder at all.. maybe you changed something in the configuration? is it always appear? what else do you have under this folder?
Normal run shouldn't have more entries as far as I checked.
In addition, I'm working on making supervdsm external service, you can take a look and maybe help me with review :)
[http://gerrit.ovirt.org/#/c/11051/]
Regards,
Yaniv Bronhaim.
----- Original Message -----
> From: "bigclouds" <bigclouds(a)163.com>
> To: users(a)ovirt.org
> Sent: Friday, April 26, 2013 9:59:47 AM
> Subject: [Users] questions about vdsm supervdsmserver
>
> hi,all.
> i have 2 questions about supervdsmserver,
> 1.why it is created separately as a daemon?
> its many function have never been used, and its function can be done by
> calling libvirt directly, why supervdsmserver is need?
> 2.it seems that only one supervdsmserver should be exist, by killing old ones
> to assure that . but look at this, and please explain to me.
> unix 2 [ ACC ] STREAM LISTENING 1339963 4968/python /var/run/vdsm/svdsm.sock
> unix 2 [ ACC ] STREAM LISTENING 384165 39716/python &nb sp;
> /var/run/vdsm/svdsm.sock
> unix 2 [ ACC ] STREAM LISTENING 1100509 49487/python /var/run/vdsm/svdsm.sock
> unix 2 [ ACC ] STREAM LISTENING 1326232 3813/python /var/run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 1448193 4968/python /var/run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 1447937 4968/python /var /run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 1424959 4968/python /var/run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 1414835 4968/python /var/run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 1327873 3813/python /var/run/mcvda/svdsm.sock
> unix 2 [ ] STREAM CONNECTED 1309612 49487/python & nbsp;
> /var/run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 384221 39716/python /var/run/mcvda/svdsm.sock
> thanks
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
10 years, 12 months
Enabling clusterLevels for 3.3 in dsaversion.py
by deepakcs＠linux.vnet.ibm.com
Hi,
I am trying to validate GlusterFS domain engine patches, against
VDSM. GlusterFS domain is enabled for 3.3 only
So when i try to add my VDSM as a new host to engine, it doesn't allow
me to do so since clusterLevels (returned by VDSM as part of engine
calling getCap) doesn't have 3.3
I hacked VDSM's dsaversion.py to return 3.3 as well as part of getCap
and now I am able to add my VDSM host as a new host from engine for DC
of type GLUSTERFS_DOMAIN.
Is this the right way to test a 3.3. feature, if yes, should I send a
vdsm patch to add 3.3 in dsaversion.py ?
If not, then what is the right process to follow here ?
thanx,
deepak
10 years, 12 months
Re: [vdsm] [Engine-devel] Fwd: the procedure of storage-related
by bigclouds
hi,
maybe i do not make you understand me fully. i am reading vdsm code, but it is hard for me to understand StorageDomain,StoragePool. before stoargeD(P) can work, engine must prepare many things.
i want to know the call flow (process) which must be done to make storageS(P) work.
1.for example, what funcitons you should call if make a stoargeDomain work.
poolConnectStorageServer->poolCreate->poolConnect->domainCreate->domainActivate.
thanks
At 2013-04-28 17:40:29,"Vered Volansky" <vered(a)redhat.com> wrote:
>
>
>----- Forwarded Message -----
>> From: "Vered Volansky" <vered(a)redhat.com>
>> To: "bigclouds" <bigclouds(a)163.com>
>> Sent: Sunday, April 28, 2013 12:39:31 PM
>> Subject: Re: [Engine-devel] the procedure of storage-related
>>
>> Hi,
>>
>> Find my answers below.
>>
>> Best Regards,
>> Vered
>>
>> ----- Original Message -----
>> > From: "bigclouds" <bigclouds(a)163.com>
>> > To: "engine-devel" <engine-devel(a)ovirt.org>
>> > Sent: Saturday, April 27, 2013 8:40:56 AM
>> > Subject: [Engine-devel] the procedure of storage-related
>> >
>> > hi,all
>> > 1.i am now not very familar with the right procedure of storage,
>> > please give me a simply introduction of their concept and relation.
>> > help
>> > me out
>> >
>> > StoragePool,StorageDomain
>> > image,volume
>>
>> You should find the following link helpful:
>> http://www.ovirt.org/Vdsm_Storage_Terminology
>>
>> As per your other questions, you might find the following guide helpul:
>> http://www.ovirt.org/Quick_Start_Guide#Configure_Storage
>>
>> Of not, please rephrase them as they're not clear enough and I'd rather not
>> guess.
>>
>>
>> >
>> >
>> > 2.please help me confirm.
>> > i find only one place call mount command, which is
>> > poolConnectStorageServer.
>> > if poolConnectStorageServer is before create and active
>> > StoragePool,StorageDomain?
>> >
>> > 3.if attach is just modify metadata, not anything else?
>> >
>> > 4.sp.py, deactivateSD
>> > if i deactivate ISO storage,it finally umount masterDir, why ?
>> > if masterDir is not mastersd?
>> > thanks
>> >
>> >
>> >
>> > _______________________________________________
>> > Engine-devel mailing list
>> > Engine-devel(a)ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >
>>
>_______________________________________________
>Engine-devel mailing list
>Engine-devel(a)ovirt.org
>http://lists.ovirt.org/mailman/listinfo/engine-devel
10 years, 12 months
Re: [vdsm] [Users] questions about vdsm supervdsmserver
by iheim＠redhat.com
you'll probably get more answers on vdsm-devel (cc'd).
bcc'd users to avoid dupes.
On 04/26/2013 09:59 AM, bigclouds wrote:
> hi,all.
> i have 2 questions about supervdsmserver,
> 1.why it is created separately as a daemon?
> its many function have never been used, and its function can be done
> by calling libvirt directly, why supervdsmserver is need?
> 2.it seems that only one supervdsmserver should be exist, by killing
> old ones to assure that . but look at this, and please explain to me.
> unix 2 [ ACC ] STREAM LISTENING 1339963
> 4968/python /var/run/vdsm/svdsm.sock
> unix 2 [ ACC ] STREAM LISTENING 384165
> 39716/python &nb sp; /var/run/vdsm/svdsm.sock
> unix 2 [ ACC ] STREAM LISTENING 1100509
> 49487/python /var/run/vdsm/svdsm.sock
> unix 2 [ ACC ] STREAM LISTENING 1326232
> 3813/python /var/run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 1448193
> 4968/python /var/run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 1447937
> 4968/python /var /run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 1424959
> 4968/python /var/run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 1414835
> 4968/python /var/run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 1327873
> 3813/python /var/run/mcvda/svdsm.sock
> unix 2 [ ] STREAM CONNECTED 1309612
> 49487/python & nbsp; /var/run/mcvda/svdsm.sock
> unix 3 [ ] STREAM CONNECTED 384221
> 39716/python /var/run/mcvda/svdsm.sock
> thanks
>
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
11 years
Error in network devices report with getVdsCaps
by masayag＠redhat.com
Hi,
Latest vdsm has a regression in network devices reported with getVdsCaps:
In the list below 'vdsmdummy' should be filtered out and 'rhevm' should
have been reported as a network under the bridges element and also as a
network under networks element.
I suspect commit 8febe0e40650983d809abaa10be983bc1953ef1e caused this
issue, but haven't tried a build with a version prior to it to confirm it.
Here is the output of the getVdsCaps, filtered only for the relevant
elements:
bridges = {}
networks = {}
nics = {';vdsmdummy;': {'addr': '',
'cfg': {},
'hwaddr': 'ca:b4:d1:xx:xx:xx',
'ipv6addrs': [],
'mtu': '1500',
'netmask': '',
'speed': 0},
'eth0': {'addr': '',
'cfg': {'BRIDGE': 'rhevm',
'DEVICE': 'eth0',
'HWADDR': '00:26::xx:xx:xx',
'MTU': '1500',
'ONBOOT': 'yes'},
'hwaddr': '00:26:6c:ff:cd:c0',
'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'],
'mtu': '1500',
'netmask': '',
'speed': 1000},
'eth1': {'addr': '',
'cfg': {'BOOTPROTO': 'dhcp',
'DEVICE': 'eth1',
'DHCP_HOSTNAME': 'xxx.xxx.com',
'HWADDR': '00:26:6C:FF:CD:C1',
'IPV6INIT': 'no',
'NM_CONTROLLED': 'yes',
'ONBOOT': 'no',
'TYPE': 'Ethernet',
'USERCTL': 'no',
'UUID':
'09876e54-70c3-4572-a63a-f2c3da6fb0bd'},
'hwaddr': '00:26:6c:xx:xx:xx',
'ipv6addrs': [],
'mtu': '1500',
'netmask': '',
'speed': 0},
'rhevm': {'addr': '10.35.148.48',
'cfg': {'BOOTPROTO': 'dhcp',
'DELAY': '0',
'DEVICE': 'rhevm',
'DHCP_HOSTNAME': 'xxx.xxx.com',
'HOSTNAME': 'xxx.xxx.redhat.com',
'IPV6INIT': 'no',
'MTU': '1500',
'NM_CONTROLLED': 'no',
'ONBOOT': 'yes',
'TYPE': 'Bridge',
'UUID':
'4a1dd6c4-2bba-4825-92c8-7dd9ba29ce67'},
'hwaddr': '00:26:6c:ff:cd:c0',
'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'],
'mtu': '1500',
'netmask': '255.255.252.0',
'speed': 0}}
Thanks,
Moti
11 years
Per device custom properties
by amuller＠redhat.com
Hi all,
Right now we have the ability to define VM-wide properties that may be used by hooks.
It is time we have the same functionality on a device basis:
http://www.ovirt.org/Features/Device_Custom_Properties
For example: If the VM has 2 disks called disk1 and disk2, and two NICs called nic1 and nic2,
and the admin (From the engine) added a custom property qos: 0.5 for nic1
and a custom property defrag: None for disk2. When the VM is started we'll run a hook
for nic1 with its XML and qos: 0.5 added as an environment variable, and a hook for disk2 with its XML and defrag: None.
When a device is hot plugged and it has custom properties we'll run that hook as well.
Implementation-wise, hot plug/unplug for disks and NICs is dead simple - vmCreate is more problematic:
If the user set a custom property called 'qos: 0.8' for nic3, I'd want it exposed as an environment variable called 'qos'
for hot plug nic hooks, but for vmCreate I'd like to prefix the nic's alias.
However, when vmCreate is called we don't have the aliases for NICs and disks.
The proposed solution is to create a new hook point called something like:
'before_device_creation' that will be called before vmCreate.
We'll then call that hook specifically for devices that contains custom properties, as described in the second paragraph of this mail.
I would love to hear smarter ideas before I move forward. Thanks!
11 years
vdsm sync call meeting minutes Monday April 8th 2013
by Dan Kenigsberg
Speaking attendees, in no particular order: Ayal, Yaniv, Saggi, Douglas,
Adam, Dan, Federico, Toni.
Here are the meeting minutes for this week's sync call:
- two small ovirt-3.2 patches are pending
http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:ovirt-3.2,n,z
Federico to consider to take them into the branch.
- Federico to research more into Yuval M and Limor Gavish's nasty failure
http://lists.ovirt.org/pipermail/users/2013-March/013635.html
- Toni: No huge leaps for NetReload during this fortnight.
- There are plenty of nice improvements by Zhou Zhen Sheng. Please help in
reviewing them: http://gerrit.ovirt.org/#/dashboard/1000174
- Two Vdsm developers from IBM Beijing intend to come over to
http://www.ovirt.org/OVirt_Global_Workshops#oVirt_Workshop_at_Intel_Campus
So is /me.
- Saggi is busy writing a Java client for Vdsm.
Needs review for his jsonrpc patches. Will ping Adam about it.
- It's high time to solve https://fedorahosted.org/ovirt/ticket/41
Adam is cool about Jenkis async task, nacking an invalid commit message.
Dan prefers to get any sinner to follow this link
https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=2MTZZR5UUAD...
But nagging ovirt infra about ticket 41 is acceptable.
- Ayal: Backup API, DRBD design work is being done.
- Subteams (mainly infra and storage) to update their list of features in
http://www.ovirt.org/OVirt_3.3_release-management
as the feature freaze is in less than 2 months.
See you,
Dan.
11 years
