Open Stack

> > If you have the Open vSwitch components installed in domain 0, then
> there
> > are a few scripts that wrap around it to set up the isolation rules
> used
> > in flat mode.  These are in nova/plugins/xenapi/networking.
> 
> I believe you mean: plugins/xenserver/networking

Yes, those are the ones.

> Nova in Debian now creates a nova-xcp-plugins taking files from
> plugins/xenserver/xenapi/. I now believe that I should also make a
> nova-xcp-network package.
> 
> Having a quick look at the files in the plugins/xenserver/networking
> folder, these would need some re-work. For example, the init.d scripts
> are lacking LSB headers (to be used by insserv for parallel booting),
> and also there's an etc/sysconfig, which really, is too much CentOS /
> RedHat centric (in Debian, it would go in /etc/default).
> 
> Now, I saw files in etc/xensource/scripts. I suppose that these, in
> Debian, to respect both FHS and the work we've done with Mike and Jon,
> these files should go in /usr/lib/xcp/scripts/. I just hope there's no
> references to the wrong CentOS path in these scripts! If you know
> things
> that should be adapted right away, it'd be great to have the fixes made
> for runtime, rather than a Debian specific patch, IMO, because patches
> are annoying to maintain.
> 
> You can expect that I will contribute these adaptations for Debian in
> the next following days, and also fix the packaging to add this new
> nova-xcp-network binary package.
> 
> I will let you know how it goes.

Those scripts are going to be 100% CentOS/XenServer dependent right now.  They've been written specifically for that environment, and I don't know of anyone who's tried them in a pure Debian environment.

We can certainly take any changes that would be required to make them work in either environment.

> >> Does OpenStack + XCP still use nova-network? Is all traffic for the
> VMs
> >> routed through it as with KVM and libvirt? Should I still create a
> >> bridge on the nova-network domU?
> >
> > It depends on which network mode you're using.  If you're using the
> > HA modes, then yes, traffic goes through nova-network.  In flat mode
> > it will come directly to domain 0 and the vSwitch.
> 
> And using the VLAN manager?

VLAN without HA will come through domain 0 directly I believe.  The VLANs are managed as ports on the Open vSwitch.

> > Devstack has all of the domU setup for HA networking
> > -- see https://blueprints.launchpad.net/nova/+spec/xenapi-ha-nova-
> network.
> 
> I've always been directed to devstack, however, I'm really not
> interested at all in using it: I'm working on packaging things
> correctly
> for Debian, and as a consequence, I want to use *only* the Debian
> packages that we produce. Of course, I'll keep updating and modifying
> them until it works.

The point of directing you to devstack is not to say "go use devstack" it's to say "go read devstack and see what it does".  Devstack is used to set up automated test systems, so it's always up to date with the configuration required in OpenStack.  If you're in any doubt, it's the canonical reference for configuration settings.

> >> How does Openstack injects IP addresses in an XCP VM? Can this even
> be
> >> done?
> >
> > It talks to an in-guest agent, typically. It writes it to XenStore,
> and
> > then this is picked up by the agent inside the VM.
> 
> So, running the XCP software inside the VM is mandatory? If so, this
> should change IMO, it's really not hosting provider friendly: customers
> expect to take any AMI image, possibly from AWS, and run them on the
> cloud, we can't force customers to use specific VM images for XCP.

You're not running XCP inside the VM.  You're running an agent inside the VM.

If you don't want to do that, then you either have to accept filesystem injection (which some people like, some people don't) or you have to use DHCP to configure IP addresses.

> > Security groups have only recently been implemented for XenAPI:
> > https://blueprints.launchpad.net/nova/+spec/xenapi-security-groups.
> > That got merged less than two weeks ago.
> 
> Will this be in e3?

Yes.

> Do you know if the OVF files exported by VirtualBox would work?

I have never tried that.  You'd maybe be able to get it to work with a bit of effort, but you're likely to run into problems with the different kernel / driver set that I presume vbox uses.  Citrix has a product -- XenConvert -- which deals with all of these kinds of conversion issues and will swap out drivers and so on.  It's not a very simple problem to solve.  Particularly the Windows case.  You might be OK with up-to-date Linux though (i.e. 3.2 kernels).

> >> 3/ Console
> >> on the same wiki page, it tells about using VNC. While this does
> work,
> >> I
> >> didn't have access to the login prompt. What's the way, if using
> >> openstack, to tell that the console is hvc0 (or whatever is the Xen
> >> console device name)?
> >
> > That's dependent on the in-guest setup.  I think on latest Sid you'll
> need to have an entry in /etc/init/hvc0.conf, similar to this:
> >
> > start on stopped rc RUNLEVEL=[2345]
> > stop on runlevel [!2345]
> >
> > respawn
> > exec /sbin/getty -L hvc0 9600 linux
> 
> This is an upstart script, that's really not for Debian, but for
> Ubuntu!

*sigh*  I'm not even going to ask why Ubuntu and Debian have different init systems.

> I can adapt it, however, the issue is that images that we find on the
> net wont have this by default. So, I thought that best would be to have
> added, automatically by XenServer / XCP, a parameter on the command
> like
> like: tty1=hvc0 (or similar), so that such thing wouldn't be needed.
> Any
> thoughts?

If you're going to allow your customers to install arbitrary images, then you're always going to be in the situation where some of these settings work, and some don't.  The console renamed from xvc0 to hvc0 not that long ago, for example.  I think you're going to struggle to find a way to make everything work perfectly.  If I were you I'd choose some specific images, such as the most recent Rackspace ones, or the most recent Amazon ones, and experiment with just those few.

Cheers,

Ewan.