ok, so the process seems pretty obtuse, so let me run this by the list= =3D here and maybe I'm just not doing it the best way.

1) i connected an export domain called EXPORTNFS. the nfs share = =3D is physically on my management server (as is iso)

2) exported 1 VM.

3) on the mgmt server, i run "tar zxcf /root/test.tgz /opt/export= =3D /[UUID]/images /opt/export/[UUID]/master"

4) for good measure, i use ovirt web gui to delete the exported VM fro= =3D m the export

5) run the command 'engine-image-uploader =3D96u admin(a)internal uplo= ad t=3D est.tgz =3D96v =3D96e EXPORTNFS

6) after a while, it completes and i see the VM back in the export sto= =3D rage tab under VM Import.

i didn't run the vm yet, but I'm assuming thats a successful export an= =3D d import.

so, it seems if i wanted to export each and every VM from one separate= =3D ovirt to another, i would export each VM, tar-gzip it, clear it from the w= =3D ebgui, and start the next one? IE.. i mean it looks like engine-imag= =3D e-uploader would be pretty unhappy with finding more than one set of VM UUIDs inside?

is this the way it should be done, or am i doing it the hard way?

thanks!

jonathan

From: Jonathan Horne <jhorne(a)skopos.us>
Date: Tuesday, December 11, 2012 = 8:=3D 02 AM
To: "users(a)ovirt.org" <=3D users(a)ovirt.org>
Subject: [Users] theoretical scen= ar=3D io

My production deployment is approaching soon, so i am trying to get so= =3D me final tasks and concepts completed before that day arrives. Lets s= =3D ay, that i have a working domain, but that an impending disaster is about t= =3D o destroy the whole thing. How can i get the Vms out, and then how can i reverse this and get them into a compl= =3D etely new and unrelated/unconnected ovirt domain?

Any advice, or a doc or link would be much appreciated.

Thanks,

jonathan

This is a PRIVATE mess= age. I=3D f you are not the intended recipient, please delete without copying and kin= =3D dly advise us by e-mail of the mistake in delivery. NOTE: Regardless of con= =3D tent, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit wri= =3D tten agreement or government initiative expressly permitting the use of e-m= =3D ail for such purpose. --_000_9BE6F493F83A594DA60C45E6A09DC5AC016D644CAUSP01DAG0201co_-- --===============2808824553999514933== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS1fMDAwXzlCRTZGNDkzRjgzQTU5NERBNjBDNDVFNkEwOURDNUFDMDE2RDY0NENBVVNQMDFEQUcw MjAxY29fCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0iV2luZG93cy0xMjUyIgpD b250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlCgpvaywgc28gdGhlIHBy b2Nlc3Mgc2VlbXMgcHJldHR5IG9idHVzZSwgc28gbGV0IG1lIHJ1biB0aGlzIGJ5IHRoZSBsaXN0 IGhlcmU9CiBhbmQgbWF5YmUgSSdtIGp1c3Qgbm90IGRvaW5nIGl0IHRoZSBiZXN0IHdheS4KCjEp IGkgY29ubmVjdGVkIGFuIGV4cG9ydCBkb21haW4gY2FsbGVkIEVYUE9SVE5GUy4gIHRoZSBuZnMg c2hhcmUgaXMgcGh5c2ljYT0KbGx5IG9uIG15IG1hbmFnZW1lbnQgc2VydmVyIChhcyBpcyBpc28p CjIpIGV4cG9ydGVkIDEgVk0uCjMpIG9uIHRoZSBtZ210IHNlcnZlciwgaSBydW4gInRhciB6eGNm IC9yb290L3Rlc3QudGd6IC9vcHQvZXhwb3J0L1tVVUlEXS9pbT0KYWdlcyAvb3B0L2V4cG9ydC9b VVVJRF0vbWFzdGVyIgo0KSBmb3IgZ29vZCBtZWFzdXJlLCBpIHVzZSBvdmlydCB3ZWIgZ3VpIHRv IGRlbGV0ZSB0aGUgZXhwb3J0ZWQgVk0gZnJvbSB0aGU9CiBleHBvcnQKNSkgcnVuIHRoZSBjb21t YW5kICdlbmdpbmUtaW1hZ2UtdXBsb2FkZXIgPTk2dSBhZG1pbkBpbnRlcm5hbCB1cGxvYWQgdGVz dC50PQpneiA9OTZ2ID05NmUgRVhQT1JUTkZTCjYpIGFmdGVyIGEgd2hpbGUsIGl0IGNvbXBsZXRl cyBhbmQgaSBzZWUgdGhlIFZNIGJhY2sgaW4gdGhlIGV4cG9ydCBzdG9yYWdlID0KdGFiIHVuZGVy IFZNIEltcG9ydC4KCmkgZGlkbid0IHJ1biB0aGUgdm0geWV0LCBidXQgSSdtIGFzc3VtaW5nIHRo YXRzIGEgc3VjY2Vzc2Z1bCBleHBvcnQgYW5kIGltcD0Kb3J0LgoKc28sIGl0IHNlZW1zIGlmIGkg d2FudGVkIHRvIGV4cG9ydCBlYWNoIGFuZCBldmVyeSBWTSBmcm9tIG9uZSBzZXBhcmF0ZSBvdmly PQp0IHRvIGFub3RoZXIsIGkgd291bGQgZXhwb3J0IGVhY2ggVk0sIHRhci1nemlwIGl0LCBjbGVh ciBpdCBmcm9tIHRoZSB3ZWJndWk9CiwgYW5kIHN0YXJ0IHRoZSBuZXh0IG9uZT8gICBJRS4uIGkg bWVhbiBpdCBsb29rcyBsaWtlIGVuZ2luZS1pbWFnZS11cGxvYWRlcj0KIHdvdWxkIGJlIHByZXR0 eSB1bmhhcHB5IHdpdGggZmluZGluZyBtb3JlIHRoYW4gb25lIHNldCBvZiBWTSBVVUlEcyBpbnNp ZGU/CgppcyB0aGlzIHRoZSB3YXkgaXQgc2hvdWxkIGJlIGRvbmUsIG9yIGFtIGkgZG9pbmcgaXQg dGhlIGhhcmQgd2F5PwoKdGhhbmtzIQpqb25hdGhhbgoKCgpGcm9tOiBKb25hdGhhbiBIb3JuZSA8 amhvcm5lQHNrb3Bvcy51czxtYWlsdG86amhvcm5lQHNrb3Bvcy51cz4+CkRhdGU6IFR1ZXNkYXks IERlY2VtYmVyIDExLCAyMDEyIDg6MDIgQU0KVG86ICJ1c2Vyc0BvdmlydC5vcmc8bWFpbHRvOnVz ZXJzQG92aXJ0Lm9yZz4iIDx1c2Vyc0BvdmlydC5vcmc8bWFpbHRvOnVzZXJzPQpAb3ZpcnQub3Jn Pj4KU3ViamVjdDogW1VzZXJzXSB0aGVvcmV0aWNhbCBzY2VuYXJpbwoKTXkgcHJvZHVjdGlvbiBk ZXBsb3ltZW50IGlzIGFwcHJvYWNoaW5nIHNvb24sIHNvIGkgYW0gdHJ5aW5nIHRvIGdldCBzb21l IGZpPQpuYWwgdGFza3MgYW5kIGNvbmNlcHRzIGNvbXBsZXRlZCBiZWZvcmUgdGhhdCBkYXkgYXJy aXZlcy4gIExldHMgc2F5LCB0aGF0IGk9CiBoYXZlIGEgd29ya2luZyBkb21haW4sIGJ1dCB0aGF0 IGFuIGltcGVuZGluZyBkaXNhc3RlciBpcyBhYm91dCB0byBkZXN0cm95ID0KdGhlIHdob2xlIHRo aW5nLiAgSG93IGNhbiBpIGdldCB0aGUgVm1zIG91dCwgYW5kIHRoZW4gaG93IGNhbiBpIHJldmVy c2UgdGhpPQpzIGFuZCBnZXQgdGhlbSBpbnRvIGEgY29tcGxldGVseSBuZXcgYW5kIHVucmVsYXRl ZC91bmNvbm5lY3RlZCBvdmlydCBkb21haW49Cj8KCkFueSBhZHZpY2UsIG9yIGEgZG9jIG9yIGxp bmsgd291bGQgYmUgbXVjaCBhcHByZWNpYXRlZC4KClRoYW5rcywKam9uYXRoYW4KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fClRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZT0KbGV0ZSB3aXRob3V0 IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGlu IGRlbGl2PQplcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hh bGwgbm90IG9wZXJhdGUgdG8gYmluZCBTS089ClBPUyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29u dHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4gYWdyZT0KZW1lbnQgb3Ig Z292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1t YWlsIGZvciBzPQp1Y2ggcHVycG9zZS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f ClRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBkZT0KbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZp c2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIGRlbGl2PQplcnkuIE5PVEU6IFJlZ2Fy ZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBT S089ClBPUyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRv IGV4cGxpY2l0IHdyaXR0ZW4gYWdyZT0KZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4 cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzPQp1Y2ggcHVycG9zZS4K Ci0tXzAwMF85QkU2RjQ5M0Y4M0E1OTREQTYwQzQ1RTZBMDlEQzVBQzAxNkQ2NDRDQVVTUDAxREFH MDIwMWNvXwpDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD0iV2luZG93cy0xMjUyIgpD b250ZW50LUlEOiA8QzQxN0Y5ODhEQjc4RjU0NkJFRThENkZBREY1OUQ5QkRAY29sbGFib3JhdGlv bmhvc3QubmV0PgpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlCgo8 aHRtbD4KPGhlYWQ+CjxtZXRhIGh0dHAtZXF1aXY9M0QiQ29udGVudC1UeXBlIiBjb250ZW50PTNE InRleHQvaHRtbDsgY2hhcnNldD0zRFdpbmRvd3MtMT0KMjUyIj4KPC9oZWFkPgo8Ym9keSBzdHls ZT0zRCJ3b3JkLXdyYXA6YnJlYWstd29yZDsgY29sb3I6cmdiKDAsMCwwKTsgZm9udC1zaXplOjE0 cHg7IGZvbnQ9Ci1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4KPGRpdj4KPGRpdj4KPGRpdj5v aywgc28gdGhlIHByb2Nlc3Mgc2VlbXMgcHJldHR5IG9idHVzZSwgc28gbGV0IG1lIHJ1biB0aGlz IGJ5IHRoZSBsaXN0PQogaGVyZSBhbmQgbWF5YmUgSSdtIGp1c3Qgbm90IGRvaW5nIGl0IHRoZSBi ZXN0IHdheS4gJm5ic3A7PC9kaXY+CjxkaXY+PGJyPgo8L2Rpdj4KPGRpdj4xKSBpIGNvbm5lY3Rl ZCBhbiBleHBvcnQgZG9tYWluIGNhbGxlZCBFWFBPUlRORlMuICZuYnNwO3RoZSBuZnMgc2hhcmUg PQppcyBwaHlzaWNhbGx5IG9uIG15IG1hbmFnZW1lbnQgc2VydmVyIChhcyBpcyBpc28pPC9kaXY+ CjxkaXY+MikgZXhwb3J0ZWQgMSBWTS48L2Rpdj4KPGRpdj4zKSBvbiB0aGUgbWdtdCBzZXJ2ZXIs IGkgcnVuICZxdW90O3RhciB6eGNmIC9yb290L3Rlc3QudGd6IC9vcHQvZXhwb3J0PQovW1VVSURd L2ltYWdlcyAvb3B0L2V4cG9ydC9bVVVJRF0vbWFzdGVyJnF1b3Q7PC9kaXY+CjxkaXY+NCkgZm9y IGdvb2QgbWVhc3VyZSwgaSB1c2Ugb3ZpcnQgd2ViIGd1aSB0byBkZWxldGUgdGhlIGV4cG9ydGVk IFZNIGZybz0KbSB0aGUgZXhwb3J0PC9kaXY+CjxkaXY+NSkgcnVuIHRoZSBjb21tYW5kICdlbmdp bmUtaW1hZ2UtdXBsb2FkZXIgPTk2dSBhZG1pbkBpbnRlcm5hbCB1cGxvYWQgdD0KZXN0LnRneiA9 OTZ2ID05NmUgRVhQT1JUTkZTPC9kaXY+CjxkaXY+NikgYWZ0ZXIgYSB3aGlsZSwgaXQgY29tcGxl dGVzIGFuZCBpIHNlZSB0aGUgVk0gYmFjayBpbiB0aGUgZXhwb3J0IHN0bz0KcmFnZSB0YWIgdW5k ZXIgVk0gSW1wb3J0LjwvZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+aSBkaWRuJ3QgcnVuIHRo ZSB2bSB5ZXQsIGJ1dCBJJ20gYXNzdW1pbmcgdGhhdHMgYSBzdWNjZXNzZnVsIGV4cG9ydCBhbj0K ZCBpbXBvcnQuPC9kaXY+CjxkaXY+PGJyPgo8L2Rpdj4KPGRpdj5zbywgaXQgc2VlbXMgaWYgaSB3 YW50ZWQgdG8gZXhwb3J0IGVhY2ggYW5kIGV2ZXJ5IFZNIGZyb20gb25lIHNlcGFyYXRlPQogb3Zp cnQgdG8gYW5vdGhlciwgaSB3b3VsZCBleHBvcnQgZWFjaCBWTSwgdGFyLWd6aXAgaXQsIGNsZWFy IGl0IGZyb20gdGhlIHc9CmViZ3VpLCBhbmQgc3RhcnQgdGhlIG5leHQgb25lPyAmbmJzcDsgSUUu LiBpIG1lYW4gaXQgbG9va3MgbGlrZSBlbmdpbmUtaW1hZz0KZS11cGxvYWRlciB3b3VsZCBiZSBw cmV0dHkgdW5oYXBweSB3aXRoCiBmaW5kaW5nIG1vcmUgdGhhbiBvbmUgc2V0IG9mIFZNIFVVSURz IGluc2lkZT88L2Rpdj4KPGRpdj48YnI+CjwvZGl2Pgo8ZGl2PmlzIHRoaXMgdGhlIHdheSBpdCBz aG91bGQgYmUgZG9uZSwgb3IgYW0gaSBkb2luZyBpdCB0aGUgaGFyZCB3YXk/PC9kaXY9Cj4KPGRp dj48YnI+CjwvZGl2Pgo8ZGl2PnRoYW5rcyE8L2Rpdj4KPGRpdj5qb25hdGhhbjwvZGl2Pgo8ZGl2 Pjxicj4KPC9kaXY+CjxkaXY+PGJyPgo8L2Rpdj4KPGRpdj4KPGRpdj48L2Rpdj4KPC9kaXY+Cjwv ZGl2Pgo8L2Rpdj4KPGRpdj48YnI+CjwvZGl2Pgo8c3BhbiBpZD0zRCJPTEtfU1JDX0JPRFlfU0VD VElPTiI+CjxkaXYgc3R5bGU9M0QiZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7 IHRleHQtYWxpZ246bGVmdDsgY29sb3I6Yj0KbGFjazsgYm9yZGVyLWJvdHRvbTptZWRpdW0gbm9u ZTsgYm9yZGVyLWxlZnQ6bWVkaXVtIG5vbmU7IHBhZGRpbmctYm90dG9tOjBpPQpuOyBwYWRkaW5n LWxlZnQ6MGluOyBwYWRkaW5nLXJpZ2h0OjBpbjsgYm9yZGVyLXRvcDojYjVjNGRmIDFwdCBzb2xp ZDsgYm9yZGU9CnItcmlnaHQ6bWVkaXVtIG5vbmU7IHBhZGRpbmctdG9wOjNwdCI+CjxzcGFuIHN0 eWxlPTNEImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5Kb25hdGhhbiBIb3JuZSAmbHQ7 PGEgaHJlZj0zRD0KIm1haWx0bzpqaG9ybmVAc2tvcG9zLnVzIj5qaG9ybmVAc2tvcG9zLnVzPC9h PiZndDs8YnI+CjxzcGFuIHN0eWxlPTNEImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5U dWVzZGF5LCBEZWNlbWJlciAxMSwgMjAxMiA4Oj0KMDIgQU08YnI+CjxzcGFuIHN0eWxlPTNEImZv bnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0zRCJtYWlsdG86dXNlcnNA bz0KdmlydC5vcmciPnVzZXJzQG92aXJ0Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9M0QibWFp bHRvOnVzZXJzQG92aXJ0Lm9yZyI+PQp1c2Vyc0BvdmlydC5vcmc8L2E+Jmd0Ozxicj4KPHNwYW4g c3R5bGU9M0QiZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltVc2Vyc10gdGhlb3Jl dGljYWwgc2NlbmFyPQppbzxicj4KPC9kaXY+CjxkaXY+PGJyPgo8L2Rpdj4KPGRpdj4KPGRpdiBz dHlsZT0zRCJ3b3JkLXdyYXA6YnJlYWstd29yZDsgY29sb3I6cmdiKDAsMCwwKTsgZm9udC1zaXpl OjE0cHg7IGZvbnQtPQpmYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4KPGRpdj4KPGRpdj4KPGRp dj5NeSBwcm9kdWN0aW9uIGRlcGxveW1lbnQgaXMgYXBwcm9hY2hpbmcgc29vbiwgc28gaSBhbSB0 cnlpbmcgdG8gZ2V0IHNvPQptZSBmaW5hbCB0YXNrcyBhbmQgY29uY2VwdHMgY29tcGxldGVkIGJl Zm9yZSB0aGF0IGRheSBhcnJpdmVzLiAmbmJzcDtMZXRzIHM9CmF5LCB0aGF0IGkgaGF2ZSBhIHdv cmtpbmcgZG9tYWluLCBidXQgdGhhdCBhbiBpbXBlbmRpbmcgZGlzYXN0ZXIgaXMgYWJvdXQgdD0K byBkZXN0cm95IHRoZSB3aG9sZSB0aGluZy4gJm5ic3A7SG93IGNhbiBpCiBnZXQgdGhlIFZtcyBv dXQsIGFuZCB0aGVuIGhvdyBjYW4gaSByZXZlcnNlIHRoaXMgYW5kIGdldCB0aGVtIGludG8gYSBj b21wbD0KZXRlbHkgbmV3IGFuZCB1bnJlbGF0ZWQvdW5jb25uZWN0ZWQgb3ZpcnQgZG9tYWluPzwv ZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+QW55IGFkdmljZSwgb3IgYSBkb2Mgb3IgbGluayB3 b3VsZCBiZSBtdWNoIGFwcHJlY2lhdGVkLjwvZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+VGhh bmtzLDwvZGl2Pgo8ZGl2PmpvbmF0aGFuPC9kaXY+CjxkaXY+CjxkaXY+PC9kaXY+CjwvZGl2Pgo8 L2Rpdj4KPC9kaXY+Cjxicj4KPGhyPgo8Zm9udCBjb2xvcj0zRCJHcmF5IiBmYWNlPTNEIkFyaWFs IiBzaXplPTNEIjEiPlRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIEk9CmYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5k IGtpbj0KZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnku IE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29uPQp0ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3Bl cmF0ZSB0bwogYmluZCBTS09QT1MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVz cyBwdXJzdWFudCB0byBleHBsaWNpdCB3cmk9CnR0ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQg aW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbT0KYWlsIGZvciBz dWNoIHB1cnBvc2UuPC9mb250PjwvZGl2Pgo8L2Rpdj4KPC9zcGFuPjxicj4KPGhyPgo8Zm9udCBj b2xvcj0zRCJHcmF5IiBmYWNlPTNEIkFyaWFsIiBzaXplPTNEIjEiPlRoaXMgaXMgYSBQUklWQVRF IG1lc3NhZ2UuIEk9CmYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbj0KZGx5IGFkdmlzZSB1cyBieSBlLW1haWwg b2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29uPQp0ZW50 LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0bwogYmluZCBTS09QT1MgdG8gYW55IG9y ZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cmk9CnR0 ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGlu ZyB0aGUgdXNlIG9mIGUtbT0KYWlsIGZvciBzdWNoIHB1cnBvc2UuPC9mb250Pgo8L2JvZHk+Cjwv aHRtbD4KCi0tXzAwMF85QkU2RjQ5M0Y4M0E1OTREQTYwQzQ1RTZBMDlEQzVBQzAxNkQ2NDRDQVVT UDAxREFHMDIwMWNvXy0tCg== --===============2808824553999514933==-- From vered at redhat.com Wed Dec 12 02:32:57 2012 Content-Type: multipart/mixed; boundary="===============0333094533217608240==" MIME-Version: 1.0 From: Vered Volansky To: users at ovirt.org Subject: Re: [Users] theoretical scenario Date: Wed, 12 Dec 2012 02:32:56 -0500 Message-ID: <1534012511.47713052.1355297576183.JavaMail.root@redhat.com> In-Reply-To: 9BE6F493F83A594DA60C45E6A09DC5AC016D644C@AUSP01DAG0201.collaborationhost.net --===============0333094533217608240== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable First, your scenario is missing the actual import, you just have the data i= n the export domain, not the vms in the engine. Second - A slightly simpler way you were looking for: 1. Export multiple vms using either a short script via RESTAPI or webadmin = (select multiple vms and export). 2. Detach the export domain. 3. Backup the export domain with all its data. 4. Re-attach export domain when ready to. 5. Import vms. Good luck, Vered ----- Original Message ----- > From: "Jonathan Horne" > To: "Jonathan Horne" , users(a)ovirt.org > Sent: Tuesday, December 11, 2012 9:47:06 PM > Subject: Re: [Users] theoretical scenario > = > = > = > = > = > ok, so the process seems pretty obtuse, so let me run this by the > list here and maybe I'm just not doing it the best way. > = > = > 1) i connected an export domain called EXPORTNFS. the nfs share is > physically on my management server (as is iso) > 2) exported 1 VM. > 3) on the mgmt server, i run "tar zxcf /root/test.tgz > /opt/export/[UUID]/images /opt/export/[UUID]/master" > 4) for good measure, i use ovirt web gui to delete the exported VM > from the export > 5) run the command 'engine-image-uploader =E2=80=93u admin(a)internal upl= oad > test.tgz =E2=80=93v =E2=80=93e EXPORTNFS > 6) after a while, it completes and i see the VM back in the export > storage tab under VM Import. > = > = > i didn't run the vm yet, but I'm assuming thats a successful export > and import. > = > = > so, it seems if i wanted to export each and every VM from one > separate ovirt to another, i would export each VM, tar-gzip it, > clear it from the webgui, and start the next one? IE.. i mean it > looks like engine-image-uploader would be pretty unhappy with > finding more than one set of VM UUIDs inside? > = > = > is this the way it should be done, or am i doing it the hard way? > = > = > thanks! > jonathan > = > = > = > = > = > = > = > = > From: Jonathan Horne < jhorne(a)skopos.us > > Date: Tuesday, December 11, 2012 8:02 AM > To: " users(a)ovirt.org " < users(a)ovirt.org > > Subject: [Users] theoretical scenario > = > = > = > = > = > = > = > My production deployment is approaching soon, so i am trying to get > some final tasks and concepts completed before that day arrives. > Lets say, that i have a working domain, but that an impending > disaster is about to destroy the whole thing. How can i get the Vms > out, and then how can i reverse this and get them into a completely > new and unrelated/unconnected ovirt domain? > = > = > Any advice, or a doc or link would be much appreciated. > = > = > Thanks, > jonathan > = > = > = > This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the > mistake in delivery. NOTE: Regardless of content, this e-mail shall > not operate to bind SKOPOS to any order or other contract unless > pursuant to explicit written agreement or government initiative > expressly permitting the use of e-mail for such purpose. > = > This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the > mistake in delivery. NOTE: Regardless of content, this e-mail shall > not operate to bind SKOPOS to any order or other contract unless > pursuant to explicit written agreement or government initiative > expressly permitting the use of e-mail for such purpose. > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >=20 --===============0333094533217608240==-- From iheim at redhat.com Wed Dec 12 18:47:24 2012 Content-Type: multipart/mixed; boundary="===============6396694894827702011==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] theoretical scenario Date: Thu, 13 Dec 2012 01:47:30 +0200 Message-ID: <50C91792.4010306@redhat.com> In-Reply-To: 9BE6F493F83A594DA60C45E6A09DC5AC016D644C@AUSP01DAG0201.collaborationhost.net --===============6396694894827702011== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 12/11/2012 09:47 PM, Jonathan Horne wrote: > ok, so the process seems pretty obtuse, so let me run this by the list > here and maybe I'm just not doing it the best way. > > 1) i connected an export domain called EXPORTNFS. the nfs share is > physically on my management server (as is iso) > 2) exported 1 VM. > 3) on the mgmt server, i run "tar zxcf /root/test.tgz > /opt/export/[UUID]/images /opt/export/[UUID]/master" > 4) for good measure, i use ovirt web gui to delete the exported VM from > the export > 5) run the command 'engine-image-uploader =E2=80=93u admin(a)internal upl= oad > test.tgz =E2=80=93v =E2=80=93e EXPORTNFS > 6) after a while, it completes and i see the VM back in the export > storage tab under VM Import. > > i didn't run the vm yet, but I'm assuming thats a successful export and > import. > > so, it seems if i wanted to export each and every VM from one separate > ovirt to another, i would export each VM, tar-gzip it, clear it from the > webgui, and start the next one? IE.. i mean it looks like > engine-image-uploader would be pretty unhappy with finding more than one > set of VM UUIDs inside? apart of Vered's simpler solution, a small note that: 1. engine-image-uploader can handle uploading the same image more than = once and generating uuid's 2. however, i think this capability is deprecated, since engine has = recently added support to import a VM which UUID is already imported, = allowing to create a new VM from the imported one. --===============6396694894827702011==-- From kroberts at redhat.com Wed Dec 12 20:58:54 2012 Content-Type: multipart/mixed; boundary="===============1867856080166107793==" MIME-Version: 1.0 From: Keith Robertson To: users at ovirt.org Subject: Re: [Users] theoretical scenario Date: Wed, 12 Dec 2012 20:58:52 -0500 Message-ID: <50C9365C.6090006@redhat.com> In-Reply-To: 50C91792.4010306@redhat.com --===============1867856080166107793== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 12/12/2012 06:47 PM, Itamar Heim wrote: > On 12/11/2012 09:47 PM, Jonathan Horne wrote: >> ok, so the process seems pretty obtuse, so let me run this by the list >> here and maybe I'm just not doing it the best way. >> >> 1) i connected an export domain called EXPORTNFS. the nfs share is >> physically on my management server (as is iso) >> 2) exported 1 VM. >> 3) on the mgmt server, i run "tar zxcf /root/test.tgz >> /opt/export/[UUID]/images /opt/export/[UUID]/master" >> 4) for good measure, i use ovirt web gui to delete the exported VM from >> the export >> 5) run the command 'engine-image-uploader =E2=80=93u admin(a)internal up= load >> test.tgz =E2=80=93v =E2=80=93e EXPORTNFS >> 6) after a while, it completes and i see the VM back in the export >> storage tab under VM Import. >> >> i didn't run the vm yet, but I'm assuming thats a successful export and >> import. >> >> so, it seems if i wanted to export each and every VM from one separate >> ovirt to another, i would export each VM, tar-gzip it, clear it from the >> webgui, and start the next one? IE.. i mean it looks like >> engine-image-uploader would be pretty unhappy with finding more than one >> set of VM UUIDs inside? Yes, it would. If you want to export all of your VMs all at once and = have no plans to rename them or alter them whatsoever, why not just back = up the entire export storage domain and attach to the new DC/Cluster? WRT to 3. I agree that is a clunky process to create a portable VM. I = would like to create a tool that allows you to pick a VM from available = exported ones and subsequently wrap it up into a .tgz. Shouldn't be too = hard. > > apart of Vered's simpler solution, a small note that: > 1. engine-image-uploader can handle uploading the same image more than = > once and generating uuid's Correct. > 2. however, i think this capability is deprecated, since engine has = > recently added support to import a VM which UUID is already imported, = > allowing to create a new VM from the imported one. Correct. --===============1867856080166107793==--