<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Yaniv,<div class=""><br class=""></div><div class="">Thanks for your detailed reply, it's very much appreciated.</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 5 Jan 2018, at 8:34 pm, Yaniv Kaul <<a href="mailto:ykaul@redhat.com" class="">ykaul@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><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; -webkit-text-stroke-width: 0px;"><div class="">Indeed, greenfield deployment has its advantages.</div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">The migration of VMs has three parts:</div><div class="">- VM configuration data (from name to number of CPUs, memory, etc.)</div></div></div></blockquote><div><br class=""></div><div>That's not too much of an issue for us, we have a pretty standard set of configuration for performance / sizing.</div><br class=""><blockquote type="cite" class=""><div class=""><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; -webkit-text-stroke-width: 0px;"><div class="">- Data - the disks themselves.</div></div></div></blockquote><div><br class=""></div><div>This is the big one, for most hosts at least the data is on a dedicated logical volume, for example if it's postgresql, it would be LUKS on top of a logical volume for /var/lib/pgsql etc....</div><br class=""><blockquote type="cite" class=""><div class=""><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; -webkit-text-stroke-width: 0px;"><div class="">- Adjusting VM internal data (paths, boot kernel, grub?, etc.)</div></div></div></blockquote><div><br class=""></div><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><br class=""><blockquote type="cite" class=""><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; -webkit-text-stroke-width: 0px;"><div class="">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 class="">The 2nd - data movement could be done in at least two-three ways:</div><div class="">1. Copy using 'dd' from LUN/LV/raw/? to a raw volume in oVirt.</div><div class="">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></blockquote><div><br class=""></div><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><br class=""><blockquote type="cite" class=""><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; -webkit-text-stroke-width: 0px;"><div class="">3. There are ways to convert XVA to qcow2 - I saw some references on the Internet, never tried any.</div></div></blockquote><div><br class=""></div><div>This is something I was thinking of potentially doing, I can actually export each VM as an OVF/OVA package - since that's very standard I'm assuming oVirt can likely import them and convert to qcow2 or raw/LVM?</div><br class=""><blockquote type="cite" class=""><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; -webkit-text-stroke-width: 0px;"><div class=""><br class=""></div><div class="">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></blockquote><div><br class=""></div><div>Xen'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><br class=""><blockquote type="cite" class=""><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; -webkit-text-stroke-width: 0px;"><div class=""><br class=""></div><div class="">I'd be happy to help with any adjustment needed for the Python script below.</div></div></blockquote><div><br class=""></div><div>Very much appreciated, when I get to the point where I'm happy with the basic architectural design and POC deployment of oVirt - that's when I'll be testing importing VMs / data in various ways and have made note of these scripts.</div><br class=""><blockquote type="cite" class=""><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; -webkit-text-stroke-width: 0px;"><div class=""><br class=""></div><div class="">Y.</div><div class=""><br class=""></div><div class="">[1] <a href="http://docs.ansible.com/ansible/latest/xenserver_facts_module.html" class="">http://docs.ansible.com/ansible/latest/xenserver_facts_module.html</a></div><div class="">[2] <a href="https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_disk.py" class="">https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/upload_disk.py</a></div><div class=""> </div></div></blockquote></div><br class=""></div></body></html>