[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: preliminary patch towards XEN virtual disk naming

On Mon, 2008-04-07 at 10:59 +0200, Ferenc Wagner wrote:
> Ian Campbell <ijc@hellion.org.uk> writes:
> > Do you have plans to work on D-I for Xen extensively? If so we should
> > sync up.
> I've just started with this as in my day job I got responsibe for a
> couple of Xen machines.  Till now I don't think that really extensive
> work is needed, the installer worked almost perfectly.

Yes it is pretty good straight out the box.

The biggest things seem to be support for a PAE (i.e. 686-bigmem)
install image (since most Xen deployments are PAE) and enabling
CONFIG_XEN in all kernel images doing away with the need for special
domU packages. I have patches for the kernel side filed in wishlist bugs

Other than the things you mention I've really only found fairly minor
bits and bobs. I had a TODO with a few bits on it, but I can't find it
now. :-(

> The only real problem is with kbd-chooser, which errors out on me, but
> I could simply skip it with preseeding.  On the other hand, it may be
> a Xen 3.0 issue, HVC support in 3.2 may solve that.  Or at least
> provide a way to fix it right.  Unfortunately I don't have a 3.2
> installation handy, so can't test.

I haven't seen this one. HVC support is a feature of the kernel not the
hypervisor. hvc the just the device name of the virtual console device
in the Linux kernel (2.6.2x+), it speaks the Xen console ring protocol
which I think hasn't changed since Xen 3.0.0. hvc is the same as the xvc
console device in the XenSource kernels apart from the name. Which
kernel are you using?

I just add console=hvc0 to my kernel command line when booting the
installer and all seems ok. There are patches floating around upstream
which should make even this unnecessary eventually.

> Probably related, that I can't use ssh (from openssh-client-udeb) from
> the installation console (tty), it gives the error:
>   debug1: read_passphrase: can't open /dev/tty: No such device or address
>   debug1: Authentications that can continue: publickey,keyboard-interactive
>   debug1: No more authentication methods to try.
> ln -sf /dev/tty /dev/console helps it, though.

Also new to me I'm afraid. Perhaps related to the setting of CONFIG_VT
or your console= cmdline option?

> The grub-installer problem you reported doesn't concern me now, I
> don't use pygrub it this setup.  And seems like you solved it already.

Yes, I need to follow up on those patches, the grub maintainer asked me
to take them to upstream but I got bogged down with the kernel issues.

> Kernel image selection comes to my mind, but again, I don't quite need
> it in my paravirtualized setup, having no boot loader...  And one
> initrd can boot all my machines, they don't really need any kernel
> modules either.  But it can be an issue in different setups.

I think this will come out of enabling Xen in the regular kernels and
using that for the installer. Using a PAE installer image could easily
be a trigger to use a PAE kernel in the final image.

> (I wonder if installing no kernel would skip all the boot loader
> stuff, including nobootloader/confirmation...)
> But a Xen-friendly libc (libc6-xen) would be nice in the installer,
> don't you think?  As far as I know it doesn't penalize real hardware
> setups noticeably, but is a huge gain under Xen.  And in the target
> system the correct version could be installed anyway.

I hadn't thought of this one -- I typically run a 64 bit hypervisor 
where the special libc is not required. Even on 32 bit it is a
performance enhancement (rather than a critical fix) so it could
conceivably be done later although it would be nice to have it done


> I also changed debian-installer/exit/always_halt to true, because the
> Xen config is not reread on domU reboot, so I couldn't change the
> ramdisk.  If it's still the case in Xen 3.2, this could be detected
> automatically for the very least.  And also noted that the initrd
> should be copied out...  But this again depends on the type of
> virtualization and pygrub usage, I can only see a narrow slice.
> Well, it seems pretty much, but neither is a real show stopper for me.
> (No support for partitionable raids is more of one, but unrelated.)
> Still, I'm willing to put some work into the above, so please share
> your thoughts on the matter!
Ian Campbell

I've already told you more than I know.

Reply to: