5:54 a.m.
On Mon, Jan 8, 2018 at 11:52 PM, Sam McLeod <mailinglists(a)smcleod.net>
wrote:
Hi Yaniv,
Thanks for your detailed reply, it's very much appreciated.
On 5 Jan 2018, at 8:34 pm, Yaniv Kaul <ykaul(a)redhat.com> wrote:
Indeed, greenfield deployment has its advantages.
>
> 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.
>
The migration of VMs has three parts:
- VM configuration data (from name to number of CPUs, memory, etc.)
That's not too much of an issue for us, we have a pretty standard set of
configuration for performance / sizing.
- Data - the disks themselves.
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....
- Adjusting VM internal data (paths, boot kernel, grub?, etc.)
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.
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?
The 2nd - data movement could be done in at least two-three ways:
1. Copy using 'dd' from LUN/LV/raw/? to a raw volume in oVirt.
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.
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.
Well, it'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 'dd' you might even be able to
use sg_xcopy (if it's the same storage) - worth looking into it.
In any case, we have concrete plans to improve the performance of the
upload API.
3. There are ways to convert XVA to qcow2 - I saw some references on the
Internet, never tried any.
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?
Well, in theory, OVF/OVA is a standard. In practice, it'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.
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?)
Xen's virtual disks are all /dev/xvd[a-z]
Thankfully, we partition everything as LVM and partitions (other than boot
I think) are mounted as such.
And there's nothing that needs to address such path as /dev/xvd* ?
Y.
I'd be happy to help with any adjustment needed for the Python script
below.
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.
Y.
[1] http://docs.ansible.com/ansible/latest/xenserver_facts_module.html
[2] https://github.com/oVirt/ovirt-engine-sdk/blob/master/sd
k/examples/upload_disk.py