- Users - oVirt List Archives

[Users] Attaching export domain to dc fails
by Patrick Hurrelmann 24 Jan '13

24 Jan '13

Hi list, in one datacenter I'm facing problems with my export storage. The dc is of type single host with local storage. On the host I see that the nfs export domain is still connected, but the engine does not show this and therefore it cannot be used for exports or detached. Trying to add attach the export domain again fails. The following is logged n vdsm: Thread-1902159::ERROR::2013-01-24 17:11:45,474::task::853::TaskManager.Task::(_setError) Task=`4bc15024-7917-4599-988f-2784ce43fbe7`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 861, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 38, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 960, in attachStorageDomain pool.attachSD(sdUUID) File "/usr/share/vdsm/storage/securable.py", line 63, in wrapper return f(self, *args, **kwargs) File "/usr/share/vdsm/storage/sp.py", line 924, in attachSD dom.attach(self.spUUID) File "/usr/share/vdsm/storage/sd.py", line 442, in attach raise se.StorageDomainAlreadyAttached(pools[0], self.sdUUID) StorageDomainAlreadyAttached: Storage domain already attached to pool: 'domain=cd23808b-136a-4b33-a80c-f2581eab022d, pool=d95c53ca-9cef-4db2-8858-bf4937bd8c14' It won't let me attach the export domain saying that it is already attached. Manually umounting the export domain on the host results in the same error on subsequent attach. This is on CentOS 6.3 using Dreyou's rpms. Installed versions on host: vdsm.x86_64 4.10.0-0.44.14.el6 vdsm-cli.noarch 4.10.0-0.44.14.el6 vdsm-python.x86_64 4.10.0-0.44.14.el6 vdsm-xmlrpc.noarch 4.10.0-0.44.14.el6 Engine: ovirt-engine.noarch 3.1.0-3.19.el6 ovirt-engine-backend.noarch 3.1.0-3.19.el6 ovirt-engine-cli.noarch 3.1.0.7-1.el6 ovirt-engine-config.noarch 3.1.0-3.19.el6 ovirt-engine-dbscripts.noarch 3.1.0-3.19.el6 ovirt-engine-genericapi.noarch 3.1.0-3.19.el6 ovirt-engine-jbossas711.x86_64 1-0 ovirt-engine-notification-service.noarch 3.1.0-3.19.el6 ovirt-engine-restapi.noarch 3.1.0-3.19.el6 ovirt-engine-sdk.noarch 3.1.0.5-1.el6 ovirt-engine-setup.noarch 3.1.0-3.19.el6 ovirt-engine-tools-common.noarch 3.1.0-3.19.el6 ovirt-engine-userportal.noarch 3.1.0-3.19.el6 ovirt-engine-webadmin-portal.noarch 3.1.0-3.19.el6 ovirt-image-uploader.noarch 3.1.0-16.el6 ovirt-iso-uploader.noarch 3.1.0-16.el6 ovirt-log-collector.noarch 3.1.0-16.el6 How can this be recovered to a sane state? If more information is needed, please do not hesitate to request it. Thanks and regards Patrick -- Lobster LOGsuite GmbH, Münchner Straße 15a, D-82319 Starnberg HRB 178831, Amtsgericht München Geschäftsführer: Dr. Martin Fischer, Rolf Henrich

2 2

[Users] storage domain auto re-cover
by Alex Leonhardt 24 Jan '13

24 Jan '13

hi, is it possible to set a storage domain to auto-recover / auto-reactivate ? e.g. after I restart a host that runs a storage domain, i want ovirt engine to make that storage domain active after the host has come up. thanks alex -- | RHCE | Senior Systems Engineer | www.vcore.co | www.vsearchcloud.com |

2 3

[Users] custom nfs mount options
by Alex Leonhardt 24 Jan '13

24 Jan '13

Hi, Is it possible set custom nfs mount options, specifically : noatime, wsize and rsize ? I couldnt see anything when "adding a NFS domain" - only timeout & retry. Thanks! Alex -- | RHCE | Senior Systems Engineer | www.vcore.co | www.vsearchcloud.com |

5 10

[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 24 Jan '13

24 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

[Users] vnic : add a custom properties and use it in vdsm_hook
by Benoit ML 23 Jan '13

23 Jan '13

Hello Evrybody, Is there a way to add custom properties for a nic ? and use it in vdsm_hooks ? The objectife is to redefine some network parameters of a vnic at the vm boot ... (such per vnic bandwitchs, per vnic vlan, and so on) and maybe use openvswitch ... Thank you in advance -- -- Benoit

3 6

[Users] host deploy and after reboot not responsive
by Gianluca Cecchi 23 Jan '13

23 Jan '13

Hello, using ovirt 3.2 on fedora 18 from ovirt-nightly 3.2.0-1.20130113.gitc954518 After deploy and reboot of a fedora 18 host it stays not-responsive. What to check and which log files to send from engine and node? Thanks, Gianluca

3 31

[Users] Adding additional network(s)
by Tom Brown 23 Jan '13

23 Jan '13

Hi I am setting up another DC, that is managed by my sole management node, and this DC will have a requirement that the VM's will need an additional storage NIC. This NIC is for NFS/CIFS traffic and is independent of the oVirt VM's disks. I have cabled the additional physical NIC in the HV's as this network is non routed storage, and I where to go from here. Whats the next step needed to add the NIC to the DC and then i presume adding the NIC to the VM's is straight forward. thanks

2 2

Re: [Users] cannot add gluster domain
by Alex Leonhardt 23 Jan '13

23 Jan '13

Hi all, Am not too familiar with fedora and its services, anyone can help him? Alex On Jan 23, 2013 5:02 AM, "T-Sinjon" <tscbj1989(a)gmail.com> wrote: > I have forced v3 in my /etc/nfsmount and there's no firewall between NFS > server and the host. > > The only problem is no rpc.statd running . Could you tell me how can i > start it since there's no rpcbind installed on overt node 2.5.5-0.1? > > [root@ovirtnode1 ~]# systemctl status nfs-lock.service > nfs-lock.service - NFS file locking service. > Loaded: loaded (/usr/lib/systemd/system/nfs-lock.service; enabled) > Active: failed (Result: exit-code) since Thu, 17 Jan 2013 09:41:45 > +0000; 5 days ago > CGroup: name=systemd:/system/nfs-lock.service > > Jan 17 09:41:45 localhost.localdomain rpc.statd[1385]: Version 1.2.6 > starting > Jan 17 09:41:45 localhost.localdomain rpc.statd[1385]: Initializing NSM > state > [root@ovirtnode1 ~]# systemctl start nfs-lock.service > Failed to issue method call: Unit rpcbind.service failed to load: No such > file or directory. See system logs and 'systemctl status rpcbind.service' > for details. > > On 22 Jan, 2013, at 6:14 PM, Alex Leonhardt <alex.tuxx(a)gmail.com> wrote: > > Hi, this seems to look like the error you're getting : > > 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") > > Are you running nfs3 on that host ? if yes, have you forced v3 ? is > rpc.statd running ? is the NFS server firewalling off the rpc.* ports ? > > alex > > > On 22 January 2013 09:58, T-Sinjon <tscbj1989(a)gmail.com> wrote: > >> 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',) >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> > > > > -- > > | RHCE | Senior Systems Engineer | www.vcore.co | www.vsearchcloud.com | > > >

1 0

Re: [Users] Where to download ovirt-engine-sdk-java 1.0.0.2?
by Michael Pasternak 23 Jan '13

23 Jan '13

Hi, On 01/23/2013 02:37 AM, Sherry Yu wrote: > Hi Michael, > > Can you point me to download ovirt-engine-sdk-java 1.0.0.2 and where to get more info. on Java development using this API? sdk can be deployed using [1], more info can be found here [2]. [1] http://www.ovirt.org/Java-sdk#Maven_deployment [2] http://www.ovirt.org/Java-sdk > > My task is to create an integration between RHEV 3.x and SAP LVM, a product that has a Java API. I met with Oved at oVirt workshop this week and he mentioned this Java SDK. It sounds a better fit than the REST API that I have been investigating. > > Many Thanks and I am looking forward to hearing from you. > Sherry > > ----- Forwarded Message ----- > From: "Oved Ourfalli" <ovedo(a)redhat.com> > To: "Sherry Yu" <syu(a)redhat.com> > Sent: Tuesday, January 22, 2013 4:30:11 PM > Subject: Fwd: [Engine-devel] ovirt-engine-sdk-java 1.0.0.2 released > > > > ----- Forwarded Message ----- > From: "Michael Pasternak" <mpastern(a)redhat.com> > To: users(a)ovirt.org > Cc: "engine-devel" <engine-devel(a)ovirt.org> > Sent: Wednesday, January 16, 2013 6:38:02 AM > Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.2 released > > > Basically this release addresses an issue when [1] constructor is used > with NULLs as optional parameters, > > [1] public Api(String url, String username, String password, String key_file, > String cert_file, String ca_file, Integer port, Integer timeout, > Boolean persistentAuth, Boolean insecure, Boolean filter, Boolean debug) > -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0

[Users] setupNetworks failure - Host non-operational
by Deepak C Shetty 23 Jan '13

23 Jan '13

Hi All, I have a multi-VM setup, where I have ovirt engine on one VM and VDSM host on another. Discovering the host from the engine puts the host in Unassigned state, with the error saying 'ovirtmgmt' network not found. When i select setupNetworks and drag-drop the ovirtmgmt to setup over eth0, i see the below error in VDSM & host goes to non-operataional state. I tried the steps mentioned by Alon in http://lists.ovirt.org/pipermail/users/2012-December/011257.html but still see the same error ============= dump from vdsm.log ================ MainProcess|Thread-23::ERROR::2013-01-22 18:25:53,496::configNetwork::1438::setupNetworks::(setupNetworks) Requested operation is not valid: cannot set autostart for transient network Traceback (most recent call last): File "/usr/share/vdsm/configNetwork.py", line 1420, in setupNetworks implicitBonding=True, **d) File "/usr/share/vdsm/configNetwork.py", line 1030, in addNetwork configWriter.createLibvirtNetwork(network, bridged, iface) File "/usr/share/vdsm/configNetwork.py", line 208, in createLibvirtNetwork self._createNetwork(netXml) File "/usr/share/vdsm/configNetwork.py", line 192, in _createNetwork net.setAutostart(1) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2148, in setAutostart if ret == -1: raise libvirtError ('virNetworkSetAutostart() failed', net=self) libvirtError: Requested operation is not valid: cannot set autostart for transient network MainProcess|Thread-23::ERROR::2013-01-22 18:25:53,502::supervdsmServer::77::SuperVdsm.ServerCallback::(wrapper) Error in setupNetworks Traceback (most recent call last): File "/usr/share/vdsm/supervdsmServer.py", line 75, in wrapper return func(*args, **kwargs) File "/usr/share/vdsm/supervdsmServer.py", line 170, in setupNetworks return configNetwork.setupNetworks(networks, bondings, **options) File "/usr/share/vdsm/configNetwork.py", line 1420, in setupNetworks implicitBonding=True, **d) File "/usr/share/vdsm/configNetwork.py", line 1030, in addNetwork configWriter.createLibvirtNetwork(network, bridged, iface) File "/usr/share/vdsm/configNetwork.py", line 208, in createLibvirtNetwork self._createNetwork(netXml) File "/usr/share/vdsm/configNetwork.py", line 192, in _createNetwork net.setAutostart(1) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2148, in setAutostart if ret == -1: raise libvirtError ('virNetworkSetAutostart() failed', net=self) libvirtError: Requested operation is not valid: cannot set autostart for transient network

5 6

[Users] Help on an almost migrated ovirt-engine
by Adrian Gibanel 23 Jan '13

23 Jan '13

I need to migrate an ovirt-engine from an All-In-One (AIO) setup to a dedicated machine. So with an old mailing message I've tried to do it but not finished yet, that's why I ask for help. I've written a wiki page for the experience so that it becomes a howto which can be found here: http://www.ovirt.org/User:Adrian15/oVirt_engine_migration At the last step the one that finally starts ovirt-engine I've decided to ask help here just in case I was missing something important. So here are my doubts. * Original message that inspired the howto is here: http://www.mail-archive.com/users@ovirt.org/msg00670.html * What packages should I delete safely from an AIO setup so that it's just an hypervisor once I've migrate the ovirt-engine part? * Is the right way the one I've used to recreate the database? ** Origin pg_dump -U postgres engine | gzip > engine_db.gz ** Destination pg_dump -U postgres -s -f tempdb.dump engine dropdb -U postgres engine createdb -U postgres engine zcat engine_db.gz | psql -U postgres engine * Let's read: http://www.mail-archive.com/users@ovirt.org/msg00682.html : WRT certificates, note that hostname should nt change, or SSL will be invalidated. Did he mean the SSL when you connect via http or https to the manager which currently doesn't bother me? Or maybe the SSL to connect to other hosts and communicate to vdsm (sorry if I'm saying something nonsense. I don't understand oVirt architecture completely) which bothers me? * Certificates is: /etc/pki/ovirt-engine ? Something more? * Conf is: /etc/ovirt-engine ? Something more? Thank you! -- -- Adrián Gibanel I.T. Manager +34 675 683 301 www.btactic.com Ens podeu seguir a/Nos podeis seguir en: i Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es cosa de todos. AVIS: El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge . AVISO: El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje .

3 5

[Users] error at Creating the database
by Arindam Choudhury 22 Jan '13

22 Jan '13

Hi, I am a newbie. I am trying to build oVirt-engine from source following this tutorial http://www.ovirt.org/Building_oVirt_engine When I am trying to create the database, I am getting the following error: $ ./create_db_devel.sh -u postgres Running original create_db script... Creating the database: engine dropdb: could not connect to database template1: FATAL: Ident authentication failed for user "postgres" createdb: could not connect to database template1: FATAL: Ident authentication failed for user "postgres" Failed to create database engine Failed to create database engine I am on rawhide and I have already altered # tail -3 /var/lib/pgsql/data/pg_hba.conf local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust What am I doing wrong? Thanks, Arindam

2 1

[Users] error while building oVirt-engine
by Arindam Choudhury 22 Jan '13

22 Jan '13

Hi, I am following http://www.ovirt.org/Building_oVirt_engine tutorial to build oVirt-engine from source. when i do: $ mvn clean install -e [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Extensions for GWT 3.2.0 [INFO] ------------------------------------------------------------------------ [WARNING] The POM for org.ovirt.engine.ui:genericapi:jar:3.2.0 is missing, no dependency information available [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] oVirt Modules - ui ................................ SUCCESS [0.013s] [INFO] Extensions for GWT ................................ FAILURE [0.014s] [INFO] UI Utils Compatibility (for UICommon) ............. SKIPPED [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project gwt-extension: Could not resolve dependencies for project org.ovirt.engine.ui:gwt-extension:jar:3.2.0: Failure to find org.ovirt.engine.ui:genericapi:jar:3.2.0 in http://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project gwt-extension: Could not resolve dependencies for project org.ovirt.engine.ui:gwt-extension:jar:3.2.0: Failure to find org.ovirt.engine.ui:genericapi:jar:3.2.0 in http://repo1.maven.org/maven2was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:158) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project org.ovirt.engine.ui:gwt-extension:jar:3.2.0: Failure to find org.ovirt.engine.ui:genericapi:jar:3.2.0 in http://repo1.maven.org/maven2was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:189) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:185) ... 22 more Caused by: org.sonatype.aether.resolution.DependencyResolutionException: Failure to find org.ovirt.engine.ui:genericapi:jar:3.2.0 in http://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:375) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:183) ... 23 more Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failure to find org.ovirt.engine.ui:genericapi:jar:3.2.0 in http://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:538) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:216) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:358) ... 24 more Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Failure to find org.ovirt.engine.ui:genericapi:jar:3.2.0 in http://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced at org.sonatype.aether.impl.internal.DefaultUpdateCheckManager.newException(DefaultUpdateCheckManager.java:230) at org.sonatype.aether.impl.internal.DefaultUpdateCheckManager.checkArtifact(DefaultUpdateCheckManager.java:204) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:427) ... 26 more [ERROR] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionExcept… [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn <goals> -rf :gwt-extension

3 4

[Users] Power mgmt and engine relationship
by Gianluca Cecchi 22 Jan '13

22 Jan '13

Hello, Is there any requirement in connectivity between engine and hosts for fencing? Or is only from any host to any host? Is it a concept cluster wide, correct? Not a DC one? Thanks Gianluca

3 2

[Users] oVirt node install hanging on admin login prompt
by Nicolas Ecarnot 22 Jan '13

22 Jan '13

Hi, I'm trying to install oVirt node 2.5.5-0.1.fc17 and it is node going well. I'm trying to install it on a Dell blade M610 via a iDrac, and I'm quit accustomed to this kind of thing. - As I already had the issue of the label on the grub boot line, I knew how to specify /dev/sr0 or sr1 on the linux line. Well. - The install is ok with discovering my hard drive, and the installation seems to be fine. After rebooting, the bott process is leading me to the login prompt where the documentation tells me to log as 'admin' with the correct password : The keyboard is not responding, I can not even type the user name. I can't change of console, no network activity is seen. There does not seem to be a kernel panic, as some additional log lines are displayed (about the creation of bond interfaces). I also see some more lines about "systemd-readahead-collect : failed to open pack file: read-only file system"... When downloading the iso install file from the oVirt repo, I choosed the smalest one, not the "live" one. Did I did wrong? Anyway, now, what are my options? -- Nicolas Ecarnot

4 6

[Users] FC on ovirt-node with brocade : port never up
by Kevin Maziere Aubry 22 Jan '13

22 Jan '13

Hi all I have a strange behaviour between my ovirt node and my FC switch. All material are brocade. Ovirt node release : oVirt Node Hypervisor release 2.5.5 (0.1.fc17) The thing is that the node doesn't detect the FC port, it detect the FC card only. On 10 clone hosts, 2 have detected the link, all others fails. And for these 2 hosts I've rebooted them many time before it works. Because there is only the BFA driver include, I can't debug anything, or update Does anyone have a feedback on that ? 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