<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 8, 2018 at 11:52 PM, Sam McLeod <span dir="ltr">&lt;<a href="mailto:mailinglists@smcleod.net" target="_blank">mailinglists@smcleod.net</a>&gt;</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">Hi Yaniv,<div><br></div><div>Thanks for your detailed reply, it&#39;s very much appreciated.</div><div><br></div><div><div><span class="m_918542468704295143gmail-"><blockquote type="cite"><div>On 5 Jan 2018, at 8:34 pm, Yaniv Kaul &lt;<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>&gt; wrote:</div><br class="m_918542468704295143gmail-m_978673399576146281Apple-interchange-newline"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:13px;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"><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&#39;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&#39;s what has to be done, we&#39;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></div></blockquote><div><br></div></span><div>That&#39;s not too much of an issue for us, we have a pretty standard set of configuration for performance / sizing.</div><span class="m_918542468704295143gmail-"><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:13px;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"><div>- Data - the disks themselves.</div></div></div></blockquote><div><br></div></span><div>This is the big one, for most hosts at least the data is on a dedicated logical volume, for example if it&#39;s postgresql, it would be LUKS on top of a logical volume for /var/lib/pgsql etc....</div><span class="m_918542468704295143gmail-"><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:13px;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"><div>- Adjusting VM internal data (paths, boot kernel, grub?, etc.)</div></div></div></blockquote><div><br></div></span><div>Everything is currently PVHVM which uses standard grub2, you could literally dd any one of our VMs to a physical disk and boot it in any x86/64 machine.</div><span class="m_918542468704295143gmail-"><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Helvetica;font-size:13px;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"><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&#39;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 &#39;dd&#39; from LUN/LV/raw/? to a raw volume in oVirt.</div><div>2. (My preferred option), copy using &#39;dd&#39; from LUN/LV/raw and upload using the oVirt upload API (example in Python[2]). I think that&#39;s an easy to implement option and provides the flexibility to copy from pretty much any source to oVirt.</div></div></blockquote><div><br></div></span><div>A key thing here would be how quickly the oVirt API can ingest the data, our storage LUNs are 100% SSD each LUN can easily provide at least 1000MB/s and around 2M 4k write IOP/s and 2-4M 4k read IOP/s so we always find hypervisors disk virtualisation mechanisms to be the bottleneck - but adding an API to the mix, especially one that is single threaded (if that does the data stream processing) could be a big performance problem.</div></div></div></div></blockquote><div><br></div><div>Well, it&#39;s just for the data copy. We can do ~300 or so MBps in a single upload API call, but you can copy multiple disks via multiple hypervisors in parallel. In addition, if you are using &#39;dd&#39; you might even be able to use sg_xcopy (if it&#39;s the same storage) - worth looking into it. </div><div>In any case, we have concrete plans to improve the performance of the upload API.</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><span class="m_918542468704295143gmail-"><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Helvetica;font-size:13px;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"><div>3. There are ways to convert XVA to qcow2 - I saw some references on the Internet, never tried any.</div></div></blockquote><div><br></div></span><div>This is something I was thinking of potentially doing, I can actually export each VM as an OVF/OVA package - since that&#39;s very standard I&#39;m assuming oVirt can likely import them and convert to qcow2 or raw/LVM?</div></div></div></div></blockquote><div><br></div><div>Well, in theory, OVF/OVA is a standard. In practice, it&#39;s far from it - it defines how the XML should look and what it contains, but a VMware para-virtual NIC is not a para-virtual Xen NIC is not an oVirt para-virtual NIC, so the fact it describes a NIC means nothing when it comes to cross-platform compatibility.</div><div><br></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><span class="m_918542468704295143gmail-"><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Helvetica;font-size:13px;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"><div><br></div><div>As for the last item, I&#39;m really not sure what changes are needed, if at all. I don&#39;t know the disk convention, for example (/dev/sd* for SCSI disk -&gt; virtio-scsi, but are there are other device types?)</div></div></blockquote><div><br></div></span><div>Xen&#39;s virtual disks are all /dev/xvd[a-z]</div><div>Thankfully, we partition everything as LVM and partitions (other than boot I think) are mounted as such.</div></div></div></div></blockquote><div><br></div><div>And there&#39;s nothing that needs to address such path as /dev/xvd* ?</div><div>Y.</div><div><br></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><div><span class="m_918542468704295143gmail-"><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Helvetica;font-size:13px;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"><div><br></div><div>I&#39;d be happy to help with any adjustment needed for the Python script below.</div></div></blockquote><div><br></div></span><div>Very much appreciated, when I get to the point where I&#39;m happy with the basic architectural design and POC deployment of oVirt - that&#39;s when I&#39;ll be testing importing VMs / data in various ways and have made note of these scripts.</div><span class="m_918542468704295143gmail-"><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Helvetica;font-size:13px;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"><div><br></div><div>Y.</div><div><br></div><div>[1] <a href="http://docs.ansible.com/ansible/latest/xenserver_facts_module.html" target="_blank">http://docs.ansible.com/an<wbr>sible/latest/xenserver_facts_<wbr>module.html</a></div><div>[2] <a href="https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_disk.py" target="_blank">https://github.com/oVirt/o<wbr>virt-engine-sdk/blob/master/sd<wbr>k/examples/upload_disk.py</a></div><div> </div></div></blockquote></span></div><br></div></div></blockquote></div><br></div></div>