- Users - oVirt List Archives

[Users] VM migration failed on oVirt Node Hypervisor release 2.5.5 (0.1.fc17) : empty cacert.pem
by Kevin Maziere Aubry 24 Jan '13

24 Jan '13

Hi My concern is about ovirt node oVirt Node Hypervisor release 2.5.5 (0.1.fc17), iso downloaded from ovirt. I've installed and connect 4 nodes on a manager, and try to migrate a VM between hypervisors. I always fail with error : libvirtError: operation failed: Failed to connect to remote libvirt URI qemu+tls://172.16.6.3/system where 172.0.0.1 is the IP of a nde. I've check on the node and the port 16514 is open. I also test the virsh command to have a better error message : virsh -c tls://172.16.6.3/system error: Unable to import client certificate /etc/pki/CA/cacert.pem I've checked the cert file on the ovirt node and found it was empty, and that on all nodes install from the Ovirt ISO it is empty I also checked /config/etc/pki/CA/cacert.pem, which is also empty. On a vdsm node install from package on fedora17, it works. ls -al /etc/pki/CA/cacert.pem lrwxrwxrwx. 1 root root 30 18 janv. 14:30 /etc/pki/CA/cacert.pem -> /etc/pki/vdsm/certs/cacert.pem And the cert is good. I've seen no bug report regarding the feature... Kevin -- Kevin Mazière Responsable Infrastructure Alter Way – Hosting 1 rue Royal - 227 Bureaux de la Colline 92213 Saint-Cloud Cedex Tél : +33 (0)1 41 16 38 41 Mob : +33 (0)7 62 55 57 05 http://www.alterway.fr

1 0

Re: [Users] Problems when trying to delete a snapshot
by Eduardo Warszawski 24 Jan '13

24 Jan '13

----- Original Message ----- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > I recovered from this error by import my base-image in a new machine > and make a restore of the backups. > > But is it possible "by hand" to merge latest snapshot in to a > base-image to get a new VM up and running with the old disk image? > Looking at your vdsm logs the snapshot should be intact, then it can be manually restored to the previous state. Please restore the images dirs, removing the "old" and the "orig" dirs you have. You need to change the engine db accordingly too. Later you can retry the merge. Regards. > I have tried with qemu-img but have no go with it. > > Regards //Ricky > > > On 2012-12-30 16:57, Haim Ateya wrote: > > Hi Ricky, > > > > from going over your logs, it seems like create snapshot failed, > > its logged clearly in both engine and vdsm logs [1]. did you try to > > delete this snapshot or was it a different one? if so, not sure its > > worth debugging. > > > > bee7-78e7d1cbc201, vmId=d41b4ebe-3631-4bc1-805c-d762c636ca5a), log > > id: 46d21393 2012-12-13 10:40:24,372 ERROR > > [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] > > (pool-5-thread-50) [12561529] Failed in SnapshotVDS method > > 2012-12-13 10:40:24,372 ERROR > > [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] > > (pool-5-thread-50) [12561529] Error code SNAPSHOT_FAILED and error > > message VDSGenericException: VDSErrorException: Failed to > > SnapshotVDS, error = Snapshot failed 2012-12-13 10:40:24,372 INFO > > [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] > > (pool-5-thread-50) [12561529] Command > > org.ovirt.engine.core.vdsbroker.vdsbroker.SnapshotVDSCommand return > > value Class Name: > > org.ovirt.engine.core.vdsbroker.vdsbroker.StatusOnlyReturnForXmlRpc > > > > > mStatus Class Name: > org.ovirt.engine.core.vdsbroker.vdsbroker.StatusForXmlRpc > > mCode 48 mMessage > > Snapshot failed > > > > > > > > enter/6d91788c-99d9-11e1-b913-78e7d1cbc201/mastersd/master/tasks/21cbcc25-7672-4704-a414-a44f5e9944ed > > temp > > /rhev/data-center/6d91788c-99d9-11e1-b913-78e7d1cbc201/mastersd/maste > > > > > r/tasks/21cbcc25-7672-4704-a414-a44f5e9944ed.temp > > 21cbcc25-7672-4704-a414-a44f5e9944ed::ERROR::2012-12-14 > > 10:48:41,189::volume::492::Storage.Volume::(create) Unexpected > > error Traceback (most recent call last): File > > "/usr/share/vdsm/storage/volume.py", line 475, in create > > srcVolUUID, imgPath, volPath) File > > "/usr/share/vdsm/storage/fileVolume.py", line 138, in _create > > oop.getProcessPool(dom.sdUUID).createSparseFile(volPath, > > sizeBytes) File "/usr/share/vdsm/storage/remoteFileHandler.py", > > line 277, in callCrabRPCFunction *args, **kwargs) File > > "/usr/share/vdsm/storage/remoteFileHandler.py", line 195, in > > callCrabRPCFunction raise err IOError: [Errno 27] File too large > > > > 2012-12-13 10:40:24,372 INFO > > [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] > > (pool-5-thread-50) [12561529] Vds: virthost01 2012-12-13 > > 10:40:24,372 ERROR [org.ovirt.engine.core.vdsbroker.VDSCommandBase] > > (pool-5-thread-50) [12561529] Command SnapshotVDS execution failed. > > Exception: VDSErrorException: VDSGenericException: > > VDSErrorException: Failed to SnapshotVDS, error = Snapshot failed > > 2012-12-13 10:40:24,373 INFO > > [org.ovirt.engine.core.vdsbroker.vdsbroker.SnapshotVDSCommand] > > (pool-5-thread-50) [12561529] FINISH, SnapshotVDSCommand, log id: > > 46d21393 2012-12-13 10:40:24,373 ERROR > > [org.ovirt.engine.core.bll.CreateAllSnapshotsFromVmCommand] > > (pool-5-thread-50) [12561529] Wasnt able to live snpashot due to > > error: VdcBLLException: VdcBLLException: > > org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: > > VDSGenericException: VDSErrorException: Failed to SnapshotVDS, > > error = Snapshot failed, rolling back. 2012-12-13 10:40:24,376 > > ERROR [org.ovirt.engine.core.bll.CreateSnapshotCommand] > > (pool-5-thread-50) [4fd6c4e4] Ending command with failure: > > org.ovirt.engine.core.bll.CreateSnapshotCommand 2012-12-13 1 > > > > 21cbcc25-7672-4704-a414-a44f5e9944ed::ERROR::2012-12-14 > > 10:48:41,196::task::833::TaskManager.Task::(_setError) > > Task=`21cbcc25-7672-4704-a414-a44f5e9944ed`::Unexpected error > > Traceback (most recent call last): File > > "/usr/share/vdsm/storage/task.py", line 840, in _run return > > fn(*args, **kargs) File "/usr/share/vdsm/storage/task.py", line > > 307, in run return self.cmd(*self.argslist, **self.argsdict) File > > "/usr/share/vdsm/storage/securable.py", line 68, in wrapper return > > f(self, *args, **kwargs) File "/usr/share/vdsm/storage/sp.py", line > > 1903, in createVolume srcImgUUID=srcImgUUID, > > srcVolUUID=srcVolUUID) File "/usr/share/vdsm/storage/fileSD.py", > > line 258, in createVolume volUUID, desc, srcImgUUID, srcVolUUID) > > File "/usr/share/vdsm/storage/volume.py", line 494, in create > > (volUUID, e)) VolumeCreationError: Error creating a new volume: > > ('Volume creation 6da02c1e-5ef5-4fab-9ab2-bb081b35e7b3 failed: > > [Errno 27] File too large',) > > > > > > > > ----- Original Message ----- > >> From: "Ricky Schneberger" <ricky(a)schneberger.se> To: "Haim Ateya" > >> <hateya(a)redhat.com> Cc: users(a)ovirt.org Sent: Thursday, December > >> 20, 2012 5:52:10 PM Subject: Re: [Users] Problems when trying to > >> delete a snapshot > >> > > Hi, The task did not finished but it broked my VM. What I have > > right now is a VM with a base-image and a snapshot that I need to > > merge together so I can import the disk in a new VM. > > > > I have attached the logs and even the output from the > > tree-command. > > > > Regards // > > > > Ricky > > > > > > > > On 2012-12-16 08:35, Haim Ateya wrote: > >>>> please attach full engine and vdsm log from SPM machine. > >>>> also, did the task finished ? please run tree command for > >>>> /rhev/data-center/. > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Ricky Schneberger" <ricky(a)schneberger.se> To: > >>>>> users(a)ovirt.org Sent: Friday, December 14, 2012 3:16:58 PM > >>>>> Subject: [Users] Problems when trying to delete a snapshot > >>>>> > >>>> I was trying to delete a snapshot from one of my VM and > >>>> everything started fine. > >>>> > >>>> The disk image is a thin provisioned 100GB disk with 8GB > >>>> data. I just hade one snapshot and it was that one I started > >>>> to delete. After more than two hours I look in the folder > >>>> with that VMs disk images and found out that there was i new > >>>> created file with a size of around 650GB and it was still > >>>> growing. > >>>> > >>>> -rw-rw----. 1 vdsm kvm 8789950464 14 dec 12.23 > >>>> 8ede8e53-1323-442b-84f2-3c94114c64cf -rw-r--r--. 1 vdsm kvm > >>>> 681499951104 14 dec 14.10 > >>>> 8ede8e53-1323-442b-84f2-3c94114c64cf_MERGE -rw-r--r--. 1 vdsm > >>>> kvm 272 14 dec 12.24 > >>>> 8ede8e53-1323-442b-84f2-3c94114c64cf.meta -rw-rw----. 1 vdsm > >>>> kvm 107382439936 6 jun 2012 > >>>> b4a43421-728b-4204-a389-607221d945b7 -rw-r--r--. 1 vdsm kvm > >>>> 282 14 dec 12.24 b4a43421-728b-4204-a389-607221d945b7.meta > >>>> > >>>> Any idea what is happening? > >>>> > >>>> Regards > >>>>> > >>>>> _______________________________________________ Users > >>>>> mailing list Users(a)ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>> > >> > > - -- > Ricky Schneberger > > - ------------------------------------ > "Not using free exhaust energy to help your engine breathe is > downright > criminal" > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlDhjYYACgkQOap81biMC2NY1gCdHeTHy92dFzMMhwKA360OSauW > KMIAn1rClC+ZWRgukQJaeCY0g3APw4to > =G4Bl > -----END PGP SIGNATURE----- > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >

1 0

[Users] Installing a lab setup from scratch using F18
by Joop 24 Jan '13

24 Jan '13

As promised on IRC (jvandewege) I'll post my findings of setting up an ovirt lab environment from scratch using F18. First some background: - 2 hosts for testing storage cluster with replicated gluster data and iso domains (HP ML110 G5) - 2 hosts for VMs (HP DL360 G5?) - 1 managment server (HP ML110 G5) All physical servers have atleast 1Gb connection and they also have 2 10Gb ethernet ports connected to two Arista switches. Complete setup (except for the managment srv) is redundant. Using F18-x64 DVD and using minimal server with extra tools, after install the ovirt.repo and the beta gluster repo is activated. This serves as a proof of concept for a bigger setup. Problems sofar: - looks like F18 uses a different path to access video since using the defaults leads to garbled video, need to use nomodeset as a kernel option - upgrading the minimal install (yum upgrade) gives me kernel-3.7.2-204 and the boot process halts with soft locks on different cpus, reverting to 3.6.10-4.fc18.x86_64 fixes that. Managment is using 3.7.2 kernel without problems BUT it doesn't use libvirt/qemu-kvm/vdsm, my guess its related. - need to disable NetworkManager and enable network (and ifcfg-xxx) to get network going - adding the storage hosts from de webui works but after reboot vdsm is not starting, reason seems to be that network isn't initialised until after all interfaces are done with their dhcp requests. There are 4 interfaces which use dhcp, setting those to bootprotocol=none seems the help. - during deploy their is a warning about 'cannot set tuned profile', seems harmless but hadn't seen that one until now. - the deployment script discovers during deployment that the ID of the second storage server is identical to the first one and abort the deployment (Blame HP!) shouldn't it generate a unique one using uuidgen?? Things that are OK sofar: - ovirt-engine setup (no problems with postgresql) - creating/activating gluster volumes (no more deadlocks) Adding virt hosts has to wait til tomorrow, got problems getting the dvd iso onto an usb stick, will probably burn a DVD to keep going. Joop

3 2

[Users] cannot add gluster domain
by T-Sinjon 23 Jan '13

23 Jan '13

HI, everyone: Recently , I newly installed ovirt 3.1 from http://resources.ovirt.org/releases/stable/rpm/Fedora/17/noarch/, and node use http://resources.ovirt.org/releases/stable/tools/ovirt-node-iso-2.5.5-0.1.f… when i add gluster domain via nfs, mount error occurred, I have do manually mount action on the node but failed if without -o nolock option: # /usr/bin/mount -t nfs -o soft,nosharecache,timeo=600,retrans=6 my-gluster-ip:/gvol02/GlusterDomain /rhev/data-center/mnt/my-gluster-ip:_gvol02_GlusterDomain mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. mount.nfs: an incorrect mount option was specified blow is the vdsm.log from node and engine.log, any help was appreciated : vdsm.log Thread-12717::DEBUG::2013-01-22 09:19:02,261::BindingXMLRPC::156::vds::(wrapper) [my-engine-ip] Thread-12717::DEBUG::2013-01-22 09:19:02,261::task::588::TaskManager.Task::(_updateState) Task=`e1d331c6-e191-415f-bc1b-e5047d447494`::moving from state init -> state preparing Thread-12717::INFO::2013-01-22 09:19:02,262::logUtils::37::dispatcher::(wrapper) Run and protect: validateStorageServerConnection(domType=1, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'my-gluster-ip:/gvol02/GlusterDomain', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=None) Thread-12717::INFO::2013-01-22 09:19:02,262::logUtils::39::dispatcher::(wrapper) Run and protect: validateStorageServerConnection, Return response: {'statuslist': [{'status': 0, 'id': '00000000-0000-0000-0000-000000000000'}]} Thread-12717::DEBUG::2013-01-22 09:19:02,262::task::1172::TaskManager.Task::(prepare) Task=`e1d331c6-e191-415f-bc1b-e5047d447494`::finished: {'statuslist': [{'status': 0, 'id': '00000000-0000-0000-0000-000000000000'}]} Thread-12717::DEBUG::2013-01-22 09:19:02,262::task::588::TaskManager.Task::(_updateState) Task=`e1d331c6-e191-415f-bc1b-e5047d447494`::moving from state preparing -> state finished Thread-12717::DEBUG::2013-01-22 09:19:02,262::resourceManager::809::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-12717::DEBUG::2013-01-22 09:19:02,262::resourceManager::844::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-12717::DEBUG::2013-01-22 09:19:02,263::task::978::TaskManager.Task::(_decref) Task=`e1d331c6-e191-415f-bc1b-e5047d447494`::ref 0 aborting False Thread-12718::DEBUG::2013-01-22 09:19:02,307::BindingXMLRPC::156::vds::(wrapper) [my-engine-ip] Thread-12718::DEBUG::2013-01-22 09:19:02,307::task::588::TaskManager.Task::(_updateState) Task=`c07a075a-a910-4bc3-9a33-b957d05ea270`::moving from state init -> state preparing Thread-12718::INFO::2013-01-22 09:19:02,307::logUtils::37::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=1, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'my-gluster-ip:/gvol02/GlusterDomain', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '6463ca53-6c57-45f6-bb5c-45505891cae9', 'port': ''}], options=None) Thread-12718::DEBUG::2013-01-22 09:19:02,467::__init__::1249::Storage.Misc.excCmd::(_log) '/usr/bin/sudo -n /usr/bin/mount -t nfs -o soft,nosharecache,timeo=600,retrans=6 my-gluster-ip:/gvol02/GlusterDomain /rhev/data-center/mnt/my-gluster-ip:_gvol02_GlusterDomain' (cwd None) Thread-12718::ERROR::2013-01-22 09:19:02,486::hsm::1932::Storage.HSM::(connectStorageServer) Could not connect to storageServer Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 1929, in connectStorageServer File "/usr/share/vdsm/storage/storageServer.py", line 256, in connect File "/usr/share/vdsm/storage/storageServer.py", line 179, in connect File "/usr/share/vdsm/storage/mount.py", line 190, in mount File "/usr/share/vdsm/storage/mount.py", line 206, in _runcmd MountError: (32, ";mount.nfs: rpc.statd is not running but is required for remote locking.\nmount.nfs: Either use '-o nolock' to keep locks local, or start statd.\nmount.nfs: an incorrect mount option was specified\n") engine.log: 2013-01-22 17:19:20,073 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ValidateStorageServerConnectionVDSCommand] (ajp--0.0.0.0-8009-7) [25932203] START, ValidateStorageServerConnectionVDSCommand(vdsId = 626e37f4-5ee3-11e2-96fa-0030487c133e, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: null, connection: my-gluster-ip:/gvol02/GlusterDomain };]), log id: 303f4753 2013-01-22 17:19:20,095 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ValidateStorageServerConnectionVDSCommand] (ajp--0.0.0.0-8009-7) [25932203] FINISH, ValidateStorageServerConnectionVDSCommand, return: {00000000-0000-0000-0000-000000000000=0}, log id: 303f4753 2013-01-22 17:19:20,115 INFO [org.ovirt.engine.core.bll.storage.AddStorageServerConnectionCommand] (ajp--0.0.0.0-8009-7) [25932203] Running command: AddStorageServerConnectionCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: System 2013-01-22 17:19:20,117 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--0.0.0.0-8009-7) [25932203] START, ConnectStorageServerVDSCommand(vdsId = 626e37f4-5ee3-11e2-96fa-0030487c133e, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: 6463ca53-6c57-45f6-bb5c-45505891cae9, connection: my-gluster-ip:/gvol02/GlusterDomain };]), log id: 198f3eb4 2013-01-22 17:19:20,323 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--0.0.0.0-8009-7) [25932203] FINISH, ConnectStorageServerVDSCommand, return: {6463ca53-6c57-45f6-bb5c-45505891cae9=477}, log id: 198f3eb4 2013-01-22 17:19:20,325 ERROR [org.ovirt.engine.core.bll.storage.NFSStorageHelper] (ajp--0.0.0.0-8009-7) [25932203] The connection with details my-gluster-ip:/gvol02/GlusterDomain failed because of error code 477 and error message is: 477 2013-01-22 17:19:20,415 INFO [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--0.0.0.0-8009-6) [6641b9e1] Running command: AddNFSStorageDomainCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: System 2013-01-22 17:19:20,425 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--0.0.0.0-8009-6) [6641b9e1] START, CreateStorageDomainVDSCommand(vdsId = 626e37f4-5ee3-11e2-96fa-0030487c133e, storageDomain=org.ovirt.engine.core.common.businessentities.storage_domain_static@8e25c6bc, args=my-gluster-ip:/gvol02/GlusterDomain), log id: 675539c4 2013-01-22 17:19:21,064 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] (ajp--0.0.0.0-8009-6) [6641b9e1] Failed in CreateStorageDomainVDS method 2013-01-22 17:19:21,065 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] (ajp--0.0.0.0-8009-6) [6641b9e1] Error code StorageDomainFSNotMounted and error message VDSGenericException: VDSErrorException: Failed to CreateStorageDomainVDS, error = Storage domain remote path not mounted: ('/rhev/data-center/mnt/my-gluster-ip:_gvol02_GlusterDomain',) 2013-01-22 17:19:21,066 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] (ajp--0.0.0.0-8009-6) [6641b9e1] Command org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand return value Class Name: org.ovirt.engine.core.vdsbroker.vdsbroker.StatusOnlyReturnForXmlRpc mStatus Class Name: org.ovirt.engine.core.vdsbroker.vdsbroker.StatusForXmlRpc mCode 360 mMessage Storage domain remote path not mounted: ('/rhev/data-center/mnt/my-gluster-ip:_gvol02_GlusterDomain',)

2 2

[Users] KVM version not showing in Ovirt Manager
by Tom Brown 23 Jan '13

23 Jan '13

Hi I have just added another HV to a cluster and its up and running fine. I can run VM's on it and migrate fro other HV's onto it. I do note however that in the manager there is no KVM version listed as installed however on other HV's in the cluster there is a version present. I see that the KVM version is slightly different on this new host but as i said apart from this visual issue everything appear to be running fine. These HV's are CentOS 6.3 using dreyou 3.1 Node where KVM version not showing in the manager node003 ~]# rpm -qa | grep kvm qemu-kvm-rhev-0.12.1.2-2.295.el6.10.x86_64 qemu-kvm-rhev-tools-0.12.1.2-2.295.el6.10.x86_64 Node where KVM version is showing in the manager node002 ~]# rpm -qa | grep kvm qemu-kvm-tools-0.12.1.2-2.295.el6_3.8.x86_64 qemu-kvm-0.12.1.2-2.295.el6_3.8.x86_64 thanks

5 14

[Users] Encrypted Admin password error
by Dead Horse 23 Jan '13

23 Jan '13

This error appears very frequently in the engine.log. 2013-01-22 15:33:10,837 ERROR [org.ovirt.engine.core.engineencryptutils.EncryptionUtils] (MSC service thread 1-5) Failed to decrypt Data must start with zero 2013-01-22 15:33:10,838 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-5) Failed to decrypt value for property TruststorePass will be used encrypted value 2013-01-22 15:33:10,865 ERROR [org.ovirt.engine.core.engineencryptutils.EncryptionUtils] (MSC service thread 1-5) Failed to decrypt Data must start with zero 2013-01-22 15:33:10,866 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-5) Failed to decrypt value for property AdminPassword will be used encrypted value Starting appearing after manual edit to the "AdminPassword" value in the database. Tried using engine-config -s AdminPassword='somepassword' to change it which always resulted in: cannot set value 'somepassword' to key AdminPassword. Hence the manual edit Any ideas on how to make the engine happy in that regard again? - DHC

2 2

[Users] oVirt Weekly Meeting -- 2013-01-23
by Mike Burns 23 Jan '13

23 Jan '13

Minutes: http://ovirt.org/meetings/ovirt/2013/ovirt.2013-01-23-15.00.html Minutes (text): http://ovirt.org/meetings/ovirt/2013/ovirt.2013-01-23-15.00.txt Log: http://ovirt.org/meetings/ovirt/2013/ovirt.2013-01-23-15.00.log.html ============================ #ovirt: oVirt Weekly Meeting ============================ Meeting started by mburns_ovirt_ws at 15:00:57 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2013/ovirt.2013-01-23-15.00.log.html . Meeting summary --------------- * agenda and roll call (mburns_ovirt_ws, 15:01:05) * Release status (mburns, 15:04:10) * vdsm and engine rpms are posted to ovirt-beta repo (mburns, 15:04:23) * testing is ongoing with ovirt-node (mburns, 15:04:43) * hope to have ovirt-node packages and image uploaded and beta announcement sent today (mburns, 15:05:10) * workshops (dneary, 15:08:24) * Sunnyvale workshop on now. 90 registered, ~70 attendees for day 1 (dneary, 15:08:51) * Dates for Shanghai workshop in Intel's campus there have been pushed back (dneary, 15:09:29) * Shanghai workshop will now happen on May 8-9, 2013 (dneary, 15:09:49) * Call for participation and registration for that workshop will go online next week (dneary, 15:10:38) * oVirt Board meeting during the NetApp workshop is planned for tomorrow, Thursday 24 Jan. Remote attendance is possible - please contact dneary(a)redhat.com or lhawthor(a)redhat.com to attend remotely (dneary, 15:13:33) * Board meeting starts at 09:00 AM PST, 17:00 UTC (mburns, 15:16:38) * Infra update (quick) (mburns, 15:17:15) * <quaid> we've got *both* sets of servers & I'll be distributing access to the Infra maintainers later today so work can continue in my absence (mburns, 15:17:38) * Release Status (continued) (mburns, 15:18:02) * Q from aglitke -- will we have a 3.2 ovirt on a stick? (mburns, 15:18:33) * A - yes, it's already in use at the workshop right now (mburns, 15:18:48) * next step is to get it into a jenkins build to build it daily (mburns, 15:19:07) * question from linex about upgrades -- will it be a simple package update to go from 3.1 to 3.2? (mburns, 15:19:34) * answer -- no, 3.1 runs on F17 and 3.2 on F18, so there is an OS upgrade involved as well as running engine-upgrade (mburns, 15:20:17) * upgrade from 3.2 beta to 3.2 GA *should* be more smooth (mburns, 15:20:57) * Proposal -- since we don't have beta ready yet, slip test day from 24-Jan to 29-Jan and GA from 30-Jan to 06-Feb (mburns, 15:24:12) * question -- release note status (mburns, 15:25:16) * sgordon and cheryn tan are coordinating (mburns, 15:25:29) * maintainers need to be responsive is asked for info from them if we hope to have them available on time (mburns, 15:25:48) * should have a draft ready for the 29th (mburns, 15:26:13) * AGREED: release date to slip 1 week to 06-Feb and test day to 29-Jan (mburns, 15:27:40) * Other Topics (mburns, 15:29:40) Meeting ended at 15:32:24 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mburns (60) * dneary (20) * aglitke (19) * mburns_ovirt_ws (7) * sgordon (5) * linex (5) * ovirtbot (4) * Rydekull (2) * quaid (1) * dustins (1) * oschreib (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

[Users] Attaching floppy to guest
by Gianluca Cecchi 23 Jan '13

23 Jan '13

Hello, if I want to attach a floppy image to a guest, can I only do via run once when it is powered off or can I attach it to a running guest too? In my case I have a winxp guest running and I only see Change CD as an option... Thanks, Gianluca

2 2

[Users] Guests are paused without error message while doing maintenance on NFS storage
by Karli Sjöberg 23 Jan '13

23 Jan '13

--_000_5F9E965F5A80BC468BE5F40576769F091023A18Bexchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCnRoaXMgaXMgYSBiaXQgY29tcGxleCBpc3N1ZSwgc28gScK0bCB0cnkgYW5kIGJlIGFz IGNsZWFyIGFzIHBvc3NpYmxlLiBXZSBhcmUgcnVubmluZyBvVmlydC0zLjEgaW4gb3VyIHByb2R1 Y3Rpb24gZW52aXJvbm1lbnQsIGJhc2VkIG9uIG1pbmltYWwgRmVkb3JhIDE3IGluc3RhbGxzLiBX ZSBoYXZlIDR4SFAgMzgwJ3MgKEludGVsKSBydW5uaW5nIGluIG9uZSBjbHVzdGVyLCBhbmQgMnhT dW4gNzMxMCdzIChBTUQpIGluIGFub3RoZXIgY2x1c3Rlci4gVGhleSBoYXZlIHNoYXJlZCBzdG9y YWdlIG92ZXIgTkZTIHRvIGEgRnJlZUJTRC1iYXNlZCBzeXN0ZW0gdGhhdCB1c2VzIFpGUyBhcyBh IGZpbGVzeXN0ZW0uIFRoZSBzdG9yYWdlIGJvb3RzIG9mZiBvZiBhIG1pcnJvcmVkIFpGUyBwb29s IG1hZGUgdXAgb2YgdHdvIFVTQidzIHRoYXQgb25seSBob3VzZXMgLywgd2hpbGUgL3ZhciwgL3Vz ciwgZXRjLiBsaWVzIG9uIGEgc2VwYXJhdGUgWkZTIHBvb2wgbWFkZSB1cCBvZiB0aGUgcmVzdCBv ZiB0aGUgSEREJ3MgaW4gdGhlIHN5c3RlbS4gSXQgbG9va3MgbGlrZSB0aGlzOg0KDQpGUyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTU9VTlRQT0lOVA0KcG9vbDEg KFRoZSBtaXJyb3JlZCBVU0IncykgICAgbm9uZQ0KcG9vbDEvcm9vdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAvIChtb3VudGVkIHJvKQ0KcG9vbDIgKFRoZSByZWd1bGFyIEhERCdzKSAg ICAgbm9uZQ0KcG9vbDIvcm9vdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub25lDQpw b29sMi9yb290L3VzciAgICAgICAgICAgICAgICAgICAgICAgIC91c3INCnBvb2wyL3Jvb3QvdXNy L2hvbWUgICAgICAgICAgICAgIC91c3IvaG9tZQ0KcG9vbDIvcm9vdC91c3IvbG9jYWwgICAgICAg ICAgICAgICAvdXNyL2xvY2FsDQpwb29sMi9yb290L3ZhciAgICAgICAgICAgICAgICAgICAgICAg IC92YXINCnRtcGZzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL3RtcA0K cG9vbDIvZXhwb3J0ICAgICAgICAgICAgICAgICAgICAgICAgICAvZXhwb3J0DQpwb29sMi9leHBv cnQvZHMxICAgICAgICAgICAgICAgICAgIC9leHBvcnQvZHMxDQpwb29sMi9leHBvcnQvZHMxL2Rh dGEgICAgICAgICAgIC9leHBvcnQvZHMxL2RhdGENCnBvb2wyL2V4cG9ydC9kczEvZXhwb3J0ICAg ICAgIC9leHBvcnQvZHMxL2V4cG9ydA0KcG9vbDIvZXhwb3J0L2RzMS9pc28gICAgICAgICAgICAg L2V4cG9ydC9kczEvaXNvDQpwb29sMi9leHBvcnQvZHMyICAgICAgICAgICAgICAgICAgIC9leHBv cnQvZHMyDQpwb29sMi9leHBvcnQvZHMyL2RhdGEgICAgICAgICAgIC9leHBvcnQvZHMyL2RhdGEN Cg0KL2V0Yy9leHBvcnRzOg0KL2V4cG9ydC9kczEvZGF0YSAgICAgLWFsbGRpcnMgLW1hcHJvb3Q9 cm9vdCAxMC4wLjAuKGFsbCBvZiB0aGUgSFYncykNCi9leHBvcnQvZHMxL2V4cG9ydCAtYWxsZGly cyAtbWFwcm9vdD1yb290IDEwLjAuMC4oYWxsIG9mIHRoZSBIVidzKQ0KL2V4cG9ydC9kczEvaXNv ICAgICAgICAtYWxsZGlycyAtbWFwcm9vdD1yb290IDEwLjAuMC4oYWxsIG9mIHRoZSBIVidzKQ0K L2V4cG9ydC9kczIvZGF0YSAgICAgLWFsbGRpcnMgLW1hcHJvb3Q9cm9vdCAxMC4wLjAuKGFsbCBv ZiB0aGUgSFYncykNCg0KVG8gbWFrZSB0aG9zZSBVU0IncyBsYXN0IGZvciBhcyBsb25nIGFzIHBv c3NpYmxlLCAvIGlzIHVzdWFsbHkgbW91bnRlZCByZWFkLW9ubHkuIEFuZCB3aGVuIHlvdSBuZWVk IHRvIGNoYW5nZSBhbnl0aGluZywgeW91IG5lZWQgdG8gcmVtb3VudCAvIHRvIHJlYWQtd3JpdGUs IGRvIHRoZSBtYWludGVuYW5jZSwgYW5kIHRoZW4gcmVtb3VudCBiYWNrIHRvIHJlYWQtb25seSBh Z2Fpbi4gQnV0IHdoZW4geW91IGlzc3VlIGEgbW91bnQgY29tbWFuZCwgdGhlIFZNJ3MgaW4gb1Zp cnQgcGF1c2UuIEF0IGZpcnN0IHdlIGRpZG7CtHQgdW5kZXJzdGFuZCB0aGF0IHdhcyBhY3R1YWxs eSB0aGUgY2F1c2UgYW5kIHRyaWVkIHRvIGNvcnJlbGF0ZSB0aGUgc2VlbWluZ2x5IHNwb250YW5l b3VzIHBhdXNpbmcgdG8ganVzdCBhYm91dCBhbnl0aGluZywgVGhlbiBJIHdhcyBsb2dnZWQgaW4g dG8gYm90aCBvVmlydCdzIHdlYmFkbWluLCBhbmQgdGhlIHN0b3JhZ2UgYXQgdGhlIHNhbWUgYW5k IGlzc3VlZCAibW91bnQgLXV3IC8iLCBhbmQgKmJvb20qLCByYW5kb20gVk0ncyBzdGFydGVkIHRv IHBhdXNlOikgTm90IGFsbCBvZiB0aGVtIHRob3VnaCwgYW5kIG5vdCBqdXN0IGV2ZXJ5IG9uZSBp biBlaXRoZXIgY2x1c3RlciBvciBzb21ldGhpbmcsIGl0IGlzIGNvbXBsZXRlbHkgcmFuZG9tIHdo aWNoIFZNJ3MgYXJlIHBhdXNlZCBldmVyeSB0aW1lLg0KDQojIHRpbWUgbW91bnQgLXVyIC8NCg0K cmVhbCAwbTIuMTk4cw0KdXNlciAwbTAuMDAwcw0Kc3lzIDBtMC4wMDJzDQoNCkFuZCBoZXJlwrRz IHdoYXQgdmRzbSBvbiBvbmUgb2YgdGhlIEhWJ3MgdGhvdWdodCBhYm91dCB0aGF0Og0KaHR0cDov L3Bhc3RlYmluLmNvbS9NWGpncERmVQ0KDQpJdCBiZWdpbnMgd2l0aCBhbGwgVk0ncyBiZWluZyAi VXAiLCB0aGVuIG1lIGlzc3VpbmcgdGhlIHJlbW91bnQgb24gdGhlIHN0b3JhZ2UgZnJvbSByZWFk LXdyaXRlIHRvIHJlYWQtb25seSB3aGljaCB0b29rIDIgc2VjcyB0byBjb21wbGV0ZSwgdmRzbSBm cmVha2luZyBvdXQgd2hlbiBpdCBzaG9ydGx5IGxvb3NlcyBpdMK0cyBjb25uZWN0aW9ucyBhbmQg bGFzdGx5IG1lIGF0IDE0OjM0IG1ha2luZyB0aGVtIGFsbCBydW4gYWdhaW4gZnJvbSB3ZWJhZG1p bi4NCg0KVHdvIHRoaW5nczoNCjEpIERvZXMgYW55b25lIGtub3cgb2YgYW55IGltcHJvdmVtZW50 cyB0aGF0IGNvdWxkIGJlIG1hZGUgb24gdGhlIHN0b3JhZ2Ugc2lkZSwgYXBhcnQgZnJvbSB0aGUg b2J2aW91cyAic3RvcCByZW1vdW50aW5nIiwgc2luY2UgcGF0Y2hpbmcgbXVzdCBldmVudHVhbGx5 IGJlIG1hZGUsIGNvbmZpZ3VyYXRpb25zIGNoYW5nZWQsIGFuZCBzbyBvbi4gQSBzbWFydGVyIHdh eSBvZiBjb25maWd1cmluZyBzb21ldGhpbmc/IEJvb3RpbmcgZnJvbSBhbm90aGVyIG9yZGluYXJ5 IEhERCBpcyBzYWRseSBvdXQgb2YgdGhlIHF1ZXN0aW9uIGJlY2F1c2UgdGhlcmUgaXNuwrR0IGFu eSByb29tIGZvciBhbnkgbW9yZSwgaXTCtHMgZnVsbC4gQW5kIEkgd291bGQgaGF2ZSByZWFsbHkg bGlrZSBpdCByYXRoZXIgdG8gYm9vdCBmcm9tIHRoZSBIREQncyB0aGF0IGFyZSBhbHJlYWR5IGlu IHRoZXJlLCBidXQgdGhlcmUgYXJlICJvdGhlciB0aGluZ3MiIHByZXZlbnRpbmcgdGhhdC4NCjIp IE5vdGhpbmcgaW4gZW5naW5lIHdhcyBsb2dnZWQgYWJvdXQgaXQsIG5vICJFdmVudHMiIHdlcmUg bWFkZSBhbmQgbm90aGluZyBpbiBlbmdpbmUubG9nIHRoYXQgY291bGQgaW5kaWNhdGUgc29tZXRo aW5nIGhhZCBnb25lIHdyb25nIGF0IGFsbC4gSWYgaXQgd2FzbsK0dCBzZXJpb3VzIGVub3VnaCB0 byBpc3N1ZSBhIHdhcm5pbmcsIHdoeSBkaXNydXB0IHRoZSBzZXJ2aWNlIHdpdGggcGF1c2luZyB0 aGUgbWFjaGluZXM/IE9yIGF0IGxlYXN0IGF1dG9tYXRpY2FsbHkgc3RhcnQgdGhlbSBiYWNrIHVw IHdoZW4gY29ubmVjdGlvbiB0byB0aGUgc3RvcmFnZSBhbG1vc3QgaW1tZWRpYXRlbHkgY2FtZSBi YWNrIG9uIGl0wrRzIG93bi4gU2F5aW5nIG5vdGhpbmcgbWFkZSBpdCByZWFsbHkgaGFyZCB0byB0 cm91Ymxlc2hvb3QsIHNpbmNlIHdlIGRpZG7CtHQgaW5pdGlhbGx5IGtuZXcgYXQgYWxsIHdoYXQg Y291bGQgYmUgY2F1c2luZyB0aGUgcGF1c2VzIHRvIGhhcHBlbiwgYW5kIHdoZW4uDQoNCkJlc3Qg UmVnYXJkcw0KL0thcmxpIFNqw7ZiZXJnDQo= --_000_5F9E965F5A80BC468BE5F40576769F091023A18Bexchange21_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii IGNvbnRlbnQ9Ikd0a0hUTUwvNC40LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQpIaSw8YnI+DQo8YnI+ DQp0aGlzIGlzIGEgYml0IGNvbXBsZXggaXNzdWUsIHNvIEnCtGwgdHJ5IGFuZCBiZSBhcyBjbGVh ciBhcyBwb3NzaWJsZS4gV2UgYXJlIHJ1bm5pbmcgb1ZpcnQtMy4xIGluIG91ciBwcm9kdWN0aW9u IGVudmlyb25tZW50LCBiYXNlZCBvbiBtaW5pbWFsIEZlZG9yYSAxNyBpbnN0YWxscy4gV2UgaGF2 ZSA0eEhQIDM4MCdzIChJbnRlbCkgcnVubmluZyBpbiBvbmUgY2x1c3RlciwgYW5kIDJ4U3VuIDcz MTAncyAoQU1EKSBpbiBhbm90aGVyIGNsdXN0ZXIuIFRoZXkNCiBoYXZlIHNoYXJlZCBzdG9yYWdl IG92ZXIgTkZTIHRvIGEgRnJlZUJTRC1iYXNlZCBzeXN0ZW0gdGhhdCB1c2VzIFpGUyBhcyBhIGZp bGVzeXN0ZW0uIFRoZSBzdG9yYWdlIGJvb3RzIG9mZiBvZiBhIG1pcnJvcmVkIFpGUyBwb29sIG1h ZGUgdXAgb2YgdHdvIFVTQidzIHRoYXQgb25seSBob3VzZXMgLywgd2hpbGUgL3ZhciwgL3Vzciwg ZXRjLiBsaWVzIG9uIGEgc2VwYXJhdGUgWkZTIHBvb2wgbWFkZSB1cCBvZiB0aGUgcmVzdCBvZiB0 aGUgSEREJ3MNCiBpbiB0aGUgc3lzdGVtLiBJdCBsb29rcyBsaWtlIHRoaXM6PGJyPg0KPGJyPg0K RlMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTU9VTlRQT0lOVDxicj4NCnBvb2wxIChU aGUgbWlycm9yZWQgVVNCJ3MpJm5ic3A7Jm5ic3A7Jm5ic3A7IG5vbmU8YnI+DQpwb29sMS9yb290 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC8gKG1vdW50ZWQgcm8pPGJyPg0KcG9vbDIgKFRoZSByZWd1bGFyIEhERCdzKSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub25lPGJyPg0KcG9vbDIvcm9vdCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub25l PGJyPg0KcG9vbDIvcm9vdC91c3ImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL3Vzcjxicj4NCnBv b2wyL3Jvb3QvdXNyL2hvbWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL3Vzci9ob21lPGJyPg0KcG9v bDIvcm9vdC91c3IvbG9jYWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL3Vzci9sb2NhbDxi cj4NCnBvb2wyL3Jvb3QvdmFyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC92YXI8YnI+DQp0bXBm cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAvdG1wPGJyPg0KcG9vbDIvZXhwb3J0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC9leHBvcnQ8YnI+DQpwb29sMi9leHBvcnQvZHMxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC9leHBvcnQvZHMxPGJyPg0KcG9vbDIvZXhwb3J0 L2RzMS9kYXRhJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC9leHBvcnQvZHMxL2RhdGE8YnI+DQpwb29sMi9leHBvcnQvZHMxL2V4cG9y dCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvZXhwb3J0L2RzMS9leHBvcnQ8 YnI+DQpwb29sMi9leHBvcnQvZHMxL2lzbyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvZXhwb3J0L2RzMS9pc288 YnI+DQpwb29sMi9leHBvcnQvZHMyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC9leHBvcnQvZHMyPGJyPg0KcG9vbDIvZXhwb3J0L2RzMi9kYXRhJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC9leHBvcnQvZHMyL2RhdGE8YnI+DQo8YnI+DQovZXRjL2V4cG9ydHM6PGJyPg0KL2V4cG9ydC9k czEvZGF0YSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtYWxsZGlycyAtbWFwcm9vdD1yb290IDEw LjAuMC4oYWxsIG9mIHRoZSBIVidzKTxicj4NCi9leHBvcnQvZHMxL2V4cG9ydCAtYWxsZGlycyAt bWFwcm9vdD1yb290IDEwLjAuMC4oYWxsIG9mIHRoZSBIVidzKTxicj4NCi9leHBvcnQvZHMxL2lz byZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtYWxsZGlycyAtbWFw cm9vdD1yb290IDEwLjAuMC4oYWxsIG9mIHRoZSBIVidzKTxicj4NCi9leHBvcnQvZHMyL2RhdGEm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLWFsbGRpcnMgLW1hcHJvb3Q9cm9vdCAxMC4wLjAuKGFs bCBvZiB0aGUgSFYncyk8YnI+DQo8YnI+DQpUbyBtYWtlIHRob3NlIFVTQidzIGxhc3QgZm9yIGFz IGxvbmcgYXMgcG9zc2libGUsIC8gaXMgdXN1YWxseSBtb3VudGVkIHJlYWQtb25seS4gQW5kIHdo ZW4geW91IG5lZWQgdG8gY2hhbmdlIGFueXRoaW5nLCB5b3UgbmVlZCB0byByZW1vdW50IC8gdG8g cmVhZC13cml0ZSwgZG8gdGhlIG1haW50ZW5hbmNlLCBhbmQgdGhlbiByZW1vdW50IGJhY2sgdG8g cmVhZC1vbmx5IGFnYWluLiBCdXQgd2hlbiB5b3UgaXNzdWUgYSBtb3VudCBjb21tYW5kLCB0aGUN CiBWTSdzIGluIG9WaXJ0IHBhdXNlLiBBdCBmaXJzdCB3ZSBkaWRuwrR0IHVuZGVyc3RhbmQgdGhh dCB3YXMgYWN0dWFsbHkgdGhlIGNhdXNlIGFuZCB0cmllZCB0byBjb3JyZWxhdGUgdGhlIHNlZW1p bmdseSBzcG9udGFuZW91cyBwYXVzaW5nIHRvIGp1c3QgYWJvdXQgYW55dGhpbmcsIFRoZW4gSSB3 YXMgbG9nZ2VkIGluIHRvIGJvdGggb1ZpcnQncyB3ZWJhZG1pbiwgYW5kIHRoZSBzdG9yYWdlIGF0 IHRoZSBzYW1lIGFuZCBpc3N1ZWQgJnF1b3Q7bW91bnQgLXV3DQogLyZxdW90OywgYW5kICpib29t KiwgcmFuZG9tIFZNJ3Mgc3RhcnRlZCB0byBwYXVzZTopIE5vdCBhbGwgb2YgdGhlbSB0aG91Z2gs IGFuZCBub3QganVzdCBldmVyeSBvbmUgaW4gZWl0aGVyIGNsdXN0ZXIgb3Igc29tZXRoaW5nLCBp dCBpcyBjb21wbGV0ZWx5IHJhbmRvbSB3aGljaCBWTSdzIGFyZSBwYXVzZWQgZXZlcnkgdGltZS48 YnI+DQo8YnI+DQojIHRpbWUgbW91bnQgLXVyIC88YnI+DQo8YnI+DQpyZWFsIDBtMi4xOThzPGJy Pg0KdXNlciAwbTAuMDAwczxicj4NCnN5cyAwbTAuMDAyczxicj4NCjxicj4NCkFuZCBoZXJlwrRz IHdoYXQgdmRzbSBvbiBvbmUgb2YgdGhlIEhWJ3MgdGhvdWdodCBhYm91dCB0aGF0Ojxicj4NCjxh IGhyZWY9Imh0dHA6Ly9wYXN0ZWJpbi5jb20vTVhqZ3BEZlUiPmh0dHA6Ly9wYXN0ZWJpbi5jb20v TVhqZ3BEZlU8L2E+PGJyPg0KPGJyPg0KSXQgYmVnaW5zIHdpdGggYWxsIFZNJ3MgYmVpbmcgJnF1 b3Q7VXAmcXVvdDssIHRoZW4gbWUgaXNzdWluZyB0aGUgcmVtb3VudCBvbiB0aGUgc3RvcmFnZSBm cm9tIHJlYWQtd3JpdGUgdG8gcmVhZC1vbmx5IHdoaWNoIHRvb2sgMiBzZWNzIHRvIGNvbXBsZXRl LCB2ZHNtIGZyZWFraW5nIG91dCB3aGVuIGl0IHNob3J0bHkgbG9vc2VzIGl0wrRzIGNvbm5lY3Rp b25zIGFuZCBsYXN0bHkgbWUgYXQgMTQ6MzQgbWFraW5nIHRoZW0gYWxsIHJ1biBhZ2FpbiBmcm9t IHdlYmFkbWluLjxicj4NCjxicj4NClR3byB0aGluZ3M6PGJyPg0KMSkgRG9lcyBhbnlvbmUga25v dyBvZiBhbnkgaW1wcm92ZW1lbnRzIHRoYXQgY291bGQgYmUgbWFkZSBvbiB0aGUgc3RvcmFnZSBz aWRlLCBhcGFydCBmcm9tIHRoZSBvYnZpb3VzICZxdW90O3N0b3AgcmVtb3VudGluZyZxdW90Oywg c2luY2UgcGF0Y2hpbmcgbXVzdCBldmVudHVhbGx5IGJlIG1hZGUsIGNvbmZpZ3VyYXRpb25zIGNo YW5nZWQsIGFuZCBzbyBvbi4gQSBzbWFydGVyIHdheSBvZiBjb25maWd1cmluZyBzb21ldGhpbmc/ IEJvb3RpbmcgZnJvbSBhbm90aGVyDQogb3JkaW5hcnkgSEREIGlzIHNhZGx5IG91dCBvZiB0aGUg cXVlc3Rpb24gYmVjYXVzZSB0aGVyZSBpc27CtHQgYW55IHJvb20gZm9yIGFueSBtb3JlLCBpdMK0 cyBmdWxsLiBBbmQgSSB3b3VsZCBoYXZlIHJlYWxseSBsaWtlIGl0IHJhdGhlciB0byBib290IGZy b20gdGhlIEhERCdzIHRoYXQgYXJlIGFscmVhZHkgaW4gdGhlcmUsIGJ1dCB0aGVyZSBhcmUgJnF1 b3Q7b3RoZXIgdGhpbmdzJnF1b3Q7IHByZXZlbnRpbmcgdGhhdC48YnI+DQoyKSBOb3RoaW5nIGlu IGVuZ2luZSB3YXMgbG9nZ2VkIGFib3V0IGl0LCBubyAmcXVvdDtFdmVudHMmcXVvdDsgd2VyZSBt YWRlIGFuZCBub3RoaW5nIGluIGVuZ2luZS5sb2cgdGhhdCBjb3VsZCBpbmRpY2F0ZSBzb21ldGhp bmcgaGFkIGdvbmUgd3JvbmcgYXQgYWxsLiBJZiBpdCB3YXNuwrR0IHNlcmlvdXMgZW5vdWdoIHRv IGlzc3VlIGEgd2FybmluZywgd2h5IGRpc3J1cHQgdGhlIHNlcnZpY2Ugd2l0aCBwYXVzaW5nIHRo ZSBtYWNoaW5lcz8gT3IgYXQgbGVhc3QgYXV0b21hdGljYWxseQ0KIHN0YXJ0IHRoZW0gYmFjayB1 cCB3aGVuIGNvbm5lY3Rpb24gdG8gdGhlIHN0b3JhZ2UgYWxtb3N0IGltbWVkaWF0ZWx5IGNhbWUg YmFjayBvbiBpdMK0cyBvd24uIFNheWluZyBub3RoaW5nIG1hZGUgaXQgcmVhbGx5IGhhcmQgdG8g dHJvdWJsZXNob290LCBzaW5jZSB3ZSBkaWRuwrR0IGluaXRpYWxseSBrbmV3IGF0IGFsbCB3aGF0 IGNvdWxkIGJlIGNhdXNpbmcgdGhlIHBhdXNlcyB0byBoYXBwZW4sIGFuZCB3aGVuLjxicj4NCjxi cj4NCkJlc3QgUmVnYXJkczxicj4NCi9LYXJsaSBTasO2YmVyZw0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5F9E965F5A80BC468BE5F40576769F091023A18Bexchange21_--

1 0

Re: [Users] [Engine-devel] ovirt engine sdk
by Michael Pasternak 23 Jan '13

23 Jan '13

On 01/23/2013 03:53 PM, navin p wrote: > Hi Michael, > > Thanks for your help. > > On Wed, Jan 23, 2013 at 6:15 PM, Michael Pasternak <mpastern(a)redhat.com <mailto:mpastern@redhat.com>> wrote: > > > > in python, you can see object's attributes by accessing __dict__/__getattr__/dir(object)/etc., > vm.__dict__ will do the job for you, however i'd suggest you using some IDE (i'm using Eclipse + PyDev plugin), > this way you'll be able accessing object attributes simply by Ctrl+SPACE auto-completion. > > Do i have import something for Ctrl+SPACE to work ? It doesn't work for me atleast for list attributes. > > for vm in vmlist: > print vm.name <http://vm.name>,vm.memory,vm.id <http://vm.id>,vm.os.kernel,vm.cluster.id <http://vm.cluster.id>,vm.start_time > #print help(vm.statistics.list()) > vmslist = vm.statistics.list() > for i in vmslist: > print i.get_name() > > prints > > memory.installed > memory.used > cpu.current.guest > cpu.current.hypervisor > cpu.current.total > > but i need the values of memory.installed and memory.used . statistic holders are complex types, you can fetch data by: i.unit // the unit of the holder data i.values.value[0].datum // actual data > > Also where do i get the Java SDK and jars ? I looked at maven but it was 1.0 version of SDK. central repo has 1.0.0.2-1, see [1], deployment details can be found at [2], wiki at [3]. [1] http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.ovirt.engine.sdk%22 [2] http://www.ovirt.org/Java-sdk#Maven_deployment [3] http://www.ovirt.org/Java-sdk > > > Regards, > Navin -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0