<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 5, 2018 at 12:19 AM, Sam McLeod <span dir="ltr"><<a href="mailto:mailinglists@smcleod.net" target="_blank">mailinglists@smcleod.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Thanks for your response Yaniv,<div><br></div><div><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Context: Investigating migration from XenServer to oVirt (4.2.0)</div></div></blockquote><div><br></div><div>A very interesting subject - would love to see the outcome!</div></div></blockquote></div></div></div></blockquote><div><br></div></span><div>I'll certainly be writing one of not many blog posts on the process and outcome :)</div><div><br></div><div>We've been wanting to switch to something more 'modern' for a while, but XenServer has had a very low TCO for us, sure it doesn't perform as well as Xen/KVM setup on top of CentOS/RHEL with updated kernels, tuning etc... but it just kept working, meanwhile we lost some people in my team so it hasn't been the right time to look at moving... until now...</div><div><br></div><div>Citrix / XenServer recently screwed over the community (I don't use that term lightly) by kneecapping the free / unlicensed version of XenServer: <a href="https://xenserver.org/blog/entry/xenserver-7-3-changes-to-the-free-edition.html" target="_blank">https://xenserver.<wbr>org/blog/entry/xenserver-7-3-<wbr>changes-to-the-free-edition.<wbr>html</a></div><div><br></div><div>There's a large number of people very unhappy about this, as many of the people that contribute heavily to bug reporting, testing and rapid / modern deployment lifecycles were / are using the unlicensed version (like us over @infoxchange), so for us - this was the straw that broke the camel's back.</div><div><br></div><div>I've been looking into various options such as oVirt, Proxmox, OpenStack and a roll-your-own libvirt style platform based on our CentOS (7 at present) SOE, so far oVirt is looking promising.</div><span class="gmail-"><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>All our iSCSI storage is currently attached to XenServer hosts, XenServer formats those raw LUNs with LVM and VMs are stored within them.</div></div></blockquote><div><br></div><div>I suspect we need to copy the data. We might be able to do some tricks, but at the end of the day I think copying the data, LV to LV, makes the most sense.</div><div>However, I wonder what else is needed - do we need a conversion of the drivers, different kernel, etc.?</div></div></blockquote></div></div></div></blockquote><div><br></div></span><div>All our Xen VMs are PVHVM, so there's no reason we could't export them as files, then import them to oVirt of we do go down the oVirt path after the POC.</div><div>We run kernel-ml across our fleet (almost always running near-latest kernel release) and automate all configuration with Puppet.</div><div><br></div><div>The issue I have with this is that it will be slow - XenServer's storage performance is <i>terrible</i> and there'd be lots of manual work involved.</div><div><br></div><div>If this was to be the most simple option, I think we'd opt for rebuilding VMs from scratch, letting Puppet setup their config etc... then restoring data from backups / rsync etc... that way we'd still be performing the manual work - but we'd end up with nice clean VMs.</div></div></div></blockquote><div><br></div><div>Indeed, greenfield deployment has its advantages.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>The down side to that is juggling iSCSI LUNs, I'll have to migrate VMs on XenServer off one LUN at a time, remove that LUN from XenServer and add it to oVirt as new storage, and continue - but if it's what has to be done, we'll do it.</div></div></div></blockquote><div><br></div><div>The migration of VMs has three parts:</div><div>- VM configuration data (from name to number of CPUs, memory, etc.)</div><div>- Data - the disks themselves.</div><div>- Adjusting VM internal data (paths, boot kernel, grub?, etc.)</div><div><br></div><div>The first item could be automated. Unfortunately, it was a bit of a challenge to find a common automation platform. For example, we have great Ansible support, which I could not find for XenServer (but[1], which may be a bit limited). Perhaps if there aren't too many VMs, this could be done manually. If you use Foreman, btw, then it could probably be used for both to provision?</div><div>The 2nd - data movement could be done in at least two-three ways:</div><div>1. Copy using 'dd' from LUN/LV/raw/? to a raw volume in oVirt.</div><div>2. (My preferred option), copy using 'dd' from LUN/LV/raw and upload using the oVirt upload API (example in Python[2]). I think that's an easy to implement option and provides the flexibility to copy from pretty much any source to oVirt.</div><div>3. There are ways to convert XVA to qcow2 - I saw some references on the Internet, never tried any.</div><div><br></div><div>As for the last item, I'm really not sure what changes are needed, if at all. I don't know the disk convention, for example (/dev/sd* for SCSI disk -> virtio-scsi, but are there are other device types?)</div><div><br></div><div>I'd be happy to help with any adjustment needed for the Python script below.</div><div><br></div><div>Y.</div><div><br></div><div>[1] <a href="http://docs.ansible.com/ansible/latest/xenserver_facts_module.html">http://docs.ansible.com/ansible/latest/xenserver_facts_module.html</a></div><div>[2] <a href="https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_disk.py">https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_disk.py</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>What are the export options Xen provides? Perhaps OVF?</div><div>Is there an API to stream the disks from Xen?</div><div>Y.</div></div></blockquote></div></div></div></blockquote><div><br></div></span><div>Yes, Xen does have an API, but TBH - it's pretty awful to work with, think XML and lots of UUIDs...</div><span class="gmail-"><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div></div></blockquote></div></blockquote></div></div></div></blockquote><div>
<div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>--<br>Sam McLeod<br><a href="https://smcleod.net" target="_blank">https://smcleod.net</a><br><a href="https://twitter.com/s_mcleod" target="_blank">https://twitter.com/s_mcleod</a></div></div></div></div>
</div>
</span><div><div class="gmail-h5"><div><br><blockquote type="cite"><div>On 4 Jan 2018, at 7:58 pm, Yaniv Kaul <<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>> wrote:</div><br class="gmail-m_-3862716690318880688Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 4, 2018 at 4:03 AM, Sam McLeod <span dir="ltr"><<a href="mailto:mailinglists@smcleod.net" target="_blank">mailinglists@smcleod.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>If one was to attach a shared iSCSI LUN as 'storage' to an oVirt data centre that contains existing data - how does oVirt behave?</div><div><br></div><div>For example the LUN might be partitioned as LVM, then contain existing filesystems etc...</div><div> </div><div>- Would oVirt see that there is existing data on the LUN and simply attach it as any other linux initiator (client) world, or would it try to wipe the LUN clean and reinitialise it?</div></div></blockquote><div><br></div><div>Neither - we will not be importing these as existing data domains, nor wipe them, as they have contents.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><br></div><div>Context: Investigating migration from XenServer to oVirt (4.2.0)</div></div></blockquote><div><br></div><div>A very interesting subject - would love to see the outcome!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>All our iSCSI storage is currently attached to XenServer hosts, XenServer formats those raw LUNs with LVM and VMs are stored within them.</div></div></blockquote><div><br></div><div>I suspect we need to copy the data. We might be able to do some tricks, but at the end of the day I think copying the data, LV to LV, makes the most sense.</div><div>However, I wonder what else is needed - do we need a conversion of the drivers, different kernel, etc.?</div><div><br></div><div>What are the export options Xen provides? Perhaps OVF?</div><div>Is there an API to stream the disks from Xen?</div><div>Y.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><br></div><div><br></div><div><i>If the answer to this is already out there and I should have found it by searching, I apologise, please point me to the link and I'll RTFM.</i></div><div><div>
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>--<br>Sam McLeod<br><a href="https://smcleod.net/" target="_blank">https://smcleod.net</a><br><a href="https://twitter.com/s_mcleod" target="_blank">https://twitter.com/s_mcleod</a></div></div></div></div>
</div>
<br></div></div><br>______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div>