Open Stack

I'll let Mate reply to most of the mail - but just to pick up on the HP question

> -----Original Message-----
> From: James E. Blair [mailto:jeblair at openstack.org]
> Sent: 11 December 2013 22:44
> To: Mate Lakat
> Cc: OpenStack Infra
> Subject: Re: [OpenStack-Infra] Nested-virt hypervisor testing
> 
> Two points in 60902 caught my attention:
> 
>   The server created is a XenServer with an Ubuntu VM to run the
>   openstack services. This nested Xen virt will only currently work in
>   the Rackspace cloud. Also, because nested virt will slow things down,
>   lets try running this on performance flavors to give us the best
>   chance of running things at a reasonable speed.
> 
> Is it possible for this to run on other cloud providers (eg, HP, and
> potentially others in the future)?  It's important that our gate jobs be
> able to run on multiple providers.

Fully agreed - we're currently only targeting check jobs, not gate.

Note that the following is based on an incredibly limited understanding of libvirt - I'm very happy if I've mis-understood:

I believe XenServer cannot currently run in the HP cloud as the configuration of qemu in the "old" part of HP's cloud does not support presenting emulated devices, and only presents the virtio devices.  There appears to be a restriction in the virtio drivers which means they cannot be used in dom0 as Xen introduces an abstraction layer which the virtio drivers explicitly don't cope with.  I don't really have more details on this, and if there is someone who can help either with understanding if this scenario is possible then it may re-open that route.

I've been told that it may be possible to change the libvirt model to change the devices presented by qemu, however that depends on a newer version of OpenStack than is in the "old" part of HPs cloud.  My understanding is also that the HP deployment of the more recent OpenStack is not currently useable for openstack jobs - so we haven't investigated that any further.

In terms of additional cloud providers, I do hope that we'll be able to run on the new deployment within HP - however, the fallback could be to integrate with TripleO which would eliminate the "single point of failure".

> The image you select has "(PVHVM beta)" in the name.  Is that related?
> What does it mean?

Nested XenServer must run in an HVM container - i.e. emulated using qemu - rather than PV as Xen on Xen wouldn't work in PV mode.  PVHVM is the name given to an HVM container which then sets up the PV drivers during boot, replacing the emulated devices presented by qemu.

Note that there are also restrictions in Xen meaning that nested XenServer can't actually negotiate up to using the PV drivers, which means it will continue running in the fully virtualised mode.

The PVHVM image is used in the RS cloud because the majority of their images are set to boot as PV and if we used one of those images we would need to snapshot it and manipulate the image metadata to change the mode to HVM - which is another complication we'd rather avoid.

Bob