Re: [ovirt-users] Bad volume specification after hung migration

2017-10-26 Thread Michal Skrivanek

> On 26 Oct 2017, at 12:32, Roberto Nunin  wrote:
> 
> Hi Michael
> 
> By frozen I mean the action to put host in maintenance while some VM were 
> running on it.
> This action wasn't completed after more than one hour.

ok, and was the problem in this last VM not finishing the migration? Was it 
migrating at all? If yes, what was the progress in UI, any failures? There are 
various timeouts which should have been triggered, so if they were not 
triggered it would indeed point to some internal issue. Would be great to 
attach source and destination vdsm.log

> Thinking that shutting down the VM could help, I've done it. Looking at 
> results, not.

What was the result? Did it fail to shut down? Did you use Power Off to force 
immediate shutdown? If it was migrating, did you try to cancel the migration 
first?

> 
> Yes, I've restarted the ovirt-engine service, I've still not restarted the 
> hosted-engine VM.

well, it’s not only a universal “fix” of various things, sometimes it does more 
harm than benefit too. Logs would be helpful.

> Hosts still not restarted. Do you think can help ?

hard to say. Either way please salvage logs first

> 
> Obviously we will migrate, this activities are enabling us to have redundancy 
> at the storage level, then we will migrate to 4.1.x

great:)

Thanks,
michal

> 
> Thanks
> 
> 2017-10-26 12:26 GMT+02:00 Michal Skrivanek  >:
> 
>> On 26 Oct 2017, at 10:20, Roberto Nunin > > wrote:
>> 
>> We are running 4.0.1.1-1.el7.centos
> 
> Hi,
> any reason not to upgrade to 4.1?
> 
>> 
>> After a frozen migration attempt, we have two VM that after shutdown, are 
>> not anymore able to be started up again.
> 
> what do you mean by frozen? Are you talking about "VM live migration" or 
> “live storage migration”?
> How exactly did you resolve that situation, you only shut down those VMs? No 
> other troubleshooting steps, e.g. restarting engine, hosts, things like that?
> 
> Thanks,
> michal
>> 
>> Message returned is :
>> 
>> Bad volume specification {'index': '0', u'domainID': 
>> u'731d95a9-61a7-4c7a-813b-fb1c3dde47ea', 'reqsize': '0', u'format': u'cow', 
>> u'optional': u'false', u'address': {u'function': u'0x0', u'bus': u'0x00', 
>> u'domain': u'0x', u'type': u'pci', u'slot': u'0x05'}, u'volumeID': 
>> u'cffc70ff-ed72-46ef-a369-4be95de72260', 'apparentsize': '3221225472', 
>> u'imageID': u'3fe5a849-bcc2-42d3-93c5aca4c504515b', u'specParams': {}, 
>> u'readonly': u'false', u'iface': u'virtio', u'deviceId': 
>> u'3fe5a849bcc2-42d3-93c5-aca4c504515b', 'truesize': '3221225472', u'poolID': 
>> u'0001-0001-0001-0001-01ec', u'device': u'disk', u'shared': 
>> u'false', u'propagateErrors': u'off',u'type':u'disk'}
>> 
>> Probably this is caused by a wrong pointer into the database that still 
>> refer to the migration image-id.
>> 
>> If we search within all_disks view, we can find that parentid field isn't 
>> ---- like all other running vm, but it has a 
>> value:
>> 
>>vm_names   |   parentid
>> --+--
>>  working01.company.xx | ----
>>  working02.company.xx | ----
>>  working03.company.xx | ----
>>  working04.company.xx | ----
>>  broken001.company.xx | 30533842-2c83-4d0e-95d2-48162dbe23bd <
>>  working05.company.xx | ----
>> 
>> 
>> How we can recover from this ?
>> 
>> Thanks in advance
>> Regards,
>> 
>> -- 
>> Robert​o​
>> 
>> 
>> 
>> ___
>> Users mailing list
>> Users@ovirt.org 
>> http://lists.ovirt.org/mailman/listinfo/users 
>> 
> 
> 
> 
> 
> -- 
> Roberto
> 
> 
> 

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Bad volume specification after hung migration

2017-10-26 Thread Michal Skrivanek

> On 26 Oct 2017, at 10:20, Roberto Nunin  wrote:
> 
> We are running 4.0.1.1-1.el7.centos

Hi,
any reason not to upgrade to 4.1?

> 
> After a frozen migration attempt, we have two VM that after shutdown, are not 
> anymore able to be started up again.

what do you mean by frozen? Are you talking about "VM live migration" or “live 
storage migration”?
How exactly did you resolve that situation, you only shut down those VMs? No 
other troubleshooting steps, e.g. restarting engine, hosts, things like that?

Thanks,
michal
> 
> Message returned is :
> 
> Bad volume specification {'index': '0', u'domainID': 
> u'731d95a9-61a7-4c7a-813b-fb1c3dde47ea', 'reqsize': '0', u'format': u'cow', 
> u'optional': u'false', u'address': {u'function': u'0x0', u'bus': u'0x00', 
> u'domain': u'0x', u'type': u'pci', u'slot': u'0x05'}, u'volumeID': 
> u'cffc70ff-ed72-46ef-a369-4be95de72260', 'apparentsize': '3221225472', 
> u'imageID': u'3fe5a849-bcc2-42d3-93c5aca4c504515b', u'specParams': {}, 
> u'readonly': u'false', u'iface': u'virtio', u'deviceId': 
> u'3fe5a849bcc2-42d3-93c5-aca4c504515b', 'truesize': '3221225472', u'poolID': 
> u'0001-0001-0001-0001-01ec', u'device': u'disk', u'shared': 
> u'false', u'propagateErrors': u'off',u'type':u'disk'}
> 
> Probably this is caused by a wrong pointer into the database that still refer 
> to the migration image-id.
> 
> If we search within all_disks view, we can find that parentid field isn't 
> ---- like all other running vm, but it has a 
> value:
> 
>vm_names   |   parentid
> --+--
>  working01.company.xx | ----
>  working02.company.xx | ----
>  working03.company.xx | ----
>  working04.company.xx | ----
>  broken001.company.xx | 30533842-2c83-4d0e-95d2-48162dbe23bd <
>  working05.company.xx | ----
> 
> 
> How we can recover from this ?
> 
> Thanks in advance
> Regards,
> 
> -- 
> Robert​o​
> 
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


[ovirt-users] Bad volume specification after hung migration

2017-10-26 Thread Roberto Nunin
We are running 4.0.1.1-1.el7.centos

After a frozen migration attempt, we have two VM that after shutdown, are
not anymore able to be started up again.

Message returned is :

Bad volume specification {'index': '0', u'domainID':
u'731d95a9-61a7-4c7a-813b-fb1c3dde47ea', 'reqsize': '0', u'format': u'cow',
u'optional': u'false', u'address': {u'function': u'0x0', u'bus': u'0x00',
u'domain': u'0x', u'type': u'pci', u'slot': u'0x05'}, u'volumeID':
u'cffc70ff-ed72-46ef-a369-4be95de72260', 'apparentsize': '3221225472',
u'imageID': u'3fe5a849-bcc2-42d3-93c5aca4c504515b', u'specParams': {},
u'readonly': u'false', u'iface': u'virtio', u'deviceId':
u'3fe5a849bcc2-42d3-93c5-aca4c504515b', 'truesize': '3221225472',
u'poolID': u'0001-0001-0001-0001-01ec', u'device': u'disk',
u'shared': u'false', u'propagateErrors': u'off',u'type':u'disk'}

Probably this is caused by a wrong pointer into the database that still
refer to the migration image-id.

If we search within all_disks view, we can find that parentid field
isn't ----
like all other running vm, but it has a value:

   vm_names   |   parentid
--+--
 working01.company.xx | ----
 working02.company.xx | ----
 working03.company.xx | ----
 working04.company.xx | ----
 broken001.company.xx | 30533842-2c83-4d0e-95d2-48162dbe23bd <
 working05.company.xx | ----


How we can recover from this ?

Thanks in advance
Regards,

-- 
Robert
​o​
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users