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
now.
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
automatically.
Cheers,
Ian.
>
> 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: