[Users] Migration Failed

Tom Brown tom at ng23.net
Mon Jan 13 14:07:15 UTC 2014


selinux issue?


On 13 January 2014 12:48, Michal Skrivanek <michal.skrivanek at redhat.com>wrote:

>
> On Jan 13, 2014, at 11:37 , Neil <nwilson123 at gmail.com> wrote:
>
> > Good morning everyone,
> >
> > Sorry to trouble you again, anyone have any ideas on what to try next?
>
> Hi Neil,
> hm, other than noise I don't really see any failures in migration.
> Can you attach both src and dst vdsm log with a hint which VM and at what
> time approx it failed for you?
> There are errors for one volume reoccuring all the time, but that doesn't
> look related to the migration
>
> Thanks,
> michal
>
> >
> > Thank you so much,
> >
> > Regards.
> >
> > Neil Wilson.
> >
> > On Fri, Jan 10, 2014 at 8:31 AM, Neil <nwilson123 at gmail.com> wrote:
> >> Hi Dafna,
> >>
> >> Apologies for the late reply, I was out of my office yesterday.
> >>
> >> Just to get back to you on your questions.
> >>
> >> can you look at the vm dialogue and see what boot devices the vm has?
> >> Sorry I'm not sure where you want me to get this info from? Inside the
> >> ovirt GUI or on the VM itself.
> >> The VM has one 2TB LUN assigned. Then inside the VM this is the fstab
> >> parameters..
> >>
> >> [root at tux ~]# cat /etc/fstab
> >> /dev/VolGroup00/LogVol00 /                       ext3    defaults
>  1 0
> >> /dev/vda1             /boot                   ext3    defaults        1
> 0
> >> tmpfs                   /dev/shm                tmpfs   defaults
>  0 0
> >> devpts                  /dev/pts                devpts  gid=5,mode=620
>  0 0
> >> sysfs                   /sys                    sysfs   defaults
>  0 0
> >> proc                    /proc                   proc    defaults
>  0 0
> >> /dev/VolGroup00/LogVol01 swap                    swap    defaults
>  0 0
> >> /dev/VolGroup00/LogVol02 /homes                      xfs
> >> defaults,usrquota,grpquota        1 0
> >>
> >>
> >> can you write to the vm?
> >> Yes the machine is fully functioning, it's their main PDC and hosts
> >> all of their files.
> >>
> >>
> >> can you please dump the vm xml from libvirt? (it's one of the commands
> >> that you have in virsh)
> >>
> >> Below is the xml
> >>
> >> <domain type='kvm' id='7'>
> >>  <name>tux</name>
> >>  <uuid>2736197b-6dc3-4155-9a29-9306ca64881d</uuid>
> >>  <memory unit='KiB'>8388608</memory>
> >>  <currentMemory unit='KiB'>8388608</currentMemory>
> >>  <vcpu placement='static'>4</vcpu>
> >>  <cputune>
> >>    <shares>1020</shares>
> >>  </cputune>
> >>  <sysinfo type='smbios'>
> >>    <system>
> >>      <entry name='manufacturer'>oVirt</entry>
> >>      <entry name='product'>oVirt Node</entry>
> >>      <entry name='version'>6-4.el6.centos.10</entry>
> >>      <entry name='serial'>4C4C4544-0038-5310-8050-C6C04F34354A</entry>
> >>      <entry name='uuid'>2736197b-6dc3-4155-9a29-9306ca64881d</entry>
> >>    </system>
> >>  </sysinfo>
> >>  <os>
> >>    <type arch='x86_64' machine='rhel6.4.0'>hvm</type>
> >>    <smbios mode='sysinfo'/>
> >>  </os>
> >>  <features>
> >>    <acpi/>
> >>  </features>
> >>  <cpu mode='custom' match='exact'>
> >>    <model fallback='allow'>Westmere</model>
> >>    <topology sockets='1' cores='4' threads='1'/>
> >>  </cpu>
> >>  <clock offset='variable' adjustment='0' basis='utc'>
> >>    <timer name='rtc' tickpolicy='catchup'/>
> >>  </clock>
> >>  <on_poweroff>destroy</on_poweroff>
> >>  <on_reboot>restart</on_reboot>
> >>  <on_crash>destroy</on_crash>
> >>  <devices>
> >>    <emulator>/usr/libexec/qemu-kvm</emulator>
> >>    <disk type='file' device='cdrom'>
> >>      <driver name='qemu' type='raw'/>
> >>      <source startupPolicy='optional'/>
> >>      <target dev='hdc' bus='ide'/>
> >>      <readonly/>
> >>      <serial></serial>
> >>      <alias name='ide0-1-0'/>
> >>      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
> >>    </disk>
> >>    <disk type='block' device='disk' snapshot='no'>
> >>      <driver name='qemu' type='raw' cache='none' error_policy='stop'
> >> io='native'/>
> >>      <source
> dev='/rhev/data-center/28adaf38-a4f6-11e1-a859-cb68949043e4/0e6991ae-6238-4c61-96d2-ca8fed35161e/images/fd1a562a-3ba5-4ddb-a643-37912a6ae86f/f747ba2b-98e1-47f5-805b-6bb173bfd6ff'/>
> >>      <target dev='vda' bus='virtio'/>
> >>      <serial>fd1a562a-3ba5-4ddb-a643-37912a6ae86f</serial>
> >>      <boot order='1'/>
> >>      <alias name='virtio-disk0'/>
> >>      <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
> >> function='0x0'/>
> >>    </disk>
> >>    <controller type='ide' index='0'>
> >>      <alias name='ide0'/>
> >>      <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
> >> function='0x1'/>
> >>    </controller>
> >>    <controller type='virtio-serial' index='0'>
> >>      <alias name='virtio-serial0'/>
> >>      <address type='pci' domain='0x0000' bus='0x00' slot='0x04'
> >> function='0x0'/>
> >>    </controller>
> >>    <controller type='usb' index='0'>
> >>      <alias name='usb0'/>
> >>      <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
> >> function='0x2'/>
> >>    </controller>
> >>    <interface type='bridge'>
> >>      <mac address='00:1a:4a:a8:7a:00'/>
> >>      <source bridge='ovirtmgmt'/>
> >>      <target dev='vnet5'/>
> >>      <model type='virtio'/>
> >>      <filterref filter='vdsm-no-mac-spoofing'/>
> >>      <link state='up'/>
> >>      <alias name='net0'/>
> >>      <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
> >> function='0x0'/>
> >>    </interface>
> >>    <channel type='unix'>
> >>      <source mode='bind'
> >> path='/var/lib/libvirt/qemu/channels/tux.com.redhat.rhevm.vdsm'/>
> >>      <target type='virtio' name='com.redhat.rhevm.vdsm'/>
> >>      <alias name='channel0'/>
> >>      <address type='virtio-serial' controller='0' bus='0' port='1'/>
> >>    </channel>
> >>    <channel type='unix'>
> >>      <source mode='bind'
> >> path='/var/lib/libvirt/qemu/channels/tux.org.qemu.guest_agent.0'/>
> >>      <target type='virtio' name='org.qemu.guest_agent.0'/>
> >>      <alias name='channel1'/>
> >>      <address type='virtio-serial' controller='0' bus='0' port='2'/>
> >>    </channel>
> >>    <channel type='spicevmc'>
> >>      <target type='virtio' name='com.redhat.spice.0'/>
> >>      <alias name='channel2'/>
> >>      <address type='virtio-serial' controller='0' bus='0' port='3'/>
> >>    </channel>
> >>    <input type='mouse' bus='ps2'/>
> >>    <graphics type='spice' port='5912' tlsPort='5913' autoport='yes'
> >> listen='0' keymap='en-us' passwdValidTo='2013-09-20T07:56:54'
> >> connected='disconnect'>
> >>      <listen type='address' address='0'/>
> >>      <channel name='main' mode='secure'/>
> >>      <channel name='display' mode='secure'/>
> >>      <channel name='inputs' mode='secure'/>
> >>      <channel name='cursor' mode='secure'/>
> >>      <channel name='playback' mode='secure'/>
> >>      <channel name='record' mode='secure'/>
> >>      <channel name='smartcard' mode='secure'/>
> >>      <channel name='usbredir' mode='secure'/>
> >>    </graphics>
> >>    <video>
> >>      <model type='qxl' ram='65536' vram='65536' heads='1'/>
> >>      <alias name='video0'/>
> >>      <address type='pci' domain='0x0000' bus='0x00' slot='0x02'
> >> function='0x0'/>
> >>    </video>
> >>    <memballoon model='virtio'>
> >>      <alias name='balloon0'/>
> >>      <address type='pci' domain='0x0000' bus='0x00' slot='0x06'
> >> function='0x0'/>
> >>    </memballoon>
> >>  </devices>
> >>  <seclabel type='none'/>
> >> </domain>
> >>
> >> Thank you very much for your help.
> >>
> >> Regards.
> >>
> >> Neil Wilson.
> >>
> >>
> >>
> >> On Wed, Jan 8, 2014 at 4:55 PM, Dafna Ron <dron at redhat.com> wrote:
> >>> Hi Neil,
> >>>
> >>> the error in the log suggests that the vm is missing a disk...
> >>> can you look at the vm dialogue and see what boot devices the vm has?
> >>> can you write to the vm?
> >>> can you please dump the vm xml from libvirt? (it's one of the commands
> that
> >>> you have in virsh)
> >>>
> >>> Thanks,
> >>>
> >>> Dafna
> >>>
> >>>
> >>>
> >>> On 01/08/2014 02:42 PM, Neil wrote:
> >>>>
> >>>> Hi guys,
> >>>>
> >>>> Apologies for the late reply.
> >>>>
> >>>> The VM (Tux) was created about 2 years ago, it was converted from a
> >>>> physical machine using Clonezilla. It's been migrated a number of
> >>>> times in the past, only now when trying to move it off node03 is it
> >>>> giving this error.
> >>>>
> >>>> I've looked for any attached images/cd's and found none unfortunately.
> >>>>
> >>>> Thank you so much for your assistance so far.
> >>>>
> >>>> Regards.
> >>>>
> >>>> Neil Wilson.
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Jan 8, 2014 at 12:23 PM, Dafna Ron <dron at redhat.com> wrote:
> >>>>>
> >>>>> Thread-847747::INFO::2014-01-07
> >>>>> 14:30:32,353::logUtils::44::dispatcher::(wrapper) Run and protect:
> >>>>> inappropriateDevices(thiefId='63da7faa-f92a-4652-90f2-b6660a4fb7b3')
> >>>>> Thread-847747::INFO::2014-01-07
> >>>>> 14:30:32,354::logUtils::47::dispatcher::(wrapper) Run and protect:
> >>>>> inappropriateDevices, Return response: None
> >>>>>
> >>>>> Please check if the vm's were booted with a cd...
> >>>>>
> >>>>>
> >>>>> bject at 0x7fb1f00cbbd0>> log:<logUtils.SimpleLogAdapter instance at
> >>>>> 0x7fb1f00be7e8> name:hdc networkDev:False path: readonly:True
> reqsize:0
> >>>>> serial: truesize:0 *type:cdrom* volExtensionChunk:1024
> >>>>> watermarkLimit:536870912
> >>>>>
> >>>>> Traceback (most recent call last):
> >>>>>   File "/usr/share/vdsm/clientIF.py", line 356, in teardownVolumePath
> >>>>>     res = self.irs.teardownImage(drive['domainID'],
> >>>>>   File "/usr/share/vdsm/vm.py", line 1386, in __getitem__
> >>>>>     raise KeyError(key)
> >>>>> KeyError: 'domainID'
> >>>>> Thread-847747::WARNING::2014-01-07
> >>>>> 14:30:32,351::clientIF::362::vds::(teardownVolumePath) Drive is not a
> >>>>> vdsm
> >>>>> image: VOLWM_CHUNK_MB:1024 VOLWM_CHUNK_REPLICATE_MULT:2
> VOLWM_FREE_PCT:50
> >>>>> _blockDev:True _checkIoTuneCategories:<bound method D
> >>>>> rive._checkIoTuneCategories of <vm.Drive object at 0x7fb1f00cbc10>>
> >>>>> _customize:<bound method Drive._customize of <vm.Drive object at
> >>>>> 0x7fb1f00cbc10>> _deviceXML:<disk device="disk" snapshot="no"
> >>>>> type="block">
> >>>>>       <driver cache="none" error_policy="stop" io="native"
> name="qemu"
> >>>>> type="raw"/>
> >>>>>       <source
> >>>>>
> >>>>>
> dev="/rhev/data-center/28adaf38-a4f6-11e1-a859-cb68949043e4/0e6991ae-6238-4c61-96d2-ca8fed35161e/images/9f16f896-1da3-4f9a-a305-ac9c4f51a482/e04c6600-abb9-4ebc-a9b3-77b6c536e258"/>
> >>>>>       <target bus="ide" dev="hda"/>
> >>>>> <serial>9f16f896-1da3-4f9a-a305-ac9c4f51a482</serial>
> >>>>>       <alias name="ide0-0-0"/>
> >>>>>       <address bus="0" controller="0" target="0" type="drive"
> unit="0"/>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 01/08/2014 06:28 AM, Neil wrote:
> >>>>>>
> >>>>>> Hi Dafna,
> >>>>>>
> >>>>>> Thanks for the reply.
> >>>>>>
> >>>>>> Attached is the log from the source server (node03).
> >>>>>>
> >>>>>> I'll reply to your other questions as soon as I'm back in the office
> >>>>>> this afternoon, have to run off to a meeting.
> >>>>>>
> >>>>>> Regards.
> >>>>>>
> >>>>>> Neil Wilson.
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Jan 7, 2014 at 8:13 PM, Dafna Ron <dron at redhat.com> wrote:
> >>>>>>>
> >>>>>>> Ok... several things :)
> >>>>>>>
> >>>>>>> 1. for migration we need to see vdsm logs from both src and dst.
> >>>>>>>
> >>>>>>> 2. Is it possible that the vm has an iso attached? because I see
> that
> >>>>>>> you
> >>>>>>> are having problems with the iso domain:
> >>>>>>>
> >>>>>>> 2014-01-07 14:26:27,714 ERROR
> >>>>>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand]
> >>>>>>> (pool-6-thread-48) Domain
> e9ab725d-69c1-4a59-b225-b995d095c289:bla-iso
> >>>>>>> was
> >>>>>>> reported with error code 358
> >>>>>>>
> >>>>>>>
> >>>>>>> Thread-1165153::DEBUG::2014-01-07
> >>>>>>> 13:39:42,460::libvirtconnection::108::libvirtconnection::(wrapper)
> >>>>>>> Unknown
> >>>>>>> libvirterror: ecode: 42 edom: 10 level: 2 message: Domain not
> found: no
> >>>>>>> domain with matching uuid '63da7faa-f92a-4652-90f2-b6660a4fb7b3'
> >>>>>>>
> >>>>>>> hread-19::ERROR::2014-01-07
> >>>>>>> 13:01:02,621::sdc::143::Storage.StorageDomainCache::(_findDomain)
> >>>>>>> domain
> >>>>>>> e9ab725d-69c1-4a59-b225-b995d095c289 not found
> >>>>>>> Traceback (most recent call last):
> >>>>>>>    File "/usr/share/vdsm/storage/sdc.py", line 141, in _findDomain
> >>>>>>>      dom = findMethod(sdUUID)
> >>>>>>>    File "/usr/share/vdsm/storage/sdc.py", line 171, in
> >>>>>>> _findUnfetchedDomain
> >>>>>>>      raise se.StorageDomainDoesNotExist(sdUUID)
> >>>>>>> StorageDomainDoesNotExist: Storage domain does not exist:
> >>>>>>> (u'e9ab725d-69c1-4a59-b225-b995d095c289',)
> >>>>>>> Thread-19::ERROR::2014-01-07
> >>>>>>>
> >>>>>>>
> >>>>>>>
> 13:01:02,622::domainMonitor::225::Storage.DomainMonitorThread::(_monitorDomain)
> >>>>>>> Error while collecting domain e9ab725d-69c1-4a59-b225-b995d095c289
> >>>>>>> monitoring information
> >>>>>>> Traceback (most recent call last):
> >>>>>>>    File "/usr/share/vdsm/storage/domainMonitor.py", line 190, in
> >>>>>>> _monitorDomain
> >>>>>>>      self.domain = sdCache.produce(self.sdUUID)
> >>>>>>>    File "/usr/share/vdsm/storage/sdc.py", line 98, in produce
> >>>>>>>      domain.getRealDomain()
> >>>>>>>    File "/usr/share/vdsm/storage/sdc.py", line 52, in getRealDomain
> >>>>>>>      return self._cache._realProduce(self._sdUUID)
> >>>>>>>    File "/usr/share/vdsm/storage/sdc.py", line 122, in _realProduce
> >>>>>>>      domain = self._findDomain(sdUUID)
> >>>>>>>    File "/usr/share/vdsm/storage/sdc.py", line 141, in _findDomain
> >>>>>>>      dom = findMethod(sdUUID)
> >>>>>>>    File "/usr/share/vdsm/storage/sdc.py", line 171, in
> >>>>>>> _findUnfetchedDomain
> >>>>>>>      raise se.StorageDomainDoesNotExist(sdUUID)
> >>>>>>> StorageDomainDoesNotExist: Storage domain does not exist:
> >>>>>>> (u'e9ab725d-69c1-4a59-b225-b995d095c289',)
> >>>>>>> Dummy-29013::DEBUG::2014-01-07
> >>>>>>>
> >>>>>>>
> 13:01:03,507::storage_mailbox::733::Storage.Misc.excCmd::(_checkForMail)
> >>>>>>> 'dd
> >>>>>>>
> >>>>>>>
> >>>>>>>
> if=/rhev/data-center/28adaf38-a4f6-11e1-a859-cb68949043e4/mastersd/dom_md/inbox
> >>>>>>> iflag=direct,fullblock count=1 bs=1024000' (cwd N
> >>>>>>> one)
> >>>>>>>
> >>>>>>> 3. The migration fails with libvirt error but we need the trace
> from
> >>>>>>> the
> >>>>>>> second log:
> >>>>>>>
> >>>>>>> Thread-1165153::DEBUG::2014-01-07
> >>>>>>> 13:39:42,451::sampling::292::vm.Vm::(stop)
> >>>>>>> vmId=`63da7faa-f92a-4652-90f2-b6660a4fb7b3`::Stop statistics
> collection
> >>>>>>> Thread-1163583::DEBUG::2014-01-07
> >>>>>>> 13:39:42,452::sampling::323::vm.Vm::(run)
> >>>>>>> vmId=`63da7faa-f92a-4652-90f2-b6660a4fb7b3`::Stats thread finished
> >>>>>>> Thread-1165153::DEBUG::2014-01-07
> >>>>>>> 13:39:42,460::libvirtconnection::108::libvirtconnection::(wrapper)
> >>>>>>> Unknown
> >>>>>>> libvirterror: ecode: 42 edom: 10 level: 2 message: Domain not
> found: no
> >>>>>>> domain with matching uuid '63da7faa-f92a-4652-90f2-b6660
> >>>>>>> a4fb7b3'
> >>>>>>>
> >>>>>>>
> >>>>>>> 4. But I am worried about this and would more info about this vm...
> >>>>>>>
> >>>>>>> Thread-247::ERROR::2014-01-07
> >>>>>>> 15:35:14,868::sampling::355::vm.Vm::(collect)
> >>>>>>> vmId=`63da7faa-f92a-4652-90f2-b6660a4fb7b3`::Stats function failed:
> >>>>>>> <AdvancedStatsFunction _highWrite at 0x2ce0998>
> >>>>>>> Traceback (most recent call last):
> >>>>>>>    File "/usr/share/vdsm/sampling.py", line 351, in collect
> >>>>>>>      statsFunction()
> >>>>>>>    File "/usr/share/vdsm/sampling.py", line 226, in __call__
> >>>>>>>      retValue = self._function(*args, **kwargs)
> >>>>>>>    File "/usr/share/vdsm/vm.py", line 509, in _highWrite
> >>>>>>>      if not vmDrive.blockDev or vmDrive.format != 'cow':
> >>>>>>> AttributeError: 'Drive' object has no attribute 'format'
> >>>>>>>
> >>>>>>> How did you create this vm? was it from the UI? was it from a
> script?
> >>>>>>> what
> >>>>>>> are the parameters you used?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Dafna
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 01/07/2014 04:34 PM, Neil wrote:
> >>>>>>>>
> >>>>>>>> Hi Elad,
> >>>>>>>>
> >>>>>>>> Thanks for assisting me, yes the same condition exists, if I try
> to
> >>>>>>>> migrate Tux it says "The VM Tux is being migrated".
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Below are the details requested.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> [root at node01 ~]# virsh -r list
> >>>>>>>>    Id    Name                           State
> >>>>>>>> ----------------------------------------------------
> >>>>>>>>    1     adam                           running
> >>>>>>>>
> >>>>>>>> [root at node01 ~]# pgrep qemu
> >>>>>>>> 11232
> >>>>>>>> [root at node01 ~]# vdsClient -s 0 list table
> >>>>>>>> 63da7faa-f92a-4652-90f2-b6660a4fb7b3  11232  adam
> Up
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> [root at node03 ~]# virsh -r list
> >>>>>>>>    Id    Name                           State
> >>>>>>>> ----------------------------------------------------
> >>>>>>>>    7     tux                            running
> >>>>>>>>
> >>>>>>>> [root at node03 ~]# pgrep qemu
> >>>>>>>> 32333
> >>>>>>>> [root at node03 ~]# vdsClient -s 0 list table
> >>>>>>>> 2736197b-6dc3-4155-9a29-9306ca64881d  32333  tux
>  Up
> >>>>>>>>
> >>>>>>>> Thanks.
> >>>>>>>>
> >>>>>>>> Regards.
> >>>>>>>>
> >>>>>>>> Neil Wilson.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Jan 7, 2014 at 4:43 PM, Elad Ben Aharon <
> ebenahar at redhat.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Is it still in the same condition?
> >>>>>>>>> If yes, please add the outputs from both hosts for:
> >>>>>>>>>
> >>>>>>>>> #virsh -r list
> >>>>>>>>> #pgrep qemu
> >>>>>>>>> #vdsClient -s 0 list table     (or 'vdsClient 0 list table' if
> you
> >>>>>>>>> are
> >>>>>>>>> working in insecure mode)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thnaks,
> >>>>>>>>>
> >>>>>>>>> Elad Ben Aharon
> >>>>>>>>> RHEV-QE storage team
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Neil" <nwilson123 at gmail.com>
> >>>>>>>>> To: users at ovirt.org
> >>>>>>>>> Sent: Tuesday, January 7, 2014 4:21:43 PM
> >>>>>>>>> Subject: [Users] Migration Failed
> >>>>>>>>>
> >>>>>>>>> Hi guys,
> >>>>>>>>>
> >>>>>>>>> I've tried to migrate a VM from one host(node03) to
> another(node01),
> >>>>>>>>> and it failed to migrate, and the VM(tux) remained on the
> original
> >>>>>>>>> host. I've now tried to migrate the same VM again, and it picks
> up
> >>>>>>>>> that the previous migration is still in progress and refuses to
> >>>>>>>>> migrate.
> >>>>>>>>>
> >>>>>>>>> I've checked for the KVM process on each of the hosts and the VM
> is
> >>>>>>>>> definitely still running on node03 so there doesn't appear to be
> any
> >>>>>>>>> chance of the VM trying to run on both hosts (which I've had
> before
> >>>>>>>>> which is very scary).
> >>>>>>>>>
> >>>>>>>>> These are my versions... and attached are my engine.log and my
> >>>>>>>>> vdsm.log
> >>>>>>>>>
> >>>>>>>>> Centos 6.5
> >>>>>>>>> ovirt-iso-uploader-3.3.1-1.el6.noarch
> >>>>>>>>> ovirt-host-deploy-1.1.2-1.el6.noarch
> >>>>>>>>> ovirt-release-el6-9-1.noarch
> >>>>>>>>> ovirt-engine-setup-3.3.1-2.el6.noarch
> >>>>>>>>> ovirt-engine-3.3.1-2.el6.noarch
> >>>>>>>>> ovirt-host-deploy-java-1.1.2-1.el6.noarch
> >>>>>>>>> ovirt-image-uploader-3.3.1-1.el6.noarch
> >>>>>>>>> ovirt-engine-dbscripts-3.3.1-2.el6.noarch
> >>>>>>>>> ovirt-engine-cli-3.3.0.6-1.el6.noarch
> >>>>>>>>> ovirt-engine-websocket-proxy-3.3.1-2.el6.noarch
> >>>>>>>>> ovirt-engine-userportal-3.3.1-2.el6.noarch
> >>>>>>>>> ovirt-log-collector-3.3.1-1.el6.noarch
> >>>>>>>>> ovirt-engine-tools-3.3.1-2.el6.noarch
> >>>>>>>>> ovirt-engine-lib-3.3.1-2.el6.noarch
> >>>>>>>>> ovirt-engine-webadmin-portal-3.3.1-2.el6.noarch
> >>>>>>>>> ovirt-engine-backend-3.3.1-2.el6.noarch
> >>>>>>>>> ovirt-engine-sdk-python-3.3.0.8-1.el6.noarch
> >>>>>>>>> ovirt-engine-restapi-3.3.1-2.el6.noarch
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> vdsm-python-4.13.0-11.el6.x86_64
> >>>>>>>>> vdsm-cli-4.13.0-11.el6.noarch
> >>>>>>>>> vdsm-xmlrpc-4.13.0-11.el6.noarch
> >>>>>>>>> vdsm-4.13.0-11.el6.x86_64
> >>>>>>>>> vdsm-python-cpopen-4.13.0-11.el6.x86_64
> >>>>>>>>>
> >>>>>>>>> I've had a few issues with this particular installation in the
> past,
> >>>>>>>>> as it's from a very old pre release of ovirt, then upgrading to
> the
> >>>>>>>>> dreyou repo, then finally moving to the official Centos ovirt
> repo.
> >>>>>>>>>
> >>>>>>>>> Thanks, any help is greatly appreciated.
> >>>>>>>>>
> >>>>>>>>> Regards.
> >>>>>>>>>
> >>>>>>>>> Neil Wilson.
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Users mailing list
> >>>>>>>>> Users at ovirt.org
> >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Users mailing list
> >>>>>>>> Users at ovirt.org
> >>>>>>>> http://lists.ovirt.org/mailman/listinfo/users
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Dafna Ron
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Dafna Ron
> >>>
> >>>
> >>>
> >>> --
> >>> Dafna Ron
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140113/f56daa65/attachment-0001.html>


More information about the Users mailing list