[Users] Migration Failed
Michal Skrivanek
michal.skrivanek at redhat.com
Tue Jan 14 08:03:44 UTC 2014
On 14 Jan 2014, at 08:43, Neil wrote:
> Sorry, before anyone wastes anymore time on this, I found the issue.
>
> My NFS ISO domain was attached to the other host node02, but the NFS
> mount wasn't accessible due to the iptables service being activated on
> boot once I had run all the OS updates a while back.
>
> I've disabled the service again, and the migration has completed successfully.
>
> Thank you all for your assistance, and I'm sorry for wasting your time.
good it's working for you
I was also checking the internal error and it's http://gerrit.ovirt.org/#/c/21700, which is fixed by now
Thanks,
michal
>
> Regards.
>
> Neil Wilson.
>
>
>
> On Tue, Jan 14, 2014 at 9:30 AM, Neil <nwilson123 at gmail.com> wrote:
>> Good morning everyone,
>>
>> Sorry for the late reply.
>>
>> Tom: unfortunately selinux is disabled on all the machines involved.
>>
>> Michal: Attached are the latest logs, I started the migration at
>> 8:43am and it returned an error/failed at 8:52am. The details of the
>> migration are as follows.
>>
>> node01 (10.0.2.21) is the destination
>> node03 (10.0.2.23) is the source
>> engine01 (10.0.2.31) is the engine
>> Tux is the VM
>>
>> Strangely enough the immediate "pop up" error I received in the GUI
>> previously didn't appear this time and it looked like it might
>> actually work, however after waiting quite a while it eventually
>> returned an error in the Tasks as follows...
>>
>> 2014-Jan-14, 09:05 Refresh image list failed for domain(s): bla-iso
>> (ISO file type). Please check domain activity.
>> 2014-Jan-14, 09:05 Migration failed due to Error: Internal Engine
>> Error. Trying to migrate to another Host (VM: tux, Source:
>> node03.blabla.com, Destination: node01.blabla.com).
>> 2014-Jan-14, 08:52 Migration failed due to Error: Internal Engine
>> Error (VM: tux, Source: node03.blabla.com, Destination:
>> node01.blabla.com).
>>
>> and then also received an error in the engine.log which is why I've
>> attached that as well.
>>
>> Please shout if you need any further info.
>>
>> Thank you so much.
>>
>> Regards.
>>
>> Neil Wilson.
>>
>> On Mon, Jan 13, 2014 at 4:07 PM, Tom Brown <tom at ng23.net> wrote:
>>>
>>> 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
>>>
>>>
More information about the Users
mailing list