April 2013 - vdsm-devel - Fedora mailing-lists

Proposal VDSM <=> Engine Data Statistics Retrieval Optimization
by Vinzenz Feenstra 30 May '13

30 May '13

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

8 23

Snapshots with RAM feature
by ahadas＠redhat.com 16 May '13

16 May '13

Hi All, The proposed feature will make it possible to run a VM which was reverted to live snapshot or created from live snapshot with the same memory state as it was at the moment the live snapshot was taken. http://www.ovirt.org/Features/RAM_Snapshots All feedback is welcome! Regards, Arik

5 8

Re: [vdsm] [Users] questions about vdsm supervdsmserver
by ybronhei＠redhat.com 02 May '13

02 May '13

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 >

2 2

Enabling clusterLevels for 3.3 in dsaversion.py
by deepakcs＠linux.vnet.ibm.com 30 Apr '13

30 Apr '13

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

4 9

Re: [vdsm] [Engine-devel] Fwd: the procedure of storage-related
by bigclouds 29 Apr '13

29 Apr '13

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

3 2

oVirt updates - April 28th, 2013
by iheim＠redhat.com 28 Apr '13

28 Apr '13

I thought a summary of things going on from time to time may interest folks: 1. From the Web * Vagrant support for oVirt/RHEV added http://alturl.com/bkauk https://github.com/pradels/vagrant-ovirt http://www.vagrantup.com/ * How to create and provision an oVirt VM with ansible http://www.youtube.com/watch?v=up8X_clAvZk * ovirt_metrics - ActiveRecord-based gem for reading the oVirt History database http://is.gd/hO94Us * DEMO: oVirt - GlusterFS Native Integration for KVM Virtualization http://www.youtube.com/watch?v=0iIuHCz8L04 * Android x86 running on oVirt http://www.youtube.com/watch?v=5nFZLma_Ofw * using oVirt to build a virtualization platform on an IBM BladeCenter http://www.r11networks.com/2013/04/ovirt-meets-ibm-bladecenter/ http://www.r11networks.com/2013/04/ovirt-installation-guide/ 2. Conferences * René Koch (ovido) presented oVirt in a two conferences in Germany oVirt was covered in two OpenStack summit sessions: * Mike Day, IBM: Connected Communities, Innovative Technologies: OpenStack, oVirt, and KVM http://sched.co/WcehtG * Romil Gupta et al, HP: RHEV-M/oVirt Clusters as compute resources http://sched.co/14hte1T http://www.slideshare.net/romilgupta19/hp-rhevmdriverromil) http://alturl.com/vsn5e 3. Bug/feature/patch of the week? Send your candidates for the next update 4. Upcoming * oVirt Shanghai workshop http://www.ovirt.org/Intel_Workshop_May_2013 Feel free to send comments, items, etc for consideration for the next update. Thanks, Itamar

1 0

Re: [vdsm] [Users] questions about vdsm supervdsmserver
by iheim＠redhat.com 27 Apr '13

27 Apr '13

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 >

1 0

Error in network devices report with getVdsCaps
by masayag＠redhat.com 23 Apr '13

23 Apr '13

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

4 5

Per device custom properties
by amuller＠redhat.com 21 Apr '13

21 Apr '13

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!

6 6

vdsm sync call meeting minutes Monday April 8th 2013
by Dan Kenigsberg 20 Apr '13

20 Apr '13

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=2MTZZR5UUAD5L… 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.

3 3

Adding vdsm_api support for gluster vdsm verbs
by avishwan＠redhat.com 17 Apr '13

17 Apr '13

Hi, We are trying to add json rpc support for vdsm gluster verbs. I submitted a patch to read gluster verbs schema from vdsm/gluster directory. http://gerrit.ovirt.org/#/c/13921/ Let me know if the approach is fine. -- regards Aravinda

2 4

Re: [vdsm] [Users] vdsm unresponsive with python exception
by Dan Kenigsberg 16 Apr '13

16 Apr '13

On Thu, Apr 11, 2013 at 03:51:07PM -0500, Tony Feldmann wrote: > That was the issue. Found out yesterday that vdsm.log was somehow changed > to root:root. Just now got a chance to put it back on the mailing list. > How does the ownership of that file get cahnged. When the issue occurred I > am certain there was no one on the system. http://gerrit.ovirt.org/#/c/12940/ (Separating supervdsm log to supervdsm.log file) solves the issue. unfortunately, only on the master branch of vdsm. I think that this is a nasty issue that has to be backported to the ovirt-3.2 branch as well, and merits to be part of ovirt-3.2.2. Regards, Dan. > > > On Thu, Apr 11, 2013 at 2:15 PM, Joop <jvdwege(a)xs4all.nl> wrote: > > > Dan Kenigsberg wrote: > > > >> On Wed, Apr 10, 2013 at 08:59:01AM -0500, Tony Feldmann wrote: > >> > >> > >>> I am having a strange issue in my ovirt cluster. I have 2 hosts, 1 > >>> running > >>> engine and added as a host and one other system added as a host. Both > >>> systems are running gluster across local disks for shared storage. > >>> Everything was working fine until last night, where my system that is > >>> also > >>> running the engine when unresponsive in the admin page. All vms were > >>> still > >>> running that were on the host. I shut down the vms that were on the host > >>> from within the guest os as I was not able to do anything to the vm with > >>> the host in unresponsive state. After getting the vms off and rebooting > >>> the host, the vdsmd service says that it is running, but it continually > >>> restarts the vdsm process and dumps out these messages: detected > >>> unhandled > >>> Python exception in '/usr/share/vdsm/vdsm'. All services say they are up > >>> and running but the host stays in unresponsive state and the vdsm process > >>> keeps respawning. There is also no data in the vdsm.log. Can anyone > >>> shed > >>> any light on this for me? > >>> > >>> > >> > >> vdsm-devel(a)fedorahosted.org may be a better place to ask vdsm-specific > >> questions. > >> > >> Could you log into the non-operational host as root, and stop the vdsm > >> service. > >> > >> Then become the vdsm user with > >> > >> su -s /bin/bash - vdsm > >> > >> and run /usr/share/vdsm/vdsm manually. Do you see anything in > >> particular? > >> > >> > >> > > Please have a look at the permissions/owner of /var/log/vdsm/vdsm.log. > > Should be vdsm:kvm and not root:root > > > > Joop > > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users

3 3

getVdsStats - no network sessions/statistics
by derez＠redhat.com 15 Apr '13

15 Apr '13

Hi, I've recently updated to latest VDSM code (commit c506391442bc996031aa871a4dfd61368b5a30db). Ever since, whenever I run a VM, my host moves to Non-Operational state (oVirt). * getVdsStats output [1]: doesn't include any network sessions. * Error from oVirt engine log: - "Host '120' moved to Non-Operational state because interface/s 'em1,' are down which needed by network/s 'ovirtmgmt, ' in the current cluster" * Reverting latest commit (http://gerrit.ovirt.org/#/c/13838) seems to solve the issue. Thanks, Daniel [1] vdsClient 0 getVdsStats: cpuIdle = '100.00' cpuSys = '0.00' cpuSysVdsmd = '0.00' cpuUser = '0.00' cpuUserVdsmd = '0.00' dateTime = '2013-04-14T08:27:01 GMT' elapsedTime = '1465' generationID = 'c6c1a126-48d6-44a1-8bd7-80648436a615' ksmCpu = 0 ksmPages = 100 ksmState = False memAvailable = 11064 memCommitted = 577 memShared = 0 momStatus = 'active' netConfigDirty = 'False' rxRate = '0.00' statsAge = '1463.61' storageDomains = {'064a6bef-39f4-4bb4-a811-b8206fa7dd1c': {'code': 0, 'delay': '0.0126550197601', 'lastCheck': '3.9', 'valid': True}, '14a320f9-06c8-41b9-bb53-4fc3dc5717b0': {'code': 0, 'delay': '0.0133948326111', 'lastCheck': '3.9', 'valid': True}, 'd2066c79-a6f9-41e8-8ac8-642f84e415c0': {'code': 0, 'delay': '0.0102300643921', 'lastCheck': '7.2', 'valid': True}} swapFree = 7952 swapTotal = 7983 txRate = '0.00' vmActive = 1 vmCount = 1 vmMigrating = 0

2 1

oVirt history; now in starwars!
by dfediuck＠redhat.com 14 Apr '13

14 Apr '13

Here's a better way to see the project history: Engine http://starlogs.net/#oVirt/ovirt-engine VDSM http://starlogs.net/#oVirt/vdsm

1 0

Fwd: oVirt storage is down and doesn't come up
by Limor Gavish 12 Apr '13

12 Apr '13

Hi, For some reason, without doing anything, all the storage domains became down and restarting VDSM or the entire machine do not bring it up. I am not using lvm The following errors appear several times in vdsm.log (full logs are attached): Thread-22::WARNING::2013-04-12 19:00:08,597::lvm::378::Storage.LVM::(_reloadvgs) lvm vgs failed: 5 [] [' Volume group "1083422e-a5db-41b6-b667-b9ef1ef244f0" not found'] Thread-22::DEBUG::2013-04-12 19:00:08,598::lvm::402::OperationMutex::(_reloadvgs) Operation 'lvm reload operation' released the operation mutex Thread-22::DEBUG::2013-04-12 19:00:08,681::resourceManager::615::ResourceManager::(releaseResource) Trying to release resource 'Storage.5849b030-626e-47cb-ad90-3ce782d831b3' Thread-22::DEBUG::2013-04-12 19:00:08,681::resourceManager::634::ResourceManager::(releaseResource) Released resource 'Storage.5849b030-626e-47cb-ad90-3ce782d831b3' (0 active users) Thread-22::DEBUG::2013-04-12 19:00:08,681::resourceManager::640::ResourceManager::(releaseResource) Resource 'Storage.5849b030-626e-47cb-ad90-3ce782d831b3' is free, finding out if anyone is waiting for it. Thread-22::DEBUG::2013-04-12 19:00:08,682::resourceManager::648::ResourceManager::(releaseResource) No one is waiting for resource 'Storage.5849b030-626e-47cb-ad90-3ce782d831b3', Clearing records. Thread-22::ERROR::2013-04-12 19:00:08,682::task::850::TaskManager.Task::(_setError) Task=`e35a22ac-771a-4916-851f-2fe9d60a0ae6`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 857, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 45, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 939, in connectStoragePool masterVersion, options) File "/usr/share/vdsm/storage/hsm.py", line 986, in _connectStoragePool res = pool.connect(hostID, scsiKey, msdUUID, masterVersion) File "/usr/share/vdsm/storage/sp.py", line 695, in connect self.__rebuild(msdUUID=msdUUID, masterVersion=masterVersion) File "/usr/share/vdsm/storage/sp.py", line 1232, in __rebuild masterVersion=masterVersion) File "/usr/share/vdsm/storage/sp.py", line 1576, in getMasterDomain raise se.StoragePoolMasterNotFound(self.spUUID, msdUUID) StoragePoolMasterNotFound: Cannot find master domain: 'spUUID=5849b030-626e-47cb-ad90-3ce782d831b3, msdUUID=1083422e-a5db-41b6-b667-b9ef1ef244f0' Thread-22::DEBUG::2013-04-12 19:00:08,685::task::869::TaskManager.Task::(_run) Task=`e35a22ac-771a-4916-851f-2fe9d60a0ae6`::Task._run: e35a22ac-771a-4916-851f-2fe9d60a0ae6 ('5849b030-626e-47cb-ad90-3ce782d831b3', 1, '5849b030-626e-47cb-ad90-3ce782d831b3', '1083422e-a5db-41b6-b667-b9ef1ef244f0', 3942) {} failed - stopping task Thread-22::DEBUG::2013-04-12 19:00:08,685::task::1194::TaskManager.Task::(stop) Task=`e35a22ac-771a-4916-851f-2fe9d60a0ae6`::stopping in state preparing (force False) Thread-22::DEBUG::2013-04-12 19:00:08,685::task::974::TaskManager.Task::(_decref) Task=`e35a22ac-771a-4916-851f-2fe9d60a0ae6`::ref 1 aborting True Thread-22::INFO::2013-04-12 19:00:08,686::task::1151::TaskManager.Task::(prepare) Task=`e35a22ac-771a-4916-851f-2fe9d60a0ae6`::aborting: Task is aborted: 'Cannot find master domain' - code 304 *[wil@bufferoverflow ~]$ **sudo vgs --noheadings --units b --nosuffix --separator \| -o uuid,name,attr,size,free,extent_size,extent_count,free_count,tags,vg_mda_size,vg_mda_free * No volume groups found *[wil@bufferoverflow ~]$ **mount* proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) devtmpfs on /dev type devtmpfs (rw,nosuid,size=8131256k,nr_inodes=2032814,mode=755) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) /dev/sda3 on / type ext4 (rw,relatime,data=ordered) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) debugfs on /sys/kernel/debug type debugfs (rw,relatime) sunrpc on /proc/fs/nfsd type nfsd (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) mqueue on /dev/mqueue type mqueue (rw,relatime) tmpfs on /tmp type tmpfs (rw) configfs on /sys/kernel/config type configfs (rw,relatime) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime) /dev/sda5 on /home type ext4 (rw,relatime,data=ordered) /dev/sda1 on /boot type ext4 (rw,relatime,data=ordered) kernelpanic.home:/home/KP_Data_Domain on /rhev/data-center/mnt/kernelpanic.home:_home_KP__Data__Domain type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,mountaddr=10.100.101.100,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=10.100.101.100) bufferoverflow.home:/home/BO_ISO_Domain on /rhev/data-center/mnt/bufferoverflow.home:_home_BO__ISO__Domain type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,mountaddr=10.100.101.108,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=10.100.101.108) *[wil@bufferoverflow ~]$ **sudo find / -name 5849b030-626e-47cb-ad90-3ce782d831b3* /run/vdsm/pools/5849b030-626e-47cb-ad90-3ce782d831b3 *[wil@bufferoverflow ~]$* *sudo find / -name 1083422e-a5db-41b6-b667-b9ef1ef244f0* /home/BO_Ovirt_Storage/1083422e-a5db-41b6-b667-b9ef1ef244f0 I will extremely appreciate any help, Limor Gavish

1 0

AUTO: Yih-Herng Chuang/Seattle/IBM is out of the office, (returning 04/15/2013)
by Yih-Herng Chuang 12 Apr '13

12 Apr '13

I am out of the office until 04/15/2013. For FSM security tech issues, please contact team lead Ronald Long. For others, please contact my manager John Aguiar. I will respond your email when I am back to work. Note: This is an automated response to your message "vdsm-devel Digest, Vol 23, Issue 10" sent on 04/12/2013 6:00:04. This is the only notification you will receive while this person is away.

1 0

Re: [vdsm] [Engine-devel] ovirt-host-deploy and multible bridges
by sabose＠redhat.com 11 Apr '13

11 Apr '13

[Adding vdsm-devel] On 04/09/2013 03:40 PM, Sahina Bose wrote: > Hi all, > > I'm testing the bootstrapping of host without reboot on Fedora 18. After > host's bootstrap, > Ifconfig output returns this: > > ovirtmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 > <snipped> > > virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 > inet 192.168.122.1 netmask 255.255.255.0 broadcast > 192.168.122.255 > <snipped> > > Running*glusterHostsList* vdsm verb, returns the ip address > 192.168.122.1, whereas my host has been added with ip address 10.70.37.219 > > If I reboot the host, the virbr0 bridge is removed, and there's no issue. > > The vdsm verb glusterHostsList - returns ipAddress of host + output of > gluster peer probe. This is needed because a periodic sync job needs > to make sure that the hosts added in engine are in sync with the > gluster cli (hosts could also be added/removed from gluster cli). > > How can we make sure glusterHostsList picks the correct ipAddress? > Reading the inetinfo based on bridge has been vetoed as we are doing > away with bridges. > > It would also work if virbr0 was updated in vds_interfaces table. > Since this is not happening either - we have an issue. > > thanks > sahina > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel

3 10

Re: [vdsm] [Users] vdsm unresponsive with python exception
by Dan Kenigsberg 11 Apr '13

11 Apr '13

On Wed, Apr 10, 2013 at 08:59:01AM -0500, Tony Feldmann wrote: > I am having a strange issue in my ovirt cluster. I have 2 hosts, 1 running > engine and added as a host and one other system added as a host. Both > systems are running gluster across local disks for shared storage. > Everything was working fine until last night, where my system that is also > running the engine when unresponsive in the admin page. All vms were still > running that were on the host. I shut down the vms that were on the host > from within the guest os as I was not able to do anything to the vm with > the host in unresponsive state. After getting the vms off and rebooting > the host, the vdsmd service says that it is running, but it continually > restarts the vdsm process and dumps out these messages: detected unhandled > Python exception in '/usr/share/vdsm/vdsm'. All services say they are up > and running but the host stays in unresponsive state and the vdsm process > keeps respawning. There is also no data in the vdsm.log. Can anyone shed > any light on this for me? vdsm-devel(a)fedorahosted.org may be a better place to ask vdsm-specific questions. Could you log into the non-operational host as root, and stop the vdsm service. Then become the vdsm user with su -s /bin/bash - vdsm and run /usr/share/vdsm/vdsm manually. Do you see anything in particular? Dan.

1 0

RFC: is it possible to configure hosts in cluster to be NTP peers
by David Jaša 09 Apr '13

09 Apr '13

Hi, ovirt still doesn't configure NTP on host installation and relies on administrator not forgetting to set it up correctly, mainly because it is quite hard to configure it correctly automatically. There is one thing IMO that could be configured automatically and that could alleviate situation somewhat: make hosts in the cluster NTP peers so that when clocks go wrong in the cluster for any reason, the error is the same on all hosts in the cluster. The files could be stored in /etc/{ntp,chrony}/vdsm.conf for instance and referenced with includefile or include ..." in /etc/ntp.conf or /etc/chrony.conf respectively. What seems tricky though is that non-Up hosts should be excluded from peer list because there are higher chances that their clocks are not configured properly, so engine (or some host?) should trigger changes to NTP configuration pretty frequently. What do you think about these issues? I don't want to report bugs/RFEs on topic before I'll see your reply. David -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

1 0

How to map the oVirt engine version to VDSM version by git tags?
by shuming＠linux.vnet.ibm.com 08 Apr '13

08 Apr '13

Hi, I am looking for a way to map the oVirt version to VDSM version and engine version by git tags. I can run "git tag -l" under engine git workspace and vdsm git workspace. Here are the output from these two "git tag -l" command. Under oVirt engine workspace: -bash-4.1$ git tag -l ovirt-engine-3.0.0_0001 ovirt-engine-3.1.0 ovirt-engine-3.2.0 ovirt-engine-3.2.1 Under vdsm workspace: -bash-4.1$ git tag -l v4.10.0 v4.10.1 v4.10.2 v4.10.3 v4.9.0 v4.9.1 v4.9.2 v4.9.3 v4.9.3.1 v4.9.3.2 v4.9.3.3 v4.9.4 v4.9.5 v4.9.6 I can checkout the oVirt 3.2.1 snapshot in engine workspace by "git checkout ovirt-engine-3.2.1". But how can I get the VDSM snapshot by the tags in VDSM workspace? How can I know which change-set is for oVirt 3.2.1 in VDSM workspace? -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or shuming(a)linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC

1 0

Seeing gnutls issue when installing libvirt-python dep for VDSM
by deepakcs＠linux.vnet.ibm.com 05 Apr '13

05 Apr '13

Hi All, I am running ./autogen.sh --system and installing the required pkgs as it reports them missing. I installed libvirt and qemu-kvm, which brought in gnutls pkg as a dep. (amongst others). No errors/issues reported by yum duing the above pkgs installs. Then in installed libvirt-pythonm pkg but vdsm autogen still complains of unable to find libvirt pkg. So i tried the below and see this: # python Python 2.7.3 (default, Apr 30 2012, 21:18:11) [GCC 4.7.0 20120416 (Red Hat 4.7.0-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 25, in <module> raise lib_e ImportError: /lib64/libgnutls.so.26: symbol asn1_read_node_value, version LIBTASN1_0_3 not defined in file libtasn1.so.3 with link time reference So looks like some incompatible version of gnutls installed as part of libvirt/qemu-kvm install. *My system details:* # uname -a Linux libSM_upstream 3.3.4-5.fc17.x86_64 #1 SMP Mon May 7 17:29:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # rpm -qa| grep libvirt libvirt-daemon-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-nwfilter-0.9.11.9-1.fc17.x86_64 libvirt-python-0.9.11.9-1.fc17.x86_64 libvirt-0.9.11.9-1.fc17.x86_64 libvirt-client-0.9.11.9-1.fc17.x86_64 libvirt-daemon-config-network-0.9.11.9-1.fc17.x86_64 # rpm -qa| grep gnutls gnutls-devel-2.12.23-1.fc17.x86_64 gnutls-utils-2.12.23-1.fc17.x86_64 gnutls-c++-2.12.23-1.fc17.x86_64 gnutls-2.12.23-1.fc17.x86_64 /etc/fedora-release:Fedora release 17 (Beefy Miracle) /etc/os-release:NAME=Fedora /etc/os-release:ID=fedora /etc/os-release:PRETTY_NAME="Fedora 17 (Beefy Miracle)" /etc/os-release:CPE_NAME="cpe:/o:fedoraproject:fedora:17" /etc/redhat-release:Fedora release 17 (Beefy Miracle) /etc/system-release:Fedora release 17 (Beefy Miracle) checking for pyflakes... /bin/pyflakes checking for pep8... /bin/pep8 checking for python-config... /bin/python-config checking for nosetests... /bin/nosetests checking python module: ethtool... yes *checking python module: libvirt... no** **configure: error: failed to find required module libvirt** *

1 1

Re: [vdsm] Broken dependencies: vdsm
by Dan Kenigsberg 02 Apr '13

02 Apr '13

On Tue, Apr 02, 2013 at 02:57:19PM +0530, Balamurugan Arumugam wrote: > > > On 04/02/2013 12:09 PM, Dan Kenigsberg wrote: > >On Sat, Mar 30, 2013 at 11:42:59AM +0000, buildsys(a)fedoraproject.org wrote: > >> > >> > >>vdsm has broken dependencies in the F-19 tree: > >>On x86_64: > >> vdsm-gluster-4.10.3-12.fc19.noarch requires glusterfs >= 0:3.4.0 > >>On i386: > >> vdsm-gluster-4.10.3-12.fc19.noarch requires glusterfs >= 0:3.4.0 > >>Please resolve this as soon as possible. > > > >Bala, is glusterfs >= 0:3.4.0 expected in Fedora 19? > >If not, Douglas would have to comment-out vdsm-gluster there. > > > > As per Vijay's comment in http://gerrit.ovirt.org/#/c/13339/, I am > not clear about whether he recommends to not to build vdsm-gluster > or decrementing glusterfs dependency version. I will get back to > you asap after discussing with Vijay. This cannot wait much longer - we should not delay Fedora 19. The required glusterfs is not in Fedora 19 beta, vdsm-gluster should not be there too. Douglas, please get this over with a little patch to Fedora's dist-git's vdsm.spec. Dan.

1 0

Re: [vdsm] Broken dependencies: vdsm
by Dan Kenigsberg 02 Apr '13

02 Apr '13

On Sat, Mar 30, 2013 at 11:42:59AM +0000, buildsys(a)fedoraproject.org wrote: > > > vdsm has broken dependencies in the F-19 tree: > On x86_64: > vdsm-gluster-4.10.3-12.fc19.noarch requires glusterfs >= 0:3.4.0 > On i386: > vdsm-gluster-4.10.3-12.fc19.noarch requires glusterfs >= 0:3.4.0 > Please resolve this as soon as possible. Bala, is glusterfs >= 0:3.4.0 expected in Fedora 19? If not, Douglas would have to comment-out vdsm-gluster there. Dan.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

vdsm-devel April 2013