- Users - oVirt List Archives

[Users] Bottleneck writing to a VM w/ mounted GlusterFS
by Stefano Stagnaro 28 Sep '13

28 Sep '13

Hello, I'm testing oVirt 3.3 with GlusterFS libgfapi back-end. I'm using a node for engine and one for VDSM. From the VMs I'm mounting a second GlusterFS volume on a third storage server. I'm experiencing very bad transfer rates (38MB/s) writing from a client to a VM on the mounted GlusterFS. On the other hand, from the VM itself I can move a big file from the root vda (libgfapi) to the mounted GlusterFS at 70MB/s. I can't really figure out where the bottleneck could be. I'm using only the default ovirtmgmt network. Thank you for your help, any hint will be appreciated. Regards, -- Stefano Stagnaro IT Manager Prisma Engineering S.r.l. Via Petrocchi, 4 20127 Milano – Italy Tel. 02 26113507 int 339 e-mail: stefanos(a)prisma-eng.com skype: stefano.stagnaro

2 1

[Users] Gluster NFS Replicate bricks different size
by Andrew Lau 27 Sep '13

27 Sep '13

I've mounted a gluster 1x2 replica through NFS in oVirt. The NFS share holds the qcow images of the VMs. I recently nuked a whole replica brick in an 1x2 array (for numerous other reasons including split-brain), the brick self healed and restored back to the same state as its partner. 4 days later, they've become inbalanced. The direct `du` of the /brick are showing different sizes by around 20GB. I can see at brick level how some images are not the same size. I don't think this is normal, but I can't see anything to point what could be the issue. gluster volume heal STORAGE info gluster volume heal STORAGE info split-brain Shows no issues. Any suggestions? Cheers, Andrew.

1 0

Re: [Users] could not add iscsi disk in ovirt.
by Dafna Ron 27 Sep '13

27 Sep '13

the output is empty in both your outpit and the logs. This is the part in the log that shows that you do not have any devices: return: [] when you create a new disk and select the NFS DC- can you please send me the screen shot of that? On 09/27/2013 02:41 PM, Saurabh wrote: > On 27/09/13 18:40, Dafna Ron wrote: >> I am not sure direct lun will be supported for an NFS pool... can you >> try the same from iscsi pool? >> >> is this lun being used somewhere else or did you create a new one? >> you can run vdsClient -s 0 getDeviceList to see the list of the >> available luns and if the status is free or not. >> (it should also in the logs (engine and vdsm) when you discover the >> luns from the webadmin. >> >> >> On 09/27/2013 01:43 PM, Saurabh wrote: >>> >>> Hi guys, I am running ovirt with NFS as storage pool. Everything is >>> working quite fine for me. The only problem is I could not add the a >>> new iscsi disk in Disk tab. When I go to the Disk tab there is an >>> option of adding new disk from internal storage and another option >>> is add External (Direct Lun). When I opt for the External (Direct >>> LUN), I am able to discover the Lun but could not log in to that lun >>> using the ovirt web console. Whereas when I try to login to that lun >>> using the isciadm in command line I am able to login. Any help?? >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> >> > I have created a new Lun for this purpose only and it is not being > used anywhere. > In order to try an iscsi pool I will have to reconfigure the engine, > because during the engine setup I opted for nfs. > > This is the output when I run this command. > > [root@ovirt ~]# vdsClient -s 0 getDeviceList > [] > > > > > > this is log snippet from engine.log when I discover and try to login > to that lun. > > > ################################################################################################# > > 013-09-27 14:34:55,592 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.DiscoverSendTargetsVDSCommand] > (ajp--127.0.0.1-8702-11) START, DiscoverSendTargetsVDSCommand(HostName > = 192.168.100.59, HostId = 168842b9-071b-4c64-a22d-07ae1e63830b, > connection={ id: null, connection: 192.168.100.160, iqn: null, > vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, > nfsTimeo: null };), log id: 2e12b97 > 2013-09-27 14:34:55,653 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.DiscoverSendTargetsVDSCommand] > (ajp--127.0.0.1-8702-11) FINISH, DiscoverSendTargetsVDSCommand, > return: [{ id: null, connection: 192.168.100.160, iqn: > iqn.2013.26.ovirt.techblue.lv001, vfsType: null, mountOptions: null, > nfsVersion: null, nfsRetrans: null, nfsTimeo: null };], log id: 2e12b97 > 2013-09-27 14:36:25,877 INFO > [org.ovirt.engine.core.bll.storage.ConnectStorageToVdsCommand] > (ajp--127.0.0.1-8702-2) Running command: ConnectStorageToVdsCommand > internal: false. Entities affected : ID: > aaa00000-0000-0000-0000-123456789aaa Type: System > 2013-09-27 14:36:25,880 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] > (ajp--127.0.0.1-8702-2) START, ConnectStorageServerVDSCommand(HostName > = 192.168.100.59, HostId = 168842b9-071b-4c64-a22d-07ae1e63830b, > storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = > ISCSI, connectionList = [{ id: null, connection: 192.168.100.160, iqn: > iqn.2013.26.ovirt.techblue.lv001, vfsType: null, mountOptions: null, > nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: 5fca13a4 > 2013-09-27 14:36:26,012 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] > (ajp--127.0.0.1-8702-2) FINISH, ConnectStorageServerVDSCommand, > return: {00000000-0000-0000-0000-000000000000=0}, log id: 5fca13a4 > 2013-09-27 14:36:26,098 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.GetDeviceListVDSCommand] > (ajp--127.0.0.1-8702-12) START, GetDeviceListVDSCommand(HostName = > 192.168.100.59, HostId = 168842b9-071b-4c64-a22d-07ae1e63830b, > storageType=ISCSI), log id: 20fb893b > 2013-09-27 14:36:29,376 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.GetDeviceListVDSCommand] > (ajp--127.0.0.1-8702-12) FINISH, GetDeviceListVDSCommand, return: [], > log id: 20fb893b > > ###################################################################################################### > > > > -- Dafna Ron

2 2

[Users] could not add iscsi disk in ovirt.
by Saurabh 27 Sep '13

27 Sep '13

Hi guys, I am running ovirt with NFS as storage pool. Everything is working quite fine for me. The only problem is I could not add the a new iscsi disk in Disk tab. When I go to the Disk tab there is an option of adding new disk from internal storage and another option is add External (Direct Lun). When I opt for the External (Direct LUN), I am able to discover the Lun but could not log in to that lun using the ovirt web console. Whereas when I try to login to that lun using the isciadm in command line I am able to login. Any help??

2 2

[Users] vdsm live migration errors in latest master
by Dead Horse 27 Sep '13

27 Sep '13

Seeing failed live migrations and these errors in the vdsm logs with latest VDSM/Engine master. Hosts are EL6.4 Thread-1306::ERROR::2013-09-23 16:02:42,422::BindingXMLRPC::993::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 979, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 211, in vmDestroy return vm.destroy() File "/usr/share/vdsm/API.py", line 323, in destroy res = v.destroy() File "/usr/share/vdsm/vm.py", line 4326, in destroy response = self.releaseVm() File "/usr/share/vdsm/vm.py", line 4292, in releaseVm self._cleanup() File "/usr/share/vdsm/vm.py", line 2750, in _cleanup self._cleanupDrives() File "/usr/share/vdsm/vm.py", line 2482, in _cleanupDrives drive, exc_info=True) File "/usr/lib64/python2.6/logging/__init__.py", line 1329, in error self.logger.error(msg, *args, **kwargs) File "/usr/lib64/python2.6/logging/__init__.py", line 1082, in error self._log(ERROR, msg, args, **kwargs) File "/usr/lib64/python2.6/logging/__init__.py", line 1082, in error self._log(ERROR, msg, args, **kwargs) File "/usr/lib64/python2.6/logging/__init__.py", line 1173, in _log self.handle(record) File "/usr/lib64/python2.6/logging/__init__.py", line 1183, in handle self.callHandlers(record) File "/usr/lib64/python2.6/logging/__init__.py", line 1220, in callHandlers hdlr.handle(record) File "/usr/lib64/python2.6/logging/__init__.py", line 679, in handle self.emit(record) File "/usr/lib64/python2.6/logging/handlers.py", line 780, in emit msg = self.format(record) File "/usr/lib64/python2.6/logging/__init__.py", line 654, in format return fmt.format(record) File "/usr/lib64/python2.6/logging/__init__.py", line 436, in format record.message = record.getMessage() File "/usr/lib64/python2.6/logging/__init__.py", line 306, in getMessage msg = msg % self.args File "/usr/share/vdsm/vm.py", line 107, in __str__ if not a.startswith('__')] File "/usr/share/vdsm/vm.py", line 1344, in hasVolumeLeases if self.shared != DRIVE_SHARED_TYPE.EXCLUSIVE: AttributeError: 'Drive' object has no attribute 'shared' - DHC

3 7

[Users] importing VM from ESXI
by emitor＠gmail.com 26 Sep '13

26 Sep '13

Hi, I'm not being able to import a VM from ESXI: [root@ovirt-mgmt ~]# LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 virt-v2v -ic esx://10.11.12.123/?no_verify=1 -o rhev -os 10.11.12.222:/var/lib/exports/export --network ovirtmgt MultiDektec MultiDektec_MultiDektec: 100% [======================================================================================================================================================]D 0h36m54s libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: set_backend "appliance" libguestfs: trace: set_backend = 0 libguestfs: create: flags = 0, handle = 0x4431d30, program = perl libguestfs: trace: set_attach_method "appliance" libguestfs: trace: set_backend "appliance" libguestfs: trace: set_backend = 0 libguestfs: trace: set_attach_method = 0 libguestfs: trace: add_drive "/tmp/KxIoJI50Pc/2872ac3e-7340-4dfa-9801-0a1bd052b3a3/v2v._ApSlRZG/387a5113-bbc2-45a2-9c55-5dc3dade31a9/01c899de-131e-4407-a16c-8c5484ccb8bd" "format:raw" "iface:ide" "name:sda" libguestfs: trace: add_drive = 0 libguestfs: trace: add_drive "/tmp/to3mfS2mtB" "readonly:true" "format:raw" "iface:ide" libguestfs: trace: add_drive = 0 libguestfs: trace: set_network true libguestfs: trace: set_network = 0 libguestfs: trace: launch libguestfs: trace: get_tmpdir libguestfs: trace: get_tmpdir = "/tmp" libguestfs: trace: get_backend libguestfs: trace: get_backend = "direct" libguestfs: launch: backend=direct libguestfs: launch: tmpdir=/tmp/libguestfsbaJ32y libguestfs: launch: umask=0022 libguestfs: launch: euid=36 libguestfs: command: run: supermin-helper libguestfs: command: run: \ --verbose libguestfs: command: run: \ -u 36 libguestfs: command: run: \ -g 36 libguestfs: command: run: \ -f checksum libguestfs: command: run: \ /usr/lib64/guestfs/supermin.d libguestfs: command: run: \ x86_64 supermin helper [00008ms] whitelist = (not specified), host_cpu = x86_64, kernel = (null), initrd = (null), appliance = (null) supermin helper [00009ms] inputs[0] = /usr/lib64/guestfs/supermin.d checking modpath /lib/modules/3.10.10-200.fc19.x86_64 is a directory checking modpath /lib/modules/3.11.1-200.fc19.x86_64 is a directory checking modpath /lib/modules/3.10.11-200.fc19.x86_64 is a directory picked vmlinuz-3.11.1-200.fc19.x86_64 supermin helper [00010ms] finished creating kernel supermin helper [00010ms] visiting /usr/lib64/guestfs/supermin.d supermin helper [00010ms] visiting /usr/lib64/guestfs/supermin.d/base.img supermin helper [00055ms] visiting /usr/lib64/guestfs/supermin.d/daemon.img supermin helper [00057ms] visiting /usr/lib64/guestfs/supermin.d/hostfiles supermin helper [00419ms] visiting /usr/lib64/guestfs/supermin.d/init.img supermin helper [00440ms] visiting /usr/lib64/guestfs/supermin.d/udev-rules.img supermin helper [00468ms] adding kernel modules supermin helper [00528ms] finished creating appliance libguestfs: checksum of existing appliance: 096bf8833aed53a33f7c0da2a5e685ad430bba5b50ae20a7e0325bca32cca6d2 libguestfs: trace: get_cachedir libguestfs: trace: get_cachedir = "/var/tmp" libguestfs: [00718ms] begin testing qemu features libguestfs: command: run: /usr/bin/qemu-kvm libguestfs: command: run: \ -nographic libguestfs: command: run: \ -help libguestfs: command: run: /usr/bin/qemu-kvm libguestfs: command: run: \ -nographic libguestfs: command: run: \ -version libguestfs: qemu version 1.4 libguestfs: command: run: /usr/bin/qemu-kvm libguestfs: command: run: \ -nographic libguestfs: command: run: \ -machine accel=kvm:tcg libguestfs: command: run: \ -device ? libguestfs: [01607ms] finished testing qemu features [01608ms] /usr/bin/qemu-kvm \ -global virtio-blk-pci.scsi=off \ -nodefconfig \ -nodefaults \ -nographic \ -machine accel=kvm:tcg \ -m 500 \ -no-reboot \ -no-hpet \ -kernel /var/tmp/.guestfs-36/kernel.52160 \ -initrd /var/tmp/.guestfs-36/initrd.52160 \ -device virtio-scsi-pci,id=scsi \ -drive file=/tmp/KxIoJI50Pc/2872ac3e-7340-4dfa-9801-0a1bd052b3a3/v2v._ApSlRZG/387a5113-bbc2-45a2-9c55-5dc3dade31a9/01c899de-131e-4407-a16c-8c5484ccb8bd,cache=none,format=raw,id=hd0,if=ide \ -drive file=/tmp/to3mfS2mtB,snapshot=on,format=raw,id=hd1,if=ide \ -drive file=/var/tmp/.guestfs-36/root.52160,snapshot=on,id=appliance,if=none,cache=unsafe \ -device scsi-hd,drive=appliance \ -device virtio-serial \ -serial stdio \ -device sga \ -chardev socket,path=/tmp/libguestfsbaJ32y/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -netdev user,id=usernet,net=169.254.0.0/16 \ -device virtio-net-pci,netdev=usernet \ -append 'panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdc selinux=0 guestfs_verbose=1 TERM=screen' qemu-system-x86_64: -drive file=/tmp/KxIoJI50Pc/2872ac3e-7340-4dfa-9801-0a1bd052b3a3/v2v._ApSlRZG/387a5113-bbc2-45a2-9c55-5dc3dade31a9/01c899de-131e-4407-a16c-8c5484ccb8bd,cache=none,format=raw,id=hd0,if=ide: could not open disk image /tmp/KxIoJI50Pc/2872ac3e-7340-4dfa-9801-0a1bd052b3a3/v2v._ApSlRZG/387a5113-bbc2-45a2-9c55-5dc3dade31a9/01c899de-131e-4407-a16c-8c5484ccb8bd: Permission denied libguestfs: child_cleanup: 0x4431d30: child process died libguestfs: sending SIGTERM to process 52793 libguestfs: trace: launch = -1 (error) virt-v2v: Failed to launch guestfs appliance. Try running again with LIBGUESTFS_DEBUG=1 for more information libguestfs: trace: close libguestfs: closing guestfs handle 0x4431d30 (state 0) libguestfs: command: run: rm libguestfs: command: run: \ -rf /tmp/libguestfsbaJ32y I've followed this link to do it: http://www.hacktheory.org/index.php/projects/projects-by-eureka/migrate-esx… And these to try to fix the error: https://bugzilla.redhat.com/show_bug.cgi?id=921292 http://superuser.com/questions/298426/kvm-image-failed-to-start-with-virsh-… But it's still happening the same I'm running: qemu-kvm-1.4.2-9.fc19.x86_64 libvirt-1.1.2-1.fc19 vdsm-4.12.1-2.fc19 libguestfs-tools-c-1.22.6-1.fc19.x86_64 libguestfs-1.22.6-1.fc19.x86_64 virt-v2v-0.9.0-3.fc19.x86_64 Could you give me a hint on this? Thanks! -- *Emiliano Tortorella* +598 98941176 emitor(a)gmail.com

2 3

Re: [Users] Disk state - Illegal?
by SULLIVAN, Chris (WGK) 26 Sep '13

26 Sep '13

Thanks for posting that Andrew. I had the same problem removing disks from a Gluster volume (disk state changed to Illegal and the actual disk file was not removed from the volume) and your method worked fine for me. Cheers, Chris Message: 3 Date: Thu, 26 Sep 2013 12:53:04 +1000 From: Andrew Lau <andrew(a)andrewklau.com> To: Dan Ferris <dferris(a)prometheusresearch.com> Cc: "Users(a)ovirt.org" <Users(a)ovirt.org> Subject: Re: [Users] Disk state - Illegal? Message-ID: <CAD7dF9droPuPGxqjM-9aTyE7_qLLhDnYxLLVVB_FtWQdkH0srw(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" I noticed that too, I wasn't sure if it was a bug or just how I had setup my NFS share.. There were three steps I did to remove the disk images, I'm sure there's a 100% easier solution..: I found the easiest way (graphically) was go to your https://ovirtengine/api/disks and so a search for the illegal disk. Append the extra ID eg. <disk href="/api/disks/lk342-dfsdf... into your URL this'll give you your image ID. Go to your storage share: cd /data/storage-id/master/vms/storage-id grep -ir 'vmname' * You'll find the image-id reference here too. Then the image you will want to remove is in the /data/storage-id/images/image-id I assume you could safely remove this whole folder if you wanted to delete the disk. To remove the illegal state I did it through the API so again with the URL above https://ovirtengine/disks/disk-id send a DELETE using HTTP/CURL Again, this was a poor mans solution but it worked for me. On Thu, Sep 26, 2013 at 4:04 AM, Dan Ferris <dferris(a)prometheusresearch.com>wrote: > Hi, > > I have another hopefully simple question. > > One VM that I am trying to remove says that it's disk state is "illegal" > and when I try to remove the disk it says that it failed to initiate > the removing of the disk. > > Is there an easy way to get rid of these illegal disk images? > > Dan > PLEASE CONSIDER THE ENVIRONMENT, DON'T PRINT THIS EMAIL UNLESS YOU REALLY NEED TO. This email and its attachments may contain information which is confidential and/or legally privileged. If you are not the intended recipient of this e-mail please notify the sender immediately by e-mail and delete this e-mail and its attachments from your computer and IT systems. You must not copy, re-transmit, use or disclose (other than to the sender) the existence or contents of this email or its attachments or permit anyone else to do so. ----------------------------- ______________________________**_________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org > /mailman/listinfo/users> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ovirt.org/pipermail/users/attachments/20130926/7b7ac24b/attach…> ------------------------------ Message: 4 Date: Thu, 26 Sep 2013 08:35:07 +0100 From: "Richard W.M. Jones" <rjones(a)redhat.com> To: "emitor(a)gmail.com" <emitor(a)gmail.com> Cc: users(a)ovirt.org Subject: Re: [Users] importing VM from ESXI Message-ID: <20130926073507.GE1887(a)redhat.com> Content-Type: text/plain; charset=us-ascii On Wed, Sep 25, 2013 at 06:10:00PM -0300, emitor(a)gmail.com wrote: > could not open disk image > /tmp/KxIoJI50Pc/2872ac3e-7340-4dfa-9801-0a1bd052b3a3/v2v._ApSlRZG/387a5113-bbc2-45a2-9c55-5dc3dade31a9/01c899de-131e-4407-a16c-8c5484ccb8bd: > Permission denied The error comes from qemu and indicates qemu cannot open this temporary disk image. I've no idea why it cannot open it, but possibilities include: SELinux, file permissions (eg on /tmp), setting of TMPDIR, relative path to a backing file, and more ... I'd suggest that you 'strace -f' the whole set of processes to see what precise system call fails. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) ------------------------------ _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users End of Users Digest, Vol 24, Issue 140 **************************************

1 0

[Users] Ovirt engine high availability
by Doug Bishop 25 Sep '13

25 Sep '13

Hello, Was wondering if anyone can shed a light on this subject as I could not find any documentation specific to this. I am currently running an ovirt 3.2 cluster with 5 hosts with local storage. I have a dedicated box running ovirt engine. I would like to have the ability to run an additional box with ovirt engine on it for high availability of the portal. I realize this would most likely require I run a separate instance of postgres for the engine, however I was wondering if this is something that is officially supported? Thanks! Doug Bishop Sr. Systems Engineer dbishop(a)controlscan.com Controlscan, Inc. 11475 Great Oaks Way, Suite 300 Alpharetta, GA 30022 www.controlscan.com NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) or entity and may contain sensitive information that is confidential, proprietary, privileged or otherwise protected by law. Any unauthorized review, use, disclosure, distribution, copying or other use of, or taking of any action in reliance upon, is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of this message. This e-mail is and any response to it will be unencrypted and, therefore, potentially unsecure. The recipient should check this email and any attachments for the presence of viruses/malware according to security best practices. Thank you.

3 8

Re: [Users] Ovirt engine high availability
by Vincent Van der Kussrn 25 Sep '13

25 Sep '13

----_com.android.email_621583784851887_alt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WW91IGNhbiB1c2UgRFJCRCB3aXRoIGEgY2x1c3RlciBmaWxlc3lzdGVtIG9uIHRvcCBvZiB0aGF0 IHRvIHN0b3JlIHlvdXIgdm0gaW1hZ2UuCgpfVmluY2VudAoKQ29ubmVjdGVkIGJ5IE1vdG9yb2xh CgpEb3VnIEJpc2hvcCA8ZGJpc2hvcEBjb250cm9sc2Nhbi5jb20+IHdyb3RlOgoKPlRob3NlIGFy ZSBnb29kIG9wdGlvbnMsIGhvd2V2ZXIgc2luY2UgSSBhbSBub3QgcnVubmluZyBjZW50cmFsaXpl ZCBzdG9yYWdlLCBhbGwgbXkgaG9zdHMgYXJlIGluIHRoZWlyIG93biBkYXRhIGNlbnRlciB3aXRo IGxvY2FsIHN0b3JhZ2Ugb3B0aW9ucyBvbmx5LiBUaGF0cyB3aHkgSSBoYXZlIHR3byBzdGFuZGFs b25lIG1hY2hpbmVzIHRvIHJ1biBvdmlydCBvbi4gSW0gZ3Vlc3NpbmcgdGhpcyBpcyBub3QgcmVj b21tZW5kZWQ/IElmIG5vdCBpcyB0aGVyZSBhd2F5IHRvIGFsbG93IGxvY2FsIHN0b3JhZ2UgYW5k IG5mcyBiYXNlZCBzdG9yYWdlIGluIGEgZGF0YSBjZW50ZXI/Cj4KPkRvdWcgQmlzaG9wCj5Tci4g U3lzdGVtcyBFbmdpbmVlcgo+Q2VsbDogNjc4LTg0OC02NjU4Cj5kYmlzaG9wQGNvbnRyb2xzY2Fu LmNvbQo+Cj5Db250cm9sc2NhbiwgSW5jLgo+MTE0NzUgR3JlYXQgT2FrcyBXYXksIFN1aXRlIDMw MAo+QWxwaGFyZXR0YSwgR0EgMzAwMjIKPnd3dy5jb250cm9sc2Nhbi5jb20KPgo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+RnJvbTogRGFuIFlhc255IFtkeWFzbnlA Z21haWwuY29tXQo+U2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTMgMTI6MTQgUE0K PlRvOiBEb3VnIEJpc2hvcAo+Q2M6IHVzZXJzQG92aXJ0Lm9yZwo+U3ViamVjdDogUmU6IFtVc2Vy c10gT3ZpcnQgZW5naW5lIGhpZ2ggYXZhaWxhYmlsaXR5Cj4KPlRoZXJlIGFyZSBwbGVudHkgb2Yg b3B0aW9uczoKPjEuIFJ1biB0aGUgZW5naW5lIGFzIGEgVk0gdW5kZXIgYSBsb2NhbCBsaWJ2aXJ0 LCBhbmQgY2x1c3RlciB0aGUgbGlidmlydCBWTSBhcyBhIHByb3RlY3RlZCBzZXJ2aWNlIHVzaW5n IFJIQ1MgKHdlbGwgdGVzdGVkIGFuZCBkb2N1bWVudGVkKQo+Mi4gVXNlIHRoZSBzZWxmIGhvc3Rl ZCBlbmdpbmUgKHJlY2VudGx5IGFubm91bmNlZCwgY29taW5nIHVwIHRlY2gpCj4zLiBVc2UgYW55 IG90aGVyIGNsdXN0ZXJpbmcgdGVjaG5vbG9neSB5b3UgbGlrZSBiZXN0LCBhbiBlbmdpbmUgVk0g d2l0aCBhIGNlbnRyYWxseSBiYWNrZWQgc3RvcmFnZSBpcyB2ZXJ5IGVhc3kgdG8gc3RhcnQgb24g YW55IGNhcGFibGUgaG9zdAo+Cj4KPk9uIFdlZCwgU2VwIDI1LCAyMDEzIGF0IDEwOjA2IEFNLCBE b3VnIEJpc2hvcCA8ZGJpc2hvcEBjb250cm9sc2Nhbi5jb208bWFpbHRvOmRiaXNob3BAY29udHJv bHNjYW4uY29tPj4gd3JvdGU6Cj5IZWxsbywKPgo+V2FzIHdvbmRlcmluZyBpZiBhbnlvbmUgY2Fu IHNoZWQgYSBsaWdodCBvbiB0aGlzIHN1YmplY3QgYXMgSSBjb3VsZCBub3QgZmluZCBhbnkgZG9j dW1lbnRhdGlvbiBzcGVjaWZpYyB0byB0aGlzLiBJIGFtIGN1cnJlbnRseSBydW5uaW5nIGFuIG92 aXJ0IDMuMiBjbHVzdGVyIHdpdGggNSBob3N0cyB3aXRoIGxvY2FsIHN0b3JhZ2UuIEkgaGF2ZSBh IGRlZGljYXRlZCBib3ggcnVubmluZyBvdmlydCBlbmdpbmUuIEkgd291bGQgbGlrZSB0byBoYXZl IHRoZSBhYmlsaXR5IHRvIHJ1biBhbiBhZGRpdGlvbmFsIGJveCB3aXRoIG92aXJ0IGVuZ2luZSBv biBpdCBmb3IgaGlnaCBhdmFpbGFiaWxpdHkgb2YgdGhlIHBvcnRhbC4gSSByZWFsaXplIHRoaXMg d291bGQgbW9zdCBsaWtlbHkgcmVxdWlyZSBJIHJ1biBhIHNlcGFyYXRlIGluc3RhbmNlIG9mIHBv c3RncmVzIGZvciB0aGUgZW5naW5lLCBob3dldmVyIEkgd2FzIHdvbmRlcmluZyBpZiB0aGlzIGlz IHNvbWV0aGluZyB0aGF0IGlzIG9mZmljaWFsbHkgc3VwcG9ydGVkPwo+Cj5UaGFua3MhCj4KPkRv dWcgQmlzaG9wCj5Tci4gU3lzdGVtcyBFbmdpbmVlcgo+ZGJpc2hvcEBjb250cm9sc2Nhbi5jb208 bWFpbHRvOmRiaXNob3BAY29udHJvbHNjYW4uY29tPgo+Cj5Db250cm9sc2NhbiwgSW5jLgo+MTE0 NzUgR3JlYXQgT2FrcyBXYXksIFN1aXRlIDMwMAo+QWxwaGFyZXR0YSwgR0EgMzAwMjIKPnd3dy5j b250cm9sc2Nhbi5jb208aHR0cDovL3d3dy5jb250cm9sc2Nhbi5jb20+Cj4KPk5PVElDRTogIFRo aXMgZS1tYWlsIG1lc3NhZ2UsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMsIGlzIGZvciB0aGUg c29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBvciBlbnRpdHkgYW5kIG1heSBj b250YWluIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiB0aGF0IGlzIGNvbmZpZGVudGlhbCwgcHJvcHJp ZXRhcnksIHByaXZpbGVnZWQgb3Igb3RoZXJ3aXNlIHByb3RlY3RlZCBieSBsYXcuIEFueSB1bmF1 dGhvcml6ZWQgcmV2aWV3LCB1c2UsIGRpc2Nsb3N1cmUsIGRpc3RyaWJ1dGlvbiwgY29weWluZyBv ciBvdGhlciB1c2Ugb2YsIG9yIHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24s IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0 cm95IGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLiBUaGlzIGUtbWFpbCBpcyBhbmQgYW55IHJl c3BvbnNlIHRvIGl0IHdpbGwgYmUgdW5lbmNyeXB0ZWQgYW5kLCB0aGVyZWZvcmUsIHBvdGVudGlh bGx5IHVuc2VjdXJlLiAgVGhlIHJlY2lwaWVudCBzaG91bGQgY2hlY2sgdGhpcyBlbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGZvciB0aGUgcHJlc2VuY2Ugb2YgdmlydXNlcy9tYWx3YXJlIGFjY29y ZGluZyB0byBzZWN1cml0eSBiZXN0IHByYWN0aWNlcy4gIFRoYW5rIHlvdS4KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj5Vc2VycyBtYWlsaW5nIGxpc3QK PlVzZXJzQG92aXJ0Lm9yZzxtYWlsdG86VXNlcnNAb3ZpcnQub3JnPgo+aHR0cDovL2xpc3RzLm92 aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzCj4KPgo+Tk9USUNFOiAgVGhpcyBlLW1haWwg bWVzc2FnZSwgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cywgaXMgZm9yIHRoZSBzb2xlIHVzZSBv ZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIG9yIGVudGl0eSBhbmQgbWF5IGNvbnRhaW4gc2Vu c2l0aXZlIGluZm9ybWF0aW9uIHRoYXQgaXMgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgcHJp dmlsZWdlZCBvciBvdGhlcndpc2UgcHJvdGVjdGVkIGJ5IGxhdy4gQW55IHVuYXV0aG9yaXplZCBy ZXZpZXcsIHVzZSwgZGlzY2xvc3VyZSwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nIG9yIG90aGVyIHVz ZSBvZiwgb3IgdGFraW5nIG9mIGFueSBhY3Rpb24gaW4gcmVsaWFuY2UgdXBvbiwgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNv cGllcyBvZiB0aGlzIG1lc3NhZ2UuIFRoaXMgZS1tYWlsIGlzIGFuZCBhbnkgcmVzcG9uc2UgdG8g aXQgd2lsbCBiZSB1bmVuY3J5cHRlZCBhbmQsIHRoZXJlZm9yZSwgcG90ZW50aWFsbHkgdW5zZWN1 cmUuICBUaGUgcmVjaXBpZW50IHNob3VsZCBjaGVjayB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgZm9yIHRoZSBwcmVzZW5jZSBvZiB2aXJ1c2VzL21hbHdhcmUgYWNjb3JkaW5nIHRvIHNl Y3VyaXR5IGJlc3QgcHJhY3RpY2VzLiAgVGhhbmsgeW91Lgo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPlVzZXJzIG1haWxpbmcgbGlzdAo+VXNlcnNAb3Zp cnQub3JnCj5odHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnMK ----_com.android.email_621583784851887_alt Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdj48ZGl2PllvdSBjYW4gdXNlIERSQkQgd2l0aCBhIGNsdXN0ZXIgZmlsZXN5c3RlbSBvbiB0 b3Agb2YgdGhhdCB0byBzdG9yZSB5b3VyIHZtIGltYWdlLjwvZGl2PjxkaXY+PGJyLz48L2Rpdj48 ZGl2Pl9WaW5jZW50PC9kaXY+PGRpdj48YnIvPjwvZGl2PjxkaXY+PGZvbnQgc3R5bGU9ImNvbG9y OiMzMzMzMzMiPjxpPkNvbm5lY3RlZCBieSBNb3Rvcm9sYTwvaT48L2ZvbnQ+PC9kaXY+PC9kaXY+ PGJyPjxicj5Eb3VnIEJpc2hvcCAmbHQ7ZGJpc2hvcEBjb250cm9sc2Nhbi5jb20mZ3Q7IHdyb3Rl Ojxicj48YnI+VGhvc2UgYXJlIGdvb2Qgb3B0aW9ucywgaG93ZXZlciBzaW5jZSBJIGFtIG5vdCBy dW5uaW5nIGNlbnRyYWxpemVkIHN0b3JhZ2UsIGFsbCBteSBob3N0cyBhcmUgaW4gdGhlaXIgb3du IGRhdGEgY2VudGVyIHdpdGggbG9jYWwgc3RvcmFnZSBvcHRpb25zIG9ubHkuIFRoYXRzIHdoeSBJ IGhhdmUgdHdvIHN0YW5kYWxvbmUgbWFjaGluZXMgdG8gcnVuIG92aXJ0IG9uLiBJbSBndWVzc2lu ZyB0aGlzIGlzIG5vdCByZWNvbW1lbmRlZD8gSWYgbm90IGlzIHRoZXJlIGF3YXkgdG8gYWxsb3cg bG9jYWwgc3RvcmFnZSBhbmQgbmZzIGJhc2VkIHN0b3JhZ2UgaW4gYSBkYXRhIGNlbnRlcj88YnI+ PGJyPkRvdWcgQmlzaG9wPGJyPlNyLiBTeXN0ZW1zIEVuZ2luZWVyPGJyPkNlbGw6IDY3OC04NDgt NjY1ODxicj5kYmlzaG9wQGNvbnRyb2xzY2FuLmNvbTxicj48YnI+Q29udHJvbHNjYW4sIEluYy48 YnI+MTE0NzUgR3JlYXQgT2FrcyBXYXksIFN1aXRlIDMwMDxicj5BbHBoYXJldHRhLCBHQSAzMDAy Mjxicj53d3cuY29udHJvbHNjYW4uY29tPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPkZyb206IERhbiBZYXNueSBbZHlhc255QGdtYWlsLmNvbV08YnI+ U2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTMgMTI6MTQgUE08YnI+VG86IERvdWcg QmlzaG9wPGJyPkNjOiB1c2Vyc0BvdmlydC5vcmc8YnI+U3ViamVjdDogUmU6IFtVc2Vyc10gT3Zp cnQgZW5naW5lIGhpZ2ggYXZhaWxhYmlsaXR5PGJyPjxicj5UaGVyZSBhcmUgcGxlbnR5IG9mIG9w dGlvbnM6PGJyPjEuIFJ1biB0aGUgZW5naW5lIGFzIGEgVk0gdW5kZXIgYSBsb2NhbCBsaWJ2aXJ0 LCBhbmQgY2x1c3RlciB0aGUgbGlidmlydCBWTSBhcyBhIHByb3RlY3RlZCBzZXJ2aWNlIHVzaW5n IFJIQ1MgKHdlbGwgdGVzdGVkIGFuZCBkb2N1bWVudGVkKTxicj4yLiBVc2UgdGhlIHNlbGYgaG9z dGVkIGVuZ2luZSAocmVjZW50bHkgYW5ub3VuY2VkLCBjb21pbmcgdXAgdGVjaCk8YnI+My4gVXNl IGFueSBvdGhlciBjbHVzdGVyaW5nIHRlY2hub2xvZ3kgeW91IGxpa2UgYmVzdCwgYW4gZW5naW5l IFZNIHdpdGggYSBjZW50cmFsbHkgYmFja2VkIHN0b3JhZ2UgaXMgdmVyeSBlYXN5IHRvIHN0YXJ0 IG9uIGFueSBjYXBhYmxlIGhvc3Q8YnI+PGJyPjxicj5PbiBXZWQsIFNlcCAyNSwgMjAxMyBhdCAx MDowNiBBTSwgRG91ZyBCaXNob3AgJmx0O2RiaXNob3BAY29udHJvbHNjYW4uY29tJmx0O21haWx0 bzpkYmlzaG9wQGNvbnRyb2xzY2FuLmNvbSZndDsmZ3Q7IHdyb3RlOjxicj5IZWxsbyw8YnI+PGJy PldhcyB3b25kZXJpbmcgaWYgYW55b25lIGNhbiBzaGVkIGEgbGlnaHQgb24gdGhpcyBzdWJqZWN0 IGFzIEkgY291bGQgbm90IGZpbmQgYW55IGRvY3VtZW50YXRpb24gc3BlY2lmaWMgdG8gdGhpcy4g SSBhbSBjdXJyZW50bHkgcnVubmluZyBhbiBvdmlydCAzLjIgY2x1c3RlciB3aXRoIDUgaG9zdHMg d2l0aCBsb2NhbCBzdG9yYWdlLiBJIGhhdmUgYSBkZWRpY2F0ZWQgYm94IHJ1bm5pbmcgb3ZpcnQg ZW5naW5lLiBJIHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGUgYWJpbGl0eSB0byBydW4gYW4gYWRkaXRp b25hbCBib3ggd2l0aCBvdmlydCBlbmdpbmUgb24gaXQgZm9yIGhpZ2ggYXZhaWxhYmlsaXR5IG9m IHRoZSBwb3J0YWwuIEkgcmVhbGl6ZSB0aGlzIHdvdWxkIG1vc3QgbGlrZWx5IHJlcXVpcmUgSSBy dW4gYSBzZXBhcmF0ZSBpbnN0YW5jZSBvZiBwb3N0Z3JlcyBmb3IgdGhlIGVuZ2luZSwgaG93ZXZl ciBJIHdhcyB3b25kZXJpbmcgaWYgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCBpcyBvZmZpY2lhbGx5 IHN1cHBvcnRlZD88YnI+PGJyPlRoYW5rcyE8YnI+PGJyPkRvdWcgQmlzaG9wPGJyPlNyLiBTeXN0 ZW1zIEVuZ2luZWVyPGJyPmRiaXNob3BAY29udHJvbHNjYW4uY29tJmx0O21haWx0bzpkYmlzaG9w QGNvbnRyb2xzY2FuLmNvbSZndDs8YnI+PGJyPkNvbnRyb2xzY2FuLCBJbmMuPGJyPjExNDc1IEdy ZWF0IE9ha3MgV2F5LCBTdWl0ZSAzMDA8YnI+QWxwaGFyZXR0YSwgR0EgMzAwMjI8YnI+d3d3LmNv bnRyb2xzY2FuLmNvbSZsdDtodHRwOi8vd3d3LmNvbnRyb2xzY2FuLmNvbSZndDs8YnI+PGJyPk5P VElDRTombmJzcDsgVGhpcyBlLW1haWwgbWVzc2FnZSwgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50 cywgaXMgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIG9yIGVu dGl0eSBhbmQgbWF5IGNvbnRhaW4gc2Vuc2l0aXZlIGluZm9ybWF0aW9uIHRoYXQgaXMgY29uZmlk ZW50aWFsLCBwcm9wcmlldGFyeSwgcHJpdmlsZWdlZCBvciBvdGhlcndpc2UgcHJvdGVjdGVkIGJ5 IGxhdy4gQW55IHVuYXV0aG9yaXplZCByZXZpZXcsIHVzZSwgZGlzY2xvc3VyZSwgZGlzdHJpYnV0 aW9uLCBjb3B5aW5nIG9yIG90aGVyIHVzZSBvZiwgb3IgdGFraW5nIG9mIGFueSBhY3Rpb24gaW4g cmVsaWFuY2UgdXBvbiwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBseSBl LW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuIFRoaXMgZS1tYWls IGlzIGFuZCBhbnkgcmVzcG9uc2UgdG8gaXQgd2lsbCBiZSB1bmVuY3J5cHRlZCBhbmQsIHRoZXJl Zm9yZSwgcG90ZW50aWFsbHkgdW5zZWN1cmUuJm5ic3A7IFRoZSByZWNpcGllbnQgc2hvdWxkIGNo ZWNrIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBmb3IgdGhlIHByZXNlbmNlIG9mIHZp cnVzZXMvbWFsd2FyZSBhY2NvcmRpbmcgdG8gc2VjdXJpdHkgYmVzdCBwcmFjdGljZXMuJm5ic3A7 IFRoYW5rIHlvdS48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+VXNlcnMgbWFpbGluZyBsaXN0PGJyPlVzZXJzQG92aXJ0Lm9yZyZsdDttYWlsdG86 VXNlcnNAb3ZpcnQub3JnJmd0Ozxicj5odHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlz dGluZm8vdXNlcnM8YnI+PGJyPjxicj5OT1RJQ0U6Jm5ic3A7IFRoaXMgZS1tYWlsIG1lc3NhZ2Us IGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMsIGlzIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGlu dGVuZGVkIHJlY2lwaWVudChzKSBvciBlbnRpdHkgYW5kIG1heSBjb250YWluIHNlbnNpdGl2ZSBp bmZvcm1hdGlvbiB0aGF0IGlzIGNvbmZpZGVudGlhbCwgcHJvcHJpZXRhcnksIHByaXZpbGVnZWQg b3Igb3RoZXJ3aXNlIHByb3RlY3RlZCBieSBsYXcuIEFueSB1bmF1dGhvcml6ZWQgcmV2aWV3LCB1 c2UsIGRpc2Nsb3N1cmUsIGRpc3RyaWJ1dGlvbiwgY29weWluZyBvciBvdGhlciB1c2Ugb2YsIG9y IHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24sIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250 YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2Yg dGhpcyBtZXNzYWdlLiBUaGlzIGUtbWFpbCBpcyBhbmQgYW55IHJlc3BvbnNlIHRvIGl0IHdpbGwg YmUgdW5lbmNyeXB0ZWQgYW5kLCB0aGVyZWZvcmUsIHBvdGVudGlhbGx5IHVuc2VjdXJlLiZuYnNw OyBUaGUgcmVjaXBpZW50IHNob3VsZCBjaGVjayB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgZm9yIHRoZSBwcmVzZW5jZSBvZiB2aXJ1c2VzL21hbHdhcmUgYWNjb3JkaW5nIHRvIHNlY3Vy aXR5IGJlc3QgcHJhY3RpY2VzLiZuYnNwOyBUaGFuayB5b3UuPGJyPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPlVzZXJzIG1haWxpbmcgbGlzdDxicj5V c2Vyc0BvdmlydC5vcmc8YnI+aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZv L3VzZXJzPGJyPg== ----_com.android.email_621583784851887_alt--

1 0

[Users] vdsm Domain monitor error
by Eduardo Ramos 25 Sep '13

25 Sep '13

This is a multi-part message in MIME format. --------------080600090601070500080703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all! I'm getting a strange error in on my SPM: Message from syslogd@darwin at Sep 24 11:19:58 ... ?<11>vdsm Storage.DomainMonitorThread ERROR Error while collecting domain 0226b818-59a6-41bc-8590-91f520aa7859 monitoring information#012Traceback (most recent call last):#012 File "/usr/share/vdsm/storage/domainMonitor.py", line 182, in _monitorDomain#012 self.domain = sdCache.produce(self.sdUUID)#012 File "/usr/share/vdsm/storage/sdc.py", line 97, in produce#012 domain.getRealDomain()#012 File "/usr/share/vdsm/storage/sdc.py", line 52, in getRealDomain#012 return self._cache._realProduce(self._sdUUID)#012 File "/usr/share/vdsm/storage/sdc.py", line 121, in _realProduce#012 domain = self._findDomain(sdUUID)#012 File "/usr/share/vdsm/storage/sdc.py", line 152, in _findDomain#012 raise se.StorageDomainDoesNotExist(sdUUID)#012StorageDomainDoesNotExist: Storage domain does not exist: (u'0226b818-59a6-41bc-8590-91f520aa7859',) I also can not remove disks. When I try,immediatly appears on the 'Events' log of webadmin: *Data Center is being initialized, please wait for initialization to complete.* *User eduardo.ramos failed to initiate removing of disk 012.167_teste_InfoDoc_Disk1 from domain VMs.* Could someone help me? Thanks --------------080600090601070500080703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> <tt>Hi all!<br> <br> I'm getting a strange error in on my SPM:<br> <br> Message from syslogd@darwin at Sep 24 11:19:58 ...</tt><tt><br> </tt><tt> �<11>vdsm Storage.DomainMonitorThread ERROR Error while collecting domain 0226b818-59a6-41bc-8590-91f520aa7859 monitoring information#012Traceback (most recent call last):#012  File "/usr/share/vdsm/storage/domainMonitor.py", line 182, in _monitorDomain#012    self.domain = sdCache.produce(self.sdUUID)#012  File "/usr/share/vdsm/storage/sdc.py", line 97, in produce#012    domain.getRealDomain()#012  File "/usr/share/vdsm/storage/sdc.py", line 52, in getRealDomain#012    return self._cache._realProduce(self._sdUUID)#012  File "/usr/share/vdsm/storage/sdc.py", line 121, in _realProduce#012    domain = self._findDomain(sdUUID)#012  File "/usr/share/vdsm/storage/sdc.py", line 152, in _findDomain#012    raise se.StorageDomainDoesNotExist(sdUUID)#012StorageDomainDoesNotExist: Storage domain does not exist: (u'0226b818-59a6-41bc-8590-91f520aa7859',)<br> <br> I also can not remove disks. When I try,immediatly appears on the 'Events' log of webadmin:<br> <br> </tt> <div title="" style="outline: medium none;"> <div id="gwt-uid-1428_col2_row0"><tt>*Data Center is being initialized, please wait for initialization to complete.*<br> *</tt><tt>User eduardo.ramos failed to initiate removing of disk 012.167_teste_InfoDoc_Disk1 from domain VMs.*<br> <br> Could someone help me?<br> <br> Thanks<br> </tt></div> </div> </body> </html> --------------080600090601070500080703--

2 4