[Ovirt-devel] Questions about Xen support

[Perry N. Myers]

Pierre Inglebert wrote:
> Hi ovirt,
> 
> I'm working on the Xen support for oVirt, so first i wanna know if
> anyone else is working on or is interrested to.

Pierre,

Thanks for writing.  We haven't started implementing oVirt for Xen yet, 
but it is on our roadmap.  We definitely want to be able to support a Xen 
host as a managed node in an oVirt network.

> Thanks to libvirt, it is quite easy to make ovirt only work with Xen or
> KVM but not with both because there are some hardcoded parts for KVM.
> 
> This hardcoded parts are in task-omatic (especially in task_vm.rb),
> libvirt uri connections as "qemu+tcp://" don't work with Xen, so i'm
> trying to find a way to dynamicly modify this uri (e.g.change it to "xen
> +tcp://" for xen).
> 
> To do this, we have to know the hypervisor type before the connection,
> we also have to know what type of VM we are creating in case of many
> hypervisor types available and for the migration, the hosts need to have
> the same hypervisor.

I agree with the first part, but not necessarily the second.

For the first part...  What we should do is provide a way for a managed 
node to identify itself to the oVirt server.  Right now when a Managed 
Node using KVM is booted it contacts the oVirt Server (using DNS SRV 
records) to tell it that it is alive.  This mechanism could be extended to 
also provide other information to the oVirt Server like what type of 
Hypervisor the node is.  (So instead of just a HELLO message it could be 
something like, "HELLO:KVM or HELLO:XEN")

The daemon on the oVirt Server that is listening for the HELLO is called 
the ovirt-host-keyadd daemon.  Darryl Pierce is going to be working with 
this daemon and the ovirt-host-browser daemon to merge their functionality 
(and get rid of the Avahi notification process) so it would be worthwhile 
to discuss this in depth with him.

This identification is done presently in an init script on the managed 
node that is placed there by the node kickstart.  This should really be 
moved to an RPM instead of being placed in a kickstart file, and it should 
be made a little more generic so that it can be used on either Xen or KVM 
hosts.

Once we have the ability for a node to identify to the oVirt Server what 
kind of hypervisor it is running, then we need to be able to store that 
information in the database and it in the WUI.  Then when taskomatic 
actions are requested it can use that information to determine the virsh url.

The second part about not being able to move guests from one managed node 
to another is not so clear...  Initially I agree that this should be the 
case, since disk image formats and configuration files will differ 
somewhat.  We may want to simplify the initial support of multiple HV 
types by allowing hardware pools to only contain HVs of one type.  i.e. if 
you have both Managed Nodes (KVM) and RHEL 5.1 hosts (XEN) you could not 
have both of these host types in the same hardware pool.  They need to go 
in separate HW pools with like HV hosts.

However, there is work going on in another project to provide tools to 
migrate guests from one HV to another.  Once we have these tools linked in 
to oVirt, we should be able to run a guest on any HV that we support and 
remove the restriction that hardware pools need to contain nodes with the 
same HV type.

> For me, there are 2 solutions.
> The first solution is to allow an host to have more than one
> hypervisor, these solutions require some changes : 
> - the VM will have an hypervisor type

Agree with this, but eventually we'll allow this to be changed manually or 
even dynamically as the tools for guest HV migrations evolve.

> - On the host, a list of available hypervisors (possibly dynamic?)

What do you mean by host here?  If host == Node (as in Managed Node) then 
there is not a choice.  RHEL will only support Xen and the oVirt Managed 
Node will only support KVM.  I suppose Fedora could support both, but this 
could be detected automatically on node boot (i.e. if you're in a Xen 
kernel say HELLO:XEN, if you detect hardware virt support and are not in a 
Xen kernel say HELLO:KVM to the oVirt server)

> - For the user, we have to ask about hypervisor/arch on the VM creation
> form (from the list of available hypervisors (dynamic listing will be
> hard))

Agree.  We should be able to list only hypervisors that are present in a 
given hardware pool (which for the initial implementation will be 
restricted by the fact that hardware pools have to be homogeneous)

> - for the VM creation/migration task, we have to check if the Host is
> compatible with the VM, 

Eventually, but for initial implementation this can be omitted.

> - during the Host addition, we have to get all the hypervisor
> capabilities.

Agreed

> 
> The second solution is to keep the restriction of one hypervisor by
> Host.
> We can seperate 2 cases :
> - One Hypervisor by Host collection :
>    - Check the availability of the hypervisor during the Host addition.
>    - Move the Hypervisor Type to the Host collection (actually on Host)

Don't know if this should be automatic.  When a new node appears in the 
oVirt WUI it should be identified by what HV is running on it, and it 
should only be permitted to move to a HW pool containing like HVs.
	
> 
> - One Hypervisor by Host (Multiple for Collection) :
>    - Ask user about the hypervisor to use during the Host addition
> (possibility to choose it from a list)

This isn't necessary since the host can tell you what HV it's using.  One 
thing this brings up though... For Fedora since you can use either Xen or 
KVM, you could conceivably toggle he Node back and forth.  If we decide to 
initially implement using homogeneous HW pools, we will have to 
automatically remove the Node from its assigned HW pool if it switches HV 
types...

>    - For the VM creation, ask the user about the hypervisor type from
> the hypervisor list of the Host Collection.
>    - For migration, check available hosts in the Collection.
> 
> So I wanna know what do you think about it.

Good thoughts.  If you want to start looking at creating patches to 
support Xen, it would probably make sense to start with the code on the 
Managed Node for identifying the node to the oVirt Server.  This needs to 
be extracted from the kickstart, made into an RPM and then modified so 
that it identifies the HV type when it communicates to the server.

We also want to eventually send information like hardware capabilities 
(dmidecode info, storage/network devices, processor flags, etc...) as 
well.  So we need to give some thought to how we should package up that 
hardware information for transmission to the server.  The HV type can be 
part of that information that is sent.  There is other work being done 
right now on the hardware enumeration task, so I'd just focus on detecting 
the HV type and sending that data.  We can merge in the additional 
hardware info later.

Perry

-- 
|=-        Red Hat, Engineering, Emerging Technologies, Boston        -=|
|=-                     Email: pmyers at redhat.com                      -=|
|=-         Office: +1 412 474 3552   Mobile: +1 703 362 9622         -=|
|=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=|