<div dir="ltr">On Wed, Oct 2, 2013 at 1:36 AM, Itamar Heim <span dir="ltr"><<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 10/02/2013 12:40 AM, Christian Kolquist wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am planning on testing the modify existing to become an export domain.<br>
� That will only require me to copy within the isilon cluster a copy of<br>
the data which only will take about 1 hour. �The plan is to do the<br>
following:<br>
<br>
1. Load Fedora 19 on new engine server and install the engine, add new<br>
storage domain shares and get fully up and running without adding any nodes<br>
</blockquote>
<br></div>
just wondering - any reason you prefer fedora to .el6 (centos/rhel)?</blockquote><div>We use Fedora on most of our systems here. �We use kickstart and puppet to manage them and already have nearly everything ready to go with it.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. shutdown all VM's and then remove the nodes<br>
3. shutdown engine on current server<br>
4. copy the existing storage domain to another location on the NAS and<br>
share it out over NFS.<br>
5. Add nodes to new engine<br>
6. Modify the copy of the storage domain to be an export domain<br>
(<a href="http://humblec.com/convert-master-data-domain-to-export-domain-in-a-crashed-rhevmovirt-setup/" target="_blank">http://humblec.com/convert-<u></u>master-data-domain-to-export-<u></u>domain-in-a-crashed-<u></u>rhevmovirt-setup/</a>)<br>
7. Add it in as an existing export domain on the new engine server and<br>
start import of VM's (will take probably 4-6 hours or maybe longer,<br>
total storage is ~1TB of data)<br>
<br>
Are there any further suggestions to this? �If this plan fails then I<br>
will be able to revert back to the original engine server and domain.<br>
</blockquote>
<br></div>
sounds good to me<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
Christian<br>
<br>
<br>
<br>
<br>
On Tue, Oct 1, 2013 at 10:48 AM, Itamar Heim <<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a>>> wrote:<br>
<br>
� � On 10/01/2013 06:39 PM, Christian Kolquist wrote:<br>
<br>
� � � � We have a NFS storage cluster (Isilon) for the domain.<br>
<br>
� � � � The main question: is there a way to bring in an existing<br>
� � � � storage domain<br>
� � � � to a new engine without exporting it then importing it? �This<br>
� � � � would be<br>
� � � � good for not just upgrades but also disaster recovery as well.<br>
<br>
<br>
<br>
� � yes, importing an existing data domain is a high priority for us for<br>
� � next version as the issue was raised several times by community users.<br>
<br>
� � for 3.3, there a few options (the first one is the cleanest)<br>
� � 1. "save the export part"<br>
� � - stop using the domain in 3.1<br>
� � - change its meta data to that of an export domain<br>
� � - import it as an existing export domain to 3.3<br>
� � - import the VMs<br>
<br>
� � 2. "re-create the VMs / import disks"<br>
� � - stop using the domain in 3.1<br>
� � - create a new (empty) domain in 3.3<br>
� � - move all disks to the new domain (assuming you create the new nfs<br>
� � � �export in a way allowing you to move, not copy, from the old export)<br>
� � - use the register disk api to add all disks<br>
� � - create VMs and associate the disks to them<br>
<br>
� � yes, this one requires to document first which disk is for which VM.<br>
� � i think someone scripted something around this option.<br>
<br>
� � if your disks have snapshots, this may become too complex.<br>
<br>
� � 3. re-create the VMs and override their disks.<br>
� � this was suggested several times in the past, but if you have<br>
� � snapshots, not relevant.<br>
<br>
<br>
<br>
� � � � On Tue, Oct 1, 2013 at 8:24 AM, Itamar Heim <<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a><br>
� � � � <mailto:<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a>><br></div></div><div><div class="h5">
� � � � <mailto:<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a> <mailto:<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a>>>> wrote:<br>
<br>
� � � � � � �On 09/30/2013 04:55 PM, Christian Kolquist wrote:<br>
<br>
� � � � � � � � �So, after many frustrating weekends of trying to<br>
� � � � upgrade ovirt<br>
� � � � � � � � �from 3.1,<br>
� � � � � � � � �I have come to the conclustion that it would just be<br>
� � � � best to<br>
� � � � � � � � �export all<br>
� � � � � � � � �of our VM's and Import them once I have redone the entire<br>
� � � � � � � � �installation<br>
� � � � � � � � �with FC19 and ovirt 3.3. �Is there a way to export the<br>
� � � � entire domain<br>
� � � � � � � � �easily? Or to bring the entire domain into a new<br>
� � � � install of the<br>
� � � � � � � � �engine?<br>
<br>
� � � � � � � � �Exporting a single VM takes a very long while. �It<br>
� � � � would take a<br>
� � � � � � � � �couple<br>
� � � � � � � � �of days to export all of our VM's (33 total vm's using<br>
� � � � 1.017 TB<br>
� � � � � � � � �of data)<br>
� � � � � � � � �and then reimport them using the normal means of<br>
� � � � exporting the<br>
� � � � � � � � �machines<br>
� � � � � � � � �off then on to the export domain, load the new engine<br>
� � � � server<br>
� � � � � � � � �then import<br>
� � � � � � � � �them all back in.<br>
<br>
<br>
� � � � � � � � �Any tips or tricks would be welcome.<br>
<br>
<br>
� � � � � � �do you have a single data domain in the DC?<br>
� � � � � � �is it nfs or something else?<br>
<br>
<br>
<br>
� � � � � � � � �Christian<br>
<br>
<br>
� � � � � � � � �FYI, I ran into just about every single bug that people<br>
� � � � had when<br>
� � � � � � � � �upgrading from 3.1 to 3.2 and a few more. �I can't<br>
� � � � spend any<br>
� � � � � � � � �more time<br>
� � � � � � � � �troubleshooting the upgrade process. �If we can't do the<br>
� � � � � � � � �export->import<br>
� � � � � � � � �easily or migrate the current storage domain we will<br>
� � � � probably<br>
� � � � � � � � �have to<br>
� � � � � � � � �get rid of ovirt and move to another solution.<br>
<br>
<br>
<br>
<br></div></div>
� � � � ------------------------------<u></u>____--------------------------<u></u>--__--__---<div class="im"><br>
<br>
� � � � � � � � �This email, along with any attachments, is<br>
� � � � confidential. If you<br>
� � � � � � � � �believe you received this message in error, please<br>
� � � � contact the<br>
� � � � � � � � �sender immediately and delete all copies of the message.<br>
� � � � � � � � �Thank you.<br>
<br>
<br></div>
� � � � � � � � �______________________________<u></u>_____________________<br>
� � � � � � � � �Users mailing list<br>
� � � � <a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a> <mailto:<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a>> <mailto:<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
� � � � <mailto:<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a>>><br>
� � � � <a href="http://lists.ovirt.org/____mailman/listinfo/users" target="_blank">http://lists.ovirt.org/____<u></u>mailman/listinfo/users</a><br>
� � � � <<a href="http://lists.ovirt.org/__mailman/listinfo/users" target="_blank">http://lists.ovirt.org/__<u></u>mailman/listinfo/users</a>><br>
� � � � � � � � �<<a href="http://lists.ovirt.org/__mailman/listinfo/users" target="_blank">http://lists.ovirt.org/__<u></u>mailman/listinfo/users</a><br>
� � � � <<a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/<u></u>mailman/listinfo/users</a>>><div class="im"><br>
<br>
<br>
<br>
<br>
<br>
� � � � ------------------------------<u></u>__----------------------------<u></u>--__---<br>
� � � � This email, along with any attachments, is confidential. If you<br>
� � � � believe you received this message in error, please contact the<br>
� � � � sender immediately and delete all copies of the message.<br>
� � � � Thank you.<br>
<br>
<br>
� � � � ______________________________<u></u>___________________<br>
� � � � Users mailing list<br>
� � � � <a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a> <mailto:<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a>><br>
� � � � <a href="http://lists.ovirt.org/__mailman/listinfo/users" target="_blank">http://lists.ovirt.org/__<u></u>mailman/listinfo/users</a><br>
� � � � <<a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/<u></u>mailman/listinfo/users</a>><br>
<br>
<br>
<br>
<br>
<br>
------------------------------<u></u>------------------------------<u></u>---<br>
This email, along with any attachments, is confidential. If you<br>
believe you received this message in error, please contact the<br>
sender immediately and delete all copies of the message.<br>
Thank you.<br>
</div></blockquote>
<br>
</blockquote></div><br></div></div>
<br>
<div><br></div><div>------------------------------<WBR>------------------------------<WBR>---</div><div>This email, along with any attachments, is confidential. If you�</div><div>believe you received this message in error, please contact the�</div><div>sender immediately and delete all copies of the message. �</div><div>Thank you.</div>