This is a cryptographically signed message in MIME format.
--------------ms080503070201070608050801
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Hello,
I have not much time to deal with this issue until today. I happily=20
recovered lost disk image.
As I mentioned before, I found lost disk image (volume) but it wasn't=20
accessible because it's logical volume (I'm using FC storage) wasn't=20
active...
I double check that this image is not used anywhere and set it active
lvchange -a y=20
/dev/088e7ed9-84c7-4fbd-a570-f37fa986a772/0681822f-3ac8-473b-95ce-380f8ab=
4de06
then I was able to backup my data (in fact I created new vm disk and dd=20
this volume to it)
btw. After successful recovery I still have this orphaned image on my=20
storage which is not visible from manager. How can I correctly remove=20
it? (from storage and from engine)
It looks like this (
http://www.ovirt.org/Features/Orphaned_Images)=20
utility would helped a lot ;-)
Cheers, Jiri
any hope and/or hint for me?
Before I moved storage I (partly live) migrated disks to this storage
(we have about 5 LUNS). Probably there could be some issues. Just a
guess - could it mean that some disks would stay on original storage as=
orphaned images?
It would be useful to have some low-level util to display all images
(also orphaned) and their properties and correlations with vms.
Kind regards,
Jiri
Dne 10.9.2015 v 16:31 Eli Mesika napsal(a):
> Adding Allon M
>
> ----- Original Message -----
>> From: "Ji=C5=99=C3=AD Sl=C3=A9=C5=BEka" <jiri.slezka(a)slu.cz>
>> To: "Eli Mesika" <emesika(a)redhat.com>
>> Cc: users(a)ovirt.org, "Omer Frenkel" <ofrenkel(a)redhat.com>
>> Sent: Thursday, September 10, 2015 4:07:48 PM
>> Subject: Re: [ovirt-users] moving storage and importing vms issue
>>
>> Hello,
>>
>>> ----- Original Message -----
>>>> From: "Ji=C5=99=C3=AD Sl=C3=A9=C5=BEka"
<jiri.slezka(a)slu.cz>
>>>> To: emesika(a)redhat.com
>>>> Cc: users(a)ovirt.org
>>>> Sent: Thursday, September 10, 2015 1:50:14 PM
>>>> Subject: Re: [ovirt-users] moving storage and importing vms issue
>>>>
>>>> Hello,
>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Ji=C5=99=C3=AD Sl=C3=A9=C5=BEka"
<jiri.slezka(a)slu.cz>
>>>>>> To: users(a)ovirt.org
>>>>>> Sent: Thursday, September 10, 2015 1:30:29 AM
>>>>>> Subject: [ovirt-users] moving storage and importing vms issue
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am working on some consolidation of our RHEV/oVirt servers and
>>>>>> I moved
>>>>>> one storage to new oVirt datacenter (put it into maintenance,
>>>>>> detached
>>>>>> it from old and imported into new datacenter) which worked
pretty=
>>>>>> good.
>>>>>>
>>>>>> Then I tried to import all the vms which worked also great
except=
>>>>>> for
>>>>>> three of them.
>>>>>>
>>>>>> These vms are stucked in VM Import sub-tab and are quietly
failin=
g
>>>>>> import attempts (I can only see failed task
"Importing VM
>>>>>> clavius-winxp
>>>>>> from configuration to Cluster CIT-oVirt" but no related
event and=
/or
>>>>>> explanation)
>>>>>>
>>>>>> There is only one host in this datacenter/cluster which is SPM.
I=
>>>>>> can't
>>>>>> find anything interesting in vdsm.log (short span of import time
>>>>>> is in
>>>>>> attachment).
>>>>>
>>>>> Can you please attach also engine.log ?
>>>>
>>>> sure
>>>>
>>>> well, here I can see an error... it looks like some db and/or snaps=
hot
>>>> issue.
>>>
>>> Yes, seems as ImportVmFromConfigurationCommand tries to add
>>> snapshots with
>>> the empty GUID (000......0)
>>> This cause violation of the primary key of the snapshots table
>>> CCing Omer F on that
>>>
>>>>
>>>> well and it looks like I lost also one secondary disk from one
>>>> correctly
>>>> imported vm.
>>>>
>>>> is there a way to show all images on some storage domain?
>>>>
>>>> I found that my storage is this
>>>>
>>>> [root@ovirt04 ~]# vdsClient -s 0 getStorageDomainInfo
>>>> 088e7ed9-84c7-4fbd-a570-f37fa986a772
>>>> uuid =3D 088e7ed9-84c7-4fbd-a570-f37fa986a772
>>>> vguuid =3D MkMpr6-o9c1-LBUq-rZ0E-ZRSg-X31T-2aU1PV
>>>> state =3D OK
>>>> version =3D 3
>>>> role =3D Master
>>>> type =3D FCP
>>>> class =3D Data
>>>> pool =3D ['00000002-0002-0002-0002-0000000002b9']
>>>> name =3D oVirt-SlowStorage
>>>>
>>>> but I have no luck with finding how to display all images on it.
>>>
>>> try
>>>
>>> # vdsClient -s getImagesList
"088e7ed9-84c7-4fbd-a570-f37fa986a772"
>>
>> yes, it works :-)
>>
>> now I have list of imgUUIDs on this storage. When I compare it agains=
t
>> Disks tab in oVirt manager a see 5 images that are not
visible in
>> manager.
>>
>> 346ad5af-9db8-46eb-9a45-172ce3213496
>> 45493042-67f5-4dcd-8dae-5b2c213aa95a
>> fb8f3165-5976-4094-9d37-ea0b09124547
>> e15288bc-30ec-4a77-837b-bdc7de37a08b
>> be5c56de-6a22-4d1a-8579-f0f5d501d90c
>>
>> now I tried to find anything about these images
>>
>> [root@ovirt04 ~]# vdsClient -s 0 getVolumesList
>> "088e7ed9-84c7-4fbd-a570-f37fa986a772"
>> "00000002-0002-0002-0002-0000000002b9"
>> "346ad5af-9db8-46eb-9a45-172ce3213496"
>> eeca0e49-ba6d-4b4b-9eb4-731b90b48091 : Exported by virt-v2v.
>> da00feb8-991d-4b91-b424-6931daf00c83 : Parent is
>> eeca0e49-ba6d-4b4b-9eb4-731b90b48091
>>
>> ----
>>
>> [root@ovirt04 ~]# vdsClient -s 0 getVolumesList
>> "088e7ed9-84c7-4fbd-a570-f37fa986a772"
>> "00000002-0002-0002-0002-0000000002b9"
>> "45493042-67f5-4dcd-8dae-5b2c213aa95a"
>>
>> d2916b5d-50e4-482c-aa6b-e26d2c78ef46 : Exported by virt-v2v.
>>
>> ----
>>
>> [root@ovirt04 ~]# vdsClient -s 0 getVolumesList
>> "088e7ed9-84c7-4fbd-a570-f37fa986a772"
>> "00000002-0002-0002-0002-0000000002b9"
>> "fb8f3165-5976-4094-9d37-ea0b09124547"
>> cc83caa4-e366-4fd6-94b7-d16089aa29d6 : Parent is
>> 53c5003d-80de-4dfd-b5d8-50537a3a54d6
>>
>> 53c5003d-80de-4dfd-b5d8-50537a3a54d6 : imported by virt-v2v.
>>
>> ----
>>
>> [root@ovirt04 ~]# vdsClient -s 0 getVolumesList
>> "088e7ed9-84c7-4fbd-a570-f37fa986a772"
>> "00000002-0002-0002-0002-0000000002b9"
>> "e15288bc-30ec-4a77-837b-bdc7de37a08b"
>>
>> 2f2c2a1c-6dcc-436c-962c-00e4e074a39a :
>>
{"DiskAlias":"polymatheia1.slu.cz_Disk1","DiskDescription":""}.
>>
>> ----
>>
>> [root@ovirt04 ~]# vdsClient -s 0 getVolumesList
>> "088e7ed9-84c7-4fbd-a570-f37fa986a772"
>> "00000002-0002-0002-0002-0000000002b9"
>> "be5c56de-6a22-4d1a-8579-f0f5d501d90c"
>>
>> 0681822f-3ac8-473b-95ce-380f8ab4de06 :
>>
>> ----
>>
>> when I look on last case
>>
>> [root@ovirt04 ~]# vdsClient -s 0 getVolumeInfo
>> "088e7ed9-84c7-4fbd-a570-f37fa986a772"
>> "00000002-0002-0002-0002-0000000002b9"
>> "be5c56de-6a22-4d1a-8579-f0f5d501d90c"
>> "0681822f-3ac8-473b-95ce-380f8ab4de06"
>> status =3D OK
>> domain =3D 088e7ed9-84c7-4fbd-a570-f37fa986a772
>> capacity =3D 322122547200
>> voltype =3D LEAF
>> description =3D
>> parent =3D 00000000-0000-0000-0000-000000000000
>> format =3D RAW
>> image =3D be5c56de-6a22-4d1a-8579-f0f5d501d90c
>> uuid =3D 0681822f-3ac8-473b-95ce-380f8ab4de06
>> disktype =3D 2
>> legality =3D LEGAL
>> mtime =3D 0
>> apparentsize =3D 322122547200
>> truesize =3D 322122547200
>> type =3D PREALLOCATED
>> children =3D []
>> pool =3D
>> ctime =3D 1440611370
>>
>> [root@ovirt04 ~]# vdsClient -s 0 getVolumeSize
>> "088e7ed9-84c7-4fbd-a570-f37fa986a772"
>> "00000002-0002-0002-0002-0000000002b9"
>> "be5c56de-6a22-4d1a-8579-f0f5d501d90c"
>> "0681822f-3ac8-473b-95ce-380f8ab4de06"
>> apparentsize =3D '322122547200'
>> truesize =3D '322122547200'
>>
>> [root@ovirt04 ~]# vdsClient -s 0 getVolumePath
>> "088e7ed9-84c7-4fbd-a570-f37fa986a772"
>> "00000002-0002-0002-0002-0000000002b9"
>> "be5c56de-6a22-4d1a-8579-f0f5d501d90c"
>> "0681822f-3ac8-473b-95ce-380f8ab4de06"
>> /rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd-a570-f37fa986a772/im=
ages/be5c56de-6a22-4d1a-8579-f0f5d501d90c/0681822f-3ac8-473b-95ce-380f8ab=
4de06
>>
>>
>> [root@ovirt04 ~]# ll
>> /rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd-a570-f37fa986a772/im=
ages/be5c56de-6a22-4d1a-8579-f0f5d501d90c/0681822f-3ac8-473b-95ce-380f8ab=
4de06
>>
>>
>>
>> lrwxrwxrwx. 1 vdsm kvm 78 Sep 9 22:36
>> /rhev/data-center/mnt/blockSD/088e7ed9-84c7-4fbd-a570-f37fa986a772/im=
ages/be5c56de-6a22-4d1a-8579-f0f5d501d90c/0681822f-3ac8-473b-95ce-380f8ab=
4de06
>>
>> ->
>> /dev/088e7ed9-84c7-4fbd-a570-f37fa986a772/0681822f-3ac8-473b-95ce-380=
f8ab4de06
>>
>>
>> but
>> /dev/088e7ed9-84c7-4fbd-a570-f37fa986a772/0681822f-3ac8-473b-95ce-380=
f8ab4de06
>>
>> seems to not exists
>>
>>
>> is there any chance to recover this disks?
>>
>> Thanks,
>>
>> Jiri
>>
>>
>>
>>
>>>
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jiri
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> Could you point me where should I look, please?
>>>>>>
>>>>>> Storage (FC) was formerly attached to RHEV3.5.3 on RHEL6.7 and
wa=
s
>>>>>> imported into oVirt3.5.4 on CentOS7.1
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> Jiri Slezka
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)ovirt.org
>>>>>>
http://lists.ovirt.org/mailman/listinfo/users
>>>>>>
>>>>
>>>>
>>
>>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--------------ms080503070201070608050801
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CWcwggScMIIDhKADAgECAhEAuOSLPwlcx/l5IqBlguM0fDANBgkqhkiG9w0BAQUFADA7MQsw
CQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwg
Q0EwHhcNMTQxMTEwMDAwMDAwWhcNMTYxMTA5MjM1OTU5WjBlMQswCQYDVQQGEwJDWjElMCMG
A1UECgwcU2xlenNrw6EgdW5pdmVyeml0YSB2IE9wYXbEmzEYMBYGA1UEAwwPSmnFmcOtIFNs
w6nFvmthMRUwEwYJKoZIhvcNAQkCFgZzbGV6a2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDNcPHUXg4ZfD3shn/1zeMf8tyn/ZplDk1756hc+PVHYNO2VRP2p1HKRdtcfj1i
2V87na0EfMmfxM77dJJklSnAsCXrs0by2eHzdCz746vErs5VkSnZ1nhOWH7FViKadiyxmAv+
zXL+jkzb678GHsT2jPWdHjfhgQXAzd0hE5AqkQ3sRGRspsfruRmfgStEoE2+Ubq4jC69pBYW
i80zdAUOc+9Kl5Zfolfo/TpFViXIo4i1FMgDRNYZAhBKpHz70zN/7VUqTl/7x9z3a6ytNC8J
TbbMdj8SdWhRV0oyOOhYlFHL+1ZS0KtQ0iz5yWs9dCkq77LrTXCXaWSGBRlQ8H/5AgMBAAGj
ggFvMIIBazAfBgNVHSMEGDAWgBRjTUNaGUg/xEbBArq/7g7lgrdmpjAdBgNVHQ4EFgQUNHjX
Vei/P0DdklwoP8A3Tkq0XTYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wPwYD
VR0fBDgwNjA0oDKgMIYuaHR0cDovL2NybC50Y3MudGVyZW5hLm9yZy9URVJFTkFQZXJzb25h
bENBLmNybDByBggrBgEFBQcBAQRmMGQwOgYIKwYBBQUHMAKGLmh0dHA6Ly9jcnQudGNzLnRl
cmVuYS5vcmcvVEVSRU5BUGVyc29uYWxDQS5jcnQwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3Nw
LnRjcy50ZXJlbmEub3JnMB0GA1UdEQQWMBSBEmppcmkuc2xlemthQHNsdS5jejANBgkqhkiG
9w0BAQUFAAOCAQEAJy6bixJ53paigwWwnXfipRly2TTkICwf4PtXw9hOBoYC17PbPpAoGBtT
Dvz6pQW4woSJ4JbkkD9JKGPlZXt0fQgZKgbfQ7sRFQ54goOhvJYm+CFJUPiSXrZ/i1CUzI40
U3kXYbWOq99yKid5aUEaIub9E6cJY6fybt7ireTV2IKVNIm/AXWjjf6jxGVavQ1QzTxmRvfE
sXpQis5jgCeJjRHhZ4BhwRChkIThLYfWTSYId9rbtuj3yjLjtJipDhHJEuIckgV8sCDbjbyt
xo0WNLQmfL0KUVxvpfMfdZ3McGKwn7nQiqBcpsGI3+9pfmHkMzy4+rDGZCHkeyNNxEUpLDCC
BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMDkwNTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEP
MA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpD
m/5bsbC/tFfcdYBBS2Qa9ttPb4/QJUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5Y
M38i+/j/7Oa+264KZSUih9pvhItG6ECGKD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyh
bp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51WJFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZ
UcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSbA/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V
0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRu
fTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYDVR0PAQH/BAQDAgEGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTBYBgNVHR8EUTBPME2g
S6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRo
ZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYBBQUHMAKGLGh0
dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzAB
hhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lTLxPc
XDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT
stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxs
H0+pAMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/
HaWWWr3QyxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXc
J4bkOjtSWherqQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYIDGjCCAxYCAQEwUDA7MQswCQYD
VQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EC
EQC45Is/CVzH+XkioGWC4zR8MA0GCWCGSAFlAwQCAQUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEwMDYyMTI5MDJaMC8GCSqGSIb3DQEJBDEi
BCCX6sXW/dzEWpJxjIibSeME0/Thhmazabjju1dh4LWjPTBfBgkrBgEEAYI3EAQxUjBQMDsx
CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h
bCBDQQIRALjkiz8JXMf5eSKgZYLjNHwwYQYLKoZIhvcNAQkQAgsxUqBQMDsxCzAJBgNVBAYT
Ak5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBDQQIRALjk
iz8JXMf5eSKgZYLjNHwwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUD
BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC
BzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAQcwddyBd3SKxeT8kxZPUb2+kr
U/WqAquHvOhffwFn3vZaHpnnnJP+hOTUgEm16dooa/bNfci1ppQauLx1SX7oej1zM1oirvir
YJIaF2+unQX37twvARA4oT8Cyyi8qiUWPGgPv5jyWf5NGnTPd+QfMYzBJOu0UF996CF8tNI3
ZdH7tX8NDcA+DDjHaOgwFVFCAR8P6E11zx5U6ytnnPUEmbYVTWJGXduuldHgrv/y07A9kRMo
e4s+mJoUwzjVVIbx/7eAAAYzWoNkhYgyUiwJsH7yt+KerKJyY3NJ8J3hzuXO95rgbaNZmwI5
YdcE0hy+0ZjRGjOV1Ttho10Qzz+MAAAAAAAA
--------------ms080503070201070608050801--