On Mon, 2008-04-07 at 10:59 +0200, Ferenc Wagner wrote: > Ian Campbell <[EMAIL PROTECTED]> 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.
