hello all, i''ve been messing around with Xen, and it seems that most HOWTOs document installs by using prebuilt images. i''m rather anal about my installs though, and i want to be able to boot CDs (or ISO images). i''ve tried the following config: kernel = "/boot/vmlinuz-2.6-xen" memory = 128 name = "andre_test_01" cpus = "1" # leave to Xen to pick vif = [ ''bridge=xenbr0'' ] disk = [ ''file:/xendisks/andre_test.img,sda1,w'', ''file:/xendisks/andre_test_swap.img,sda2,w'', ''file:/xendisks/install-isoS/install.iso,hdc,r'' ] ramdisk = "/boot/initrd.img-2.6.16.33-xen" boot = "d" the boot = d is apparently used to boot the cdrom, but it doesn''t work for me. i''ve tried copying the vmlinuz and initrd. does any one have any ideas? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Jun 05, 2007 at 05:41:58PM +0100, Andre Grove wrote:> hello all, > > i''ve been messing around with Xen, and it seems that most HOWTOs > document installs by using prebuilt images. > i''m rather anal about my installs though, and i want to be able to > boot CDs (or ISO images). i''ve tried the following config: > > kernel = "/boot/vmlinuz-2.6-xen" > memory = 128 > name = "andre_test_01" > cpus = "1" # leave to Xen to pick > vif = [ ''bridge=xenbr0'' ] > disk = [ ''file:/xendisks/andre_test.img,sda1,w'', > ''file:/xendisks/andre_test_swap.img,sda2,w'', > ''file:/xendisks/install-isoS/install.iso,hdc,r'' ] > ramdisk = "/boot/initrd.img-2.6.16.33-xen" > boot = "d" > > the boot = d is apparently used to boot the cdrom, but it doesn''t work > for me. i''ve tried copying the vmlinuz and initrd.CDROM''s are only used in fully-virt guests - your config here is a paravirt guest so there''s no boot option available. Paravirt guests can only boot off a kernel/initrd (or via a bootloader like pygrub). Fullyvirt guests have a real BIOS so boot from the MBR of the disk, from CDROM, Floppy or PXE from the network. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
What are you trying to install? As Daniel said, in general installing from CD-ROMs will only work in HVM. However, there are a number of possible options: * Fedora / RHEL (and possibly SuSE?) can be installed paravirtualised from CD-ROM if you boot using the Xenified install kernel and initrd from the disk. * If you have hardware virtualisation extensions, install in HVM mode then convert to paravirtualised by installing a Xenified kernel. * Install from CD-ROM in Qemu, then convert to paravirtualised by installing a Xenified kernel. * For Debian / Ubuntu installs you can just use debootstrap to build a filesystem in a directory tree. debootstrap runs on non-debian distros, I think. * There are other possibilities (e.g. I think RedHat''s virt-manager can install RH (/ SuSE guests in future?) from network shares. Would one of these work for you? (nb. Fedora / RHEL only support PAE hosts, so you need to have a PAE Xen installed). It''d be kinda nice if there were a standardised spec for "how to boot an ISO in a paravirt VM". This would require some kind of agreement between the distributors to do things in a uniform way, but it would move us closer to a "just works" type setup - surely a good thing. It seems relatively unfortunate for the install procedure for each paravirt guest to be slightly different so that the user or tools has to understand those differences. Cheers, Mark On Tuesday 05 June 2007, Andre Grove wrote:> hello all, > > i''ve been messing around with Xen, and it seems that most HOWTOs > document installs by using prebuilt images. > i''m rather anal about my installs though, and i want to be able to > boot CDs (or ISO images). i''ve tried the following config: > > kernel = "/boot/vmlinuz-2.6-xen" > memory = 128 > name = "andre_test_01" > cpus = "1" # leave to Xen to pick > vif = [ ''bridge=xenbr0'' ] > disk = [ ''file:/xendisks/andre_test.img,sda1,w'', > ''file:/xendisks/andre_test_swap.img,sda2,w'', > ''file:/xendisks/install-isoS/install.iso,hdc,r'' ] > ramdisk = "/boot/initrd.img-2.6.16.33-xen" > boot = "d" > > the boot = d is apparently used to boot the cdrom, but it doesn''t work > for me. i''ve tried copying the vmlinuz and initrd. > > does any one have any ideas? > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users-- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> On Tue, Jun 05, 2007 at 05:41:58PM +0100, Andre Grove wrote: > > hello all, > > > > i''ve been messing around with Xen, and it seems that most HOWTOs > > document installs by using prebuilt images. > > i''m rather anal about my installs though, and i want to be able to > > boot CDs (or ISO images). i''ve tried the following config: > > > > kernel = "/boot/vmlinuz-2.6-xen" > > memory = 128 > > name = "andre_test_01" > > cpus = "1" # leave to Xen to pick > > vif = [ ''bridge=xenbr0'' ] > > disk = [ ''file:/xendisks/andre_test.img,sda1,w'', > > ''file:/xendisks/andre_test_swap.img,sda2,w'', > > ''file:/xendisks/install-isoS/install.iso,hdc,r'' ] > > ramdisk = "/boot/initrd.img-2.6.16.33-xen" > > boot = "d" > > > > the boot = d is apparently used to boot the cdrom, but it doesn''t work > > for me. i''ve tried copying the vmlinuz and initrd. > > CDROM''s are only used in fully-virt guests - your config here is a paravirt > guest so there''s no boot option available. Paravirt guests can only boot > off a kernel/initrd (or via a bootloader like pygrub). Fullyvirt guests > have a real BIOS so boot from the MBR of the disk, from CDROM, Floppy > or PXE from the network. >A common way around this is to use qemu to do the install, and then Xen to actually run the domU. You probably want to get the qemu accelerator, or run it on a *really* fast machine. It can be annoyingly slow otherwise (especially if you have to do as I''ve done and run it through VNC across the ''net). Paul -- ---------- # pwd /loony/bin ---------- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Daniel P. Berrange wrote:> On Tue, Jun 05, 2007 at 05:41:58PM +0100, Andre Grove wrote: > >> hello all, >> >> i''ve been messing around with Xen, and it seems that most HOWTOs >> document installs by using prebuilt images. >> i''m rather anal about my installs though, and i want to be able to >> boot CDs (or ISO images). i''ve tried the following config: >> >> kernel = "/boot/vmlinuz-2.6-xen" >> memory = 128 >> name = "andre_test_01" >> cpus = "1" # leave to Xen to pick >> vif = [ ''bridge=xenbr0'' ] >> disk = [ ''file:/xendisks/andre_test.img,sda1,w'', >> ''file:/xendisks/andre_test_swap.img,sda2,w'', >> ''file:/xendisks/install-isoS/install.iso,hdc,r'' ] >> ramdisk = "/boot/initrd.img-2.6.16.33-xen" >> boot = "d" >> >> the boot = d is apparently used to boot the cdrom, but it doesn''t work >> for me. i''ve tried copying the vmlinuz and initrd. >> > > CDROM''s are only used in fully-virt guests - your config here is a paravirt > guest so there''s no boot option available. Paravirt guests can only boot > off a kernel/initrd (or via a bootloader like pygrub). Fullyvirt guests > have a real BIOS so boot from the MBR of the disk, from CDROM, Floppy > or PXE from the network. >Paravirt can do certain types of network boots: look into libvirt and virt-manager and virt-install to see how it''s done. It''s also possible to build an OS image in a mounted partition with rpm "--relocate" and similar tools. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 2007-06-05 at 18:38 +0100, Mark Williamson wrote:> > It''d be kinda nice if there were a standardised spec for "how to boot an ISO > in a paravirt VM". This would require some kind of agreement between the > distributors to do things in a uniform way, but it would move us closer to > a "just works" type setup - surely a good thing. It seems relatively > unfortunate for the install procedure for each paravirt guest to be slightly > different so that the user or tools has to understand those differences. >Its not too difficult to template in many kinds of ways. We''re about to start a project for sqlite => etc/ abstraction. Store the values of etc/ text configs in sqlite , command line args produce distro specific config files. /etc/network/interfaces => /etc/sysconfig/network-scripts/* .. or similar scenarios is what we have in mind. Or, make eth0 xenbr0 with appropriate instructions to brctl by just updating the database. The other thought was to just take a small non blocking http server listening on localhost to gid wheel, and run it as a service. Kind of up in the air still, any feedback would be cool. I''d rather just fork once on dom0. The query would just be a http GET /etc/sysconfig/network-scripts/ifconfig-eth0 , this may be the less confusing route. I like switches, I''m weird. Hooks for HG would also be cool, especially the obvious revert and clone. As for strapping guests "ready to rock with LAMP" , debootstrap does the best job on the most different platforms in my experience. rpmstrap is broken (or was last I checked) because nobody has updated the rpm list since centos 3 / fc *2* I believe? If you really want to be able to configure any os from any os for a paravirt guest, you need some kind of meta package '' Rosetta stone ''. I can''t say that one doesn''t exist, but I''ve yet to find one that includes all popular distros. A link to prove me wrong would of course be welcome! I often wonder what the best way to make one would be. You could get a list of rpms or debs or anything into a db, but you need constant meta package names to relate to them especially when wrapping 3 + packaging methods. Otherwise whats the point of a relational db? Having dist specific frequently updated text lists of package names is ugly. Anything beyond that, i.e. quirks with rpm on this, or aptitude on that can probably be fixed without too much fuss. I''ve seen enough people blogging about one or the other to know that everything works everywhere if given proper love. Best, --Tim> Cheers, > Mark > > On Tuesday 05 June 2007, Andre Grove wrote: > > hello all, > > > > i''ve been messing around with Xen, and it seems that most HOWTOs > > document installs by using prebuilt images. > > i''m rather anal about my installs though, and i want to be able to > > boot CDs (or ISO images). i''ve tried the following config: > > > > kernel = "/boot/vmlinuz-2.6-xen" > > memory = 128 > > name = "andre_test_01" > > cpus = "1" # leave to Xen to pick > > vif = [ ''bridge=xenbr0'' ] > > disk = [ ''file:/xendisks/andre_test.img,sda1,w'', > > ''file:/xendisks/andre_test_swap.img,sda2,w'', > > ''file:/xendisks/install-isoS/install.iso,hdc,r'' ] > > ramdisk = "/boot/initrd.img-2.6.16.33-xen" > > boot = "d" > > > > the boot = d is apparently used to boot the cdrom, but it doesn''t work > > for me. i''ve tried copying the vmlinuz and initrd. > > > > does any one have any ideas? > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tuesday 05 June 2007, Nico Kadel-Garcia wrote:> Daniel P. Berrange wrote: > > On Tue, Jun 05, 2007 at 05:41:58PM +0100, Andre Grove wrote: > >> hello all, > >> > >> i''ve been messing around with Xen, and it seems that most HOWTOs > >> document installs by using prebuilt images. > >> i''m rather anal about my installs though, and i want to be able to > >> boot CDs (or ISO images). i''ve tried the following config: > >> > >> kernel = "/boot/vmlinuz-2.6-xen" > >> memory = 128 > >> name = "andre_test_01" > >> cpus = "1" # leave to Xen to pick > >> vif = [ ''bridge=xenbr0'' ] > >> disk = [ ''file:/xendisks/andre_test.img,sda1,w'', > >> ''file:/xendisks/andre_test_swap.img,sda2,w'', > >> ''file:/xendisks/install-isoS/install.iso,hdc,r'' ] > >> ramdisk = "/boot/initrd.img-2.6.16.33-xen" > >> boot = "d" > >> > >> the boot = d is apparently used to boot the cdrom, but it doesn''t work > >> for me. i''ve tried copying the vmlinuz and initrd. > > > > CDROM''s are only used in fully-virt guests - your config here is a > > paravirt guest so there''s no boot option available. Paravirt guests can > > only boot off a kernel/initrd (or via a bootloader like pygrub). > > Fullyvirt guests have a real BIOS so boot from the MBR of the disk, from > > CDROM, Floppy or PXE from the network. > > Paravirt can do certain types of network boots: look into libvirt and > virt-manager and virt-install to see how it''s done. > > It''s also possible to build an OS image in a mounted partition with rpm > "--relocate" and similar tools.I think yum can do install into a directory. There was a tool called rpmstrap which automated install into a directory for rpm-based guests - I think it may also have handled some guest configuration / xen-related config stuff but I''m not 100% there. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Williamson wrote:> > I think yum can do install into a directory. > > There was a tool called rpmstrap which automated install into a directory for > rpm-based guests - I think it may also have handled some guest > configuration / xen-related config stuff but I''m not 100% there. >Yum can: it takes a bit of work to optimise, otherwise it takes *FOREVER* to download all the packages, and the RPM installations tend to hang on certain "touch" commands. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Jun 05, 2007 at 06:38:34PM +0100, Mark Williamson wrote:> What are you trying to install? As Daniel said, in general installing from > CD-ROMs will only work in HVM. > > However, there are a number of possible options: > > * Fedora / RHEL (and possibly SuSE?) can be installed paravirtualised from > CD-ROM if you boot using the Xenified install kernel and initrd from the > disk.Latest version of virt-install can automatically extract a Xen kernel/initrd from ISO images / CDROM device for Fedora / RHEL / CentOS, and will try and generate a kenrel/initrd for Xen with SLES distros (SLES doesn''t provide pre-built initrds for Xen in install trees). Still normally need to install from some form of network source unless your distro is small enough to fit on a single CD. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Jun 05, 2007 at 06:38:34PM +0100, Mark Williamson wrote:> It''d be kinda nice if there were a standardised spec for "how to boot an ISO > in a paravirt VM". This would require some kind of agreement between the > distributors to do things in a uniform way, but it would move us closer to > a "just works" type setup - surely a good thing. It seems relatively > unfortunate for the install procedure for each paravirt guest to be slightly > different so that the user or tools has to understand those differences.Paravirt-ops may (eventually) help here because removing the need for a small xen kernel. Our goal in Fedora is to continue working to make paravirt boot & install process be more closely aligned to fullyvirt & baremetal. This is why we do Fedora guest installs by booting anaconda (+ optional kickstart) instead of chroot installs, and why we default to using pygrub and keeping kernels inside the guest image, etc. All the tools already expect things to work in this way with bare metal & fullvirt, so having paravirt be different is just complicating things. PXE boot of paravirt is another thing we''d like to have too... Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Tim, I''ll leave discussion of your ideas for other mails, but I just wanted to clarify what I was thinking of:> As for strapping guests "ready to rock with LAMP" , debootstrap does the > best job on the most different platforms in my experience. rpmstrap is > broken (or was last I checked) because nobody has updated the rpm list > since centos 3 / fc *2* I believe? > > If you really want to be able to configure any os from any os for a > paravirt guest, you need some kind of meta package '' Rosetta stone ''. I > can''t say that one doesn''t exist, but I''ve yet to find one that includes > all popular distros.Well, the Rosetta Stone package is exactly the kind of thing I''d like to eliminate here. Obviously for legacy guests that are already out there it might be nice to have something like this. However, it doesn''t seem scalable for the dom0 system to always understand what we''re installing in guests. A nice simple way to get this working would be for everyone to supply a grub.conf that pygrub can grok, then folks can just choose the "install Xen" option from the menu. However, not everybody uses grub, and possibly it doesn''t suit their needs. Lets take the idea of a CD-ROM config file a bit further, then... I guess what I''m proposing is _logically_ a "package format" for encapsulating an OS distribution installer. A kind of "Xen package format". This doesn''t have to literally involve a new kind of package, but the kind of simplicity I''d be looking for is: any distro that has a Xenified kernel can support the XenInstall Spec and will easy to install, in a uniform way on any Xen host. To me the obvious way to accomplish this would be to have some sort of "xen-metainfo.xml" file that compliant install CDs feature at a well-known path such as "xen/xen-metainfo.xml". This file would specify the location of a Xenified kernel, and an initrd that can load the installer proper. This would support the mode of installation current RH guests support - if you can *find* the Xen install kernel and initrd, then anaconda will appear for you and make the install friendly. More generally, such a metadata file could also specify: * boot time options that need to be passed to the kernel <bootargs> <arg>install</arg> <arg>initrd</arg> </bootargs> * user configurable boot time options <user-bootargs> <arg values="framebuffer|vnc|text|auto">installmode</arg> <arg>installserver</arg> </user-bootargs> * different kernel "modes" available (e.g. are kernels available for install on x86_32, x86_32p, x86_64) so that Xen can start the right one in order to kick off the install <kernels> <kernel> <name>Linux 2.6.18 32-bit/PAE domU</name> <path>path/to/image</path> <capable>x86_32p</capable> <capable>SMP</capable> </kernel> </kernels> * how the distro expects devices to be setup (e.g. does this install require a network device, can it do DHCP?) <devices> <required> ... </required> <supported> ... </supported> </devices> A config file like this would facilitate an install process more like: --- # xm guest-install ~/debian-install.iso Looking for Xen/x86_32p kernel... found Select installation mode "[framebuffer/vnc/text/auto]": _ Starting guest operating system... --- This way nobody has to have a detailed understanding of how other distributions structure their install CDs. The key point is that the CDs would be *self describing*. Everyone can still use their own preferred installation methods, so long as they supply enough information to tell Xen how to get started. This same information could be leveraged by the Xen Enterprise tools, virt-manager, Yast, etc. In general, perhaps it would be possible to have a "virt-info.xml" that contains details of lguest support, KVM paravirtual support etc. I wonder if there would be any distributor interest in something like this...? If so, I''d be happy to put together a more detailed proposal we could argue about on xen-devel. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Daniel P. Berrange wrote:> On Tue, Jun 05, 2007 at 06:38:34PM +0100, Mark Williamson wrote: > >> It''d be kinda nice if there were a standardised spec for "how to boot an ISO >> in a paravirt VM". This would require some kind of agreement between the >> distributors to do things in a uniform way, but it would move us closer to >> a "just works" type setup - surely a good thing. It seems relatively >> unfortunate for the install procedure for each paravirt guest to be slightly >> different so that the user or tools has to understand those differences. >> > > Paravirt-ops may (eventually) help here because removing the need for a > small xen kernel. Our goal in Fedora is to continue working to make paravirt > boot & install process be more closely aligned to fullyvirt & baremetal. > This is why we do Fedora guest installs by booting anaconda (+ optional > kickstart) instead of chroot installs, and why we default to using pygrub > and keeping kernels inside the guest image, etc. All the tools already > expect things to work in this way with bare metal & fullvirt, so having > paravirt be different is just complicating things. PXE boot of paravirt > is another thing we''d like to have too... >Is there any chance of integrating support for doing virt-manager installs on top of an *existing* domain, making sure it''s shut down, then allowing the network boot to do upgrade or rescue procedures on it? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Jun 05, 2007 at 10:22:46PM +0100, Nico Kadel-Garcia wrote:> Daniel P. Berrange wrote: > >On Tue, Jun 05, 2007 at 06:38:34PM +0100, Mark Williamson wrote: > > > >>It''d be kinda nice if there were a standardised spec for "how to boot an > >>ISO in a paravirt VM". This would require some kind of agreement between > >>the distributors to do things in a uniform way, but it would move us > >>closer to a "just works" type setup - surely a good thing. It seems > >>relatively unfortunate for the install procedure for each paravirt guest > >>to be slightly different so that the user or tools has to understand > >>those differences. > >> > > > >Paravirt-ops may (eventually) help here because removing the need for a > >small xen kernel. Our goal in Fedora is to continue working to make > >paravirt > >boot & install process be more closely aligned to fullyvirt & baremetal. > >This is why we do Fedora guest installs by booting anaconda (+ optional > >kickstart) instead of chroot installs, and why we default to using pygrub > >and keeping kernels inside the guest image, etc. All the tools already > >expect things to work in this way with bare metal & fullvirt, so having > >paravirt be different is just complicating things. PXE boot of paravirt > >is another thing we''d like to have too... > > > Is there any chance of integrating support for doing virt-manager > installs on top of an *existing* domain, making sure it''s shut down, > then allowing the network boot to do upgrade or rescue procedures on it?I''ve never really thought about that. In theory it could be doable, not sure how hairy an actual implementation would get though. A better approach may be just allowing more flexiblity in reconfiguring existing guest hardware in the UI. eg, allowing you to add a CDROM device to an existing guest & then changing the default BIOS boot device. We''re sort of half way towards being able todo the latter at the moment. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 2007-06-05 at 21:47 +0100, Mark Williamson wrote:> Hi Tim, > > I''ll leave discussion of your ideas for other mails, but I just wanted to > clarify what I was thinking of: > > > As for strapping guests "ready to rock with LAMP" , debootstrap does the > > best job on the most different platforms in my experience. rpmstrap is > > broken (or was last I checked) because nobody has updated the rpm list > > since centos 3 / fc *2* I believe? > > > > If you really want to be able to configure any os from any os for a > > paravirt guest, you need some kind of meta package '' Rosetta stone ''. I > > can''t say that one doesn''t exist, but I''ve yet to find one that includes > > all popular distros. > > Well, the Rosetta Stone package is exactly the kind of thing I''d like to > eliminate here. Obviously for legacy guests that are already out there it > might be nice to have something like this. However, it doesn''t seem scalable > for the dom0 system to always understand what we''re installing in guests.Ah I think we''re talking about the same thing, I say Rosetta more in the historical context and not alluding to the actual work going on trying to make a map of distro packages. I don''t have links to them handy but I found 3 different people trying to do this independently of each other. None of them getting very far. Just something consistent and natural-language like on dom-0 is what I was thinking of, looks like we''re on the same page. I guess we could call them "Xen" meta packages, and they''d still be useful to people using just the stuff native in 2.6. I guess it would work well for anyone using a technology that got a little help from QEMU.> A nice simple way to get this working would be for everyone to supply a > grub.conf that pygrub can grok, then folks can just choose the "install Xen" > option from the menu. However, not everybody uses grub, and possibly it > doesn''t suit their needs. Lets take the idea of a CD-ROM config file a bit > further, then...> I guess what I''m proposing is _logically_ a "package format" for encapsulating > an OS distribution installer. A kind of "Xen package format". This doesn''t > have to literally involve a new kind of package, but the kind of simplicity > I''d be looking for is: any distro that has a Xenified kernel can support the > XenInstall Spec and will easy to install, in a uniform way on any Xen host.Ok, but how to have it install the services you want at the same time? Could packages like ''php5-lighttpd-fastcgi'' make a home in these meta structures too so guests could come ''turn key'' after being installed? I would love to be able to strap a Centos5 guest with everything I wanted out of yum, and have it follow some scripts or macros I wrote to install a few things from source.> To me the obvious way to accomplish this would be to have some sort > of "xen-metainfo.xml" file that compliant install CDs feature at a well-known > path such as "xen/xen-metainfo.xml". This file would specify the location of > a Xenified kernel, and an initrd that can load the installer proper. This > would support the mode of installation current RH guests support - if you can > *find* the Xen install kernel and initrd, then anaconda will appear for you > and make the install friendly. > > More generally, such a metadata file could also specify: > * boot time options that need to be passed to the kernel > <bootargs> > <arg>install</arg> > <arg>initrd</arg> > </bootargs> > > * user configurable boot time options > <user-bootargs> > <arg values="framebuffer|vnc|text|auto">installmode</arg> > <arg>installserver</arg> > </user-bootargs> > > * different kernel "modes" available (e.g. are kernels available for install > on x86_32, x86_32p, x86_64) so that Xen can start the right one in order to > kick off the install > <kernels> > <kernel> > <name>Linux 2.6.18 32-bit/PAE domU</name> > <path>path/to/image</path> > <capable>x86_32p</capable> > <capable>SMP</capable> > </kernel> > </kernels> > > * how the distro expects devices to be setup (e.g. does this install require a > network device, can it do DHCP?) > <devices> > <required> > ... > </required> > <supported> > ... > </supported> > </devices> >Perhaps add ... <post-installed> <yum>perl make gcc mysql-server ... ... </yum> <hg>xenbits.xensource.com/example.hg</hg> <deb> ... ... </deb> <emerge> ... ... </emerge> <sh> ... ... ... </sh> </post-installed> <misc> <root>shadowed:blahblah</root> </misc> I don''t want to turn your XML file into a Makefile ... though there are cases where you''d need bools in the xml file <action type=OR_TRUE,OR_FALSE,OR_EXIT_FAILURE,OR_EXIT_SUCCESS> AND isn''t really needed, its made by lack of OR. We''d need some sanity checking because that''s a lot of stuff going on unattended if ''auto'' is the mode. I''ve been using a simple bash script that reads a pipe delimited file like this : [vif] backing=br0|mac=xxx|vifname=xxx [vbd] type=lvm|backing=/dev/blah|name=sda1|type=ext3|size=10G| mount=/home XML would be much better, bash is really ugly but the syntax is pretty much the same. My utility would then ''grind'' that down and give lvm some instructions, copy the template, write the etc/ files, and then call yum or aptitude to do some stuff.> A config file like this would facilitate an install process more like: > > --- > # xm guest-install ~/debian-install.iso > Looking for Xen/x86_32p kernel... found > Select installation mode "[framebuffer/vnc/text/auto]": _ > Starting guest operating system... > ---> This way nobody has to have a detailed understanding of how other > distributions structure their install CDs. The key point is that the CDs > would be *self describing*. Everyone can still use their own preferred > installation methods, so long as they supply enough information to tell Xen > how to get started.Exactly what I want. I hope to go a little more in depth with it and help them use the distro packaging mechanism so the VM comes out the door ready to meet requests. I tossed this out a few months ago, one of the things people replied with the most is a desire to easily edit guest configs without the fuss of having to login to the guest. This is what was steering me to a sqlite backed non blocking service to run on dom-0 that spit out config values in various formats from xml templates. I was thinking deposit the configs in a future/ directory on the vbd image prior to strapping it, and have the default init.d run a post install that removes itself.> This same information could be leveraged by the Xen Enterprise tools, > virt-manager, Yast, etc. In general, perhaps it would be possible to have > a "virt-info.xml" that contains details of lguest support, KVM paravirtual > support etc. > > I wonder if there would be any distributor interest in something like this...? > If so, I''d be happy to put together a more detailed proposal we could argue > about on xen-devel.Many many many many many. Look at www.3tera.com which is based on xen 2.0.7 (at last I checked). For a free version of AppLogic to exist, this would be the first step and time VERY well spent. Its got so many uses beyond just what we''d use it for if modified ever so slightly, It really makes a packagers job easier. Appliances become easier to make, you could make load balancers, storage servers, firewalls of various types, a vyatta or quagga router, whatever you wanted. There could be a ready made meta template for it you could download like a torrent. You also make UI creation so much easier. Now its a simple question of turning text descriptors into args that only one thing has to deal with. What your making is more or less a packagers swiss army knife. Please do post a blueprint, could I possibly suggest xen-tools since xen-devel is about to really pick up in traffic? The neat part about this project is everyone can work on it, not just kernel and hypervisor hackers. Lots of people make Xen tools just so they can contribute *something*.> Cheers, > Mark > > -- > Dave: Just a question. What use is a unicyle with no seat? And no pedals! > Mark: To answer a question with a question: What use is a skateboard? > Dave: Skateboards have wheels. > Mark: My wheel has a wheel!_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 2007-06-05 at 21:20 +0100, Mark Williamson wrote:> > I think yum can do install into a directory. >Yum experiences bouts of brain-dead-ness.> There was a tool called rpmstrap which automated install into a directory for > rpm-based guests - I think it may also have handled some guest > configuration / xen-related config stuff but I''m not 100% there.It would work, if someone had some time to update the rpm''s in rpmstrap''s lists. They go back quite a way now. There is a patch floating around that updated all the i386 rpm''s up to centos 4, but I can''t seem to find it now. I don''t think it works with meta packages , unfortunately :(. I could be wrong. Best, --Tim> Cheers, > Mark >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> * Fedora / RHEL (and possibly SuSE?) can be installed paravirtualised from > CD-ROM if you boot using the Xenified install kernel and initrd from the > disk.Would you go a little into detail here, please? I have the Fedora7 DVD iso image mounted to /loop Here''s my config file: kernel=''/loop/images/xen/vmlinuz'' ramdisk=''/loop/images/xen/initrd.img'' # this is an ext3 sparsefile, if that matters, I think not disk = [ ''file:/home/xen/f7.img,hda1,w'' ] memory = 512 vcpus = 1 cpus = ''3'' builder = ''linux'' name = ''F7'' vif = [ '''' ] localtime = 0 on_poweroff = ''destroy'' on_reboot = ''restart'' on_crash = ''restart'' extra = '' TERM=xterm root=/dev/hda1 text'' The domU seems to boot up, but stops with these messages: ... PCI: Fatal: No config space access function found PCI: setting up Xen PCI frontend stub Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled xen_mem: Initialising balloon driver. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI ... BUG: at kernel/fork.c:994 copy_process() [<c1005d9e>] show_trace_log_lvl+0x1a/0x2f [<c1006347>] show_trace+0x12/0x14 [<c10063c2>] dump_stack+0x16/0x18 [<c101d040>] copy_process+0x195/0x1245 [<c101e140>] do_fork+0x50/0x117 [<c1003351>] kernel_thread+0x8e/0x96 [<c102c6fd>] __call_usermodehelper+0x2d/0x46 [<c102cd4b>] run_workqueue+0x89/0x145 [<c102d70d>] worker_thread+0xd5/0x102 [<c102ff23>] kthread+0xb3/0xdc [<c10058df>] kernel_thread_helper+0x7/0x10 ======================... XENBUS: Device with no driver: device/vbd/769 XENBUS: Device with no driver: device/vif/0 XENBUS: Device with no driver: device/console/0 Freeing unused kernel memory: 180k freed Write protecting the kernel read-only data: 762k That''s it. After that, nothing happens. Any hints? Regards Dominik _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Daniel P. Berrange wrote:> On Tue, Jun 05, 2007 at 10:22:46PM +0100, Nico Kadel-Garcia wrote: > >> Daniel P. Berrange wrote: >> >>> On Tue, Jun 05, 2007 at 06:38:34PM +0100, Mark Williamson wrote: >>> >>> >>>> It''d be kinda nice if there were a standardised spec for "how to boot an >>>> ISO in a paravirt VM". This would require some kind of agreement between >>>> the distributors to do things in a uniform way, but it would move us >>>> closer to a "just works" type setup - surely a good thing. It seems >>>> relatively unfortunate for the install procedure for each paravirt guest >>>> to be slightly different so that the user or tools has to understand >>>> those differences. >>>> >>>> >>> Paravirt-ops may (eventually) help here because removing the need for a >>> small xen kernel. Our goal in Fedora is to continue working to make >>> paravirt >>> boot & install process be more closely aligned to fullyvirt & baremetal. >>> This is why we do Fedora guest installs by booting anaconda (+ optional >>> kickstart) instead of chroot installs, and why we default to using pygrub >>> and keeping kernels inside the guest image, etc. All the tools already >>> expect things to work in this way with bare metal & fullvirt, so having >>> paravirt be different is just complicating things. PXE boot of paravirt >>> is another thing we''d like to have too... >>> >>> >> Is there any chance of integrating support for doing virt-manager >> installs on top of an *existing* domain, making sure it''s shut down, >> then allowing the network boot to do upgrade or rescue procedures on it? >> > > I''ve never really thought about that. In theory it could be doable, not > sure how hairy an actual implementation would get though. A better approach > may be just allowing more flexiblity in reconfiguring existing guest > hardware in the UI. eg, allowing you to add a CDROM device to an existing > guest & then changing the default BIOS boot device. We''re sort of half > way towards being able todo the latter at the moment. >The para-virt installation procedure, at least on RHEL 5, does not use a local CDROM or DVD. It uses a network repository. Using a CD might be nice for a rescue operation, but the FC or RHEL style installation media support the very useful "rescue" option, which is my friend and would be useful for people like me, who sometimes have to seriously arrange system architectures.. I don''t see a theoretical problem, just disabling the the safety check that stops the procedure if the domain already has a config file: If an /etx/xen/[DOMNAME] file exists, instead of failing, simply provide the option of booting with the settings of the already existing file and set *NO* other options except those necessary for the network boot. I''m not sure if you would need to parse the existing domain file, or simply add options to do this: I don''t understand libvirt well enough to say. Does that make sense? If you point out the right bugzilla or Wiki to me, I''d be happy to put it in as a feature request. The "linux rescue" option is really, really my friend, as is the "pre" option. I use it laying OS tarballs on top of existing hardware and chrooting into them to do updates, feature reconfigurations, etc. And I''ve deployed roughly...... 20,000 servers using that kind of tool, over the last 6 years. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thanks Mark, i tend to use Ubuntu for my dom0, but i want to try and virtualise as many non-windows OSs as possible. ;) i tried the following config: kernel = "/boot/vmlinuz-FC6-install" extra = "selinux=0 reiserfs" memory = 128 name = "andre_test_01" cpus = "1" vif = [ ''bridge=xenbr0'' ] disk = [ ''file:/xendisks/andre_test.img,sda1,w'', ''file:/xendisks/andre_test_swap.img,sda2,w'' ] root = "/dev/sda ro" ramdisk = "/boot/initrd-FC6-install" builder = ''linux'' but the FC installer couldn''t find the "SCSI" disks. i then changed the config to: disk = [ ''file:/xendisks/andre_test.img,hda1,w'', ''file:/xendisks/andre_test_swap.img,hda2,w'' ] root="/dev/hda1" but the installer saw the images as different disks and not partitions, so then i changed to: disk = [ ''file:/xendisks/andre_test.img,hda,w'', ''file:/xendisks/andre_test_swap.img,hdb,w'' ] root="/dev/hda" the installer then made it through to installing the RPMs .... and then it died. am i doing this correctly? On 05/06/07, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:> What are you trying to install? As Daniel said, in general installing from > CD-ROMs will only work in HVM. > > However, there are a number of possible options: > > * Fedora / RHEL (and possibly SuSE?) can be installed paravirtualised from > CD-ROM if you boot using the Xenified install kernel and initrd from the > disk. > * If you have hardware virtualisation extensions, install in HVM mode then > convert to paravirtualised by installing a Xenified kernel. > * Install from CD-ROM in Qemu, then convert to paravirtualised by installing a > Xenified kernel. > * For Debian / Ubuntu installs you can just use debootstrap to build a > filesystem in a directory tree. debootstrap runs on non-debian distros, I > think. > * There are other possibilities (e.g. I think RedHat''s virt-manager can > install RH (/ SuSE guests in future?) from network shares. > > Would one of these work for you? (nb. Fedora / RHEL only support PAE hosts, so > you need to have a PAE Xen installed). > > It''d be kinda nice if there were a standardised spec for "how to boot an ISO > in a paravirt VM". This would require some kind of agreement between the > distributors to do things in a uniform way, but it would move us closer to > a "just works" type setup - surely a good thing. It seems relatively > unfortunate for the install procedure for each paravirt guest to be slightly > different so that the user or tools has to understand those differences. > > Cheers, > Mark > > On Tuesday 05 June 2007, Andre Grove wrote: > > hello all, > > > > i''ve been messing around with Xen, and it seems that most HOWTOs > > document installs by using prebuilt images. > > i''m rather anal about my installs though, and i want to be able to > > boot CDs (or ISO images). i''ve tried the following config: > > > > kernel = "/boot/vmlinuz-2.6-xen" > > memory = 128 > > name = "andre_test_01" > > cpus = "1" # leave to Xen to pick > > vif = [ ''bridge=xenbr0'' ] > > disk = [ ''file:/xendisks/andre_test.img,sda1,w'', > > ''file:/xendisks/andre_test_swap.img,sda2,w'', > > ''file:/xendisks/install-isoS/install.iso,hdc,r'' ] > > ramdisk = "/boot/initrd.img-2.6.16.33-xen" > > boot = "d" > > > > the boot = d is apparently used to boot the cdrom, but it doesn''t work > > for me. i''ve tried copying the vmlinuz and initrd. > > > > does any one have any ideas? > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > > > -- > Dave: Just a question. What use is a unicyle with no seat? And no pedals! > Mark: To answer a question with a question: What use is a skateboard? > Dave: Skateboards have wheels. > Mark: My wheel has a wheel! >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > Well, the Rosetta Stone package is exactly the kind of thing I''d like to > > eliminate here. Obviously for legacy guests that are already out there > > it might be nice to have something like this. However, it doesn''t seem > > scalable for the dom0 system to always understand what we''re installing > > in guests. > > Ah I think we''re talking about the same thing, I say Rosetta more in the > historical context and not alluding to the actual work going on trying > to make a map of distro packages. I don''t have links to them handy but I > found 3 different people trying to do this independently of each other. > None of them getting very far.Hmmm, OK. I guess I was thinking of the "Rosetta stone" approach as being some kind of central store of knowledge regarding how all the different distros express things. AFAIK this is how, for instance, virt-install handles things: it contains knowledge about how to kick off installations of FC, RHEL, and other distros. A number of distros now have installers (e.g. RHEL, Fedora, SLES) which can trivially run *within* a Xen domain so long as you know *how* to start them. It seems relatively unfortunate for each and every Xen management tool to need to understand these layouts. For instance, XenEnteprise might contain one implementation of "how to install" for each of these distros. virt-manager another... Other people might install them by just memorising the necessary paths and putting this stuff into a Xen config file. What IMO we *ought* to have is a simple way of describing how _to start_ an install of a paravirtualised Xen-aware guest. To begin with, that''d be all we want and I think it would be a big win in itself. Generalising slightly, I guess I''m not really proposing initially a way to simplify installs. I''m proposing a vendor-neutral way to make an ISO the "bootable" for a paravirtualised system. For "legacy" OSes, we''d need a database of meta-info files describing how to kick off a paravirt install of NetBSD, RHEL, Fedora, SLES, etc. Distributors could include a meta-info file on their future ISO releases so that they''d be self-describing and not require users to update their meta-info database.> > A nice simple way to get this working would be for everyone to supply a > > grub.conf that pygrub can grok, then folks can just choose the "install > > Xen" option from the menu. However, not everybody uses grub, and > > possibly it doesn''t suit their needs. Lets take the idea of a CD-ROM > > config file a bit further, then... > > > > I guess what I''m proposing is _logically_ a "package format" for > > encapsulating an OS distribution installer. A kind of "Xen package > > format". This doesn''t have to literally involve a new kind of package, > > but the kind of simplicity I''d be looking for is: any distro that has a > > Xenified kernel can support the XenInstall Spec and will easy to install, > > in a uniform way on any Xen host. > > Ok, but how to have it install the services you want at the same time? > Could packages like ''php5-lighttpd-fastcgi'' make a home in these meta > structures too so guests could come ''turn key'' after being installed? > > I would love to be able to strap a Centos5 guest with everything I > wanted out of yum, and have it follow some scripts or macros I wrote to > install a few things from source.Can''t you do that sort of thing using RedHat''s kickstart? I actually think this kind of thing is kinda orthogonal to my proposal, because it''s not really specific to Xen guests... You''d really want to be able to specify this for any install, whether native or virtualised, mmm?> Perhaps add ... > > <post-installed> > <yum>perl make gcc mysql-server ... ... </yum> > <hg>xenbits.xensource.com/example.hg</hg> > <deb> ... ... </deb> > <emerge> ... ... </emerge> > <sh> ... ... ... </sh> > </post-installed> > > <misc> > <root>shadowed:blahblah</root> > </misc> > > I don''t want to turn your XML file into a Makefile ... though there are > cases where you''d need bools in the xml file > > <action type=OR_TRUE,OR_FALSE,OR_EXIT_FAILURE,OR_EXIT_SUCCESS> > > AND isn''t really needed, its made by lack of OR. We''d need some sanity > checking because that''s a lot of stuff going on unattended if ''auto'' is > the mode. > > I''ve been using a simple bash script that reads a pipe delimited file > like this : > > [vif] backing=br0|mac=xxx|vifname=xxx > [vbd] type=lvm|backing=/dev/blah|name=sda1|type=ext3|size=10G| > mount=/home > > XML would be much better, bash is really ugly but the syntax is pretty > much the same. > > My utility would then ''grind'' that down and give lvm some instructions, > copy the template, write the etc/ files, and then call yum or aptitude > to do some stuff. > > > A config file like this would facilitate an install process more like: > > > > --- > > # xm guest-install ~/debian-install.iso > > Looking for Xen/x86_32p kernel... found > > Select installation mode "[framebuffer/vnc/text/auto]": _ > > Starting guest operating system... > > --- > > > > This way nobody has to have a detailed understanding of how other > > distributions structure their install CDs. The key point is that the CDs > > would be *self describing*. Everyone can still use their own preferred > > installation methods, so long as they supply enough information to tell > > Xen how to get started. > > Exactly what I want. I hope to go a little more in depth with it and > help them use the distro packaging mechanism so the VM comes out the > door ready to meet requests. > > I tossed this out a few months ago, one of the things people replied > with the most is a desire to easily edit guest configs without the fuss > of having to login to the guest.Mmmmmm. Agreed on basically all counts. Also I think that this is still the kind of thing you''d want to be able to leverage natively too so I think it comes outside the scope of what I''m looking at...> Please do post a blueprint, could I possibly suggest xen-tools since > xen-devel is about to really pick up in traffic? > > The neat part about this project is everyone can work on it, not just > kernel and hypervisor hackers. Lots of people make Xen tools just so > they can contribute *something*.I''m hoping I''ll be able to take a look at the base problem of making install CDs "just work" for Xen guests. This could potentially involve some enhancements to pygrub, but I think there may be better ways of getting the Just-Workness in there. Perhaps a wider discussion needs to be had with vendors about automating deployment in VMs: the same things that you need with mass deployments on physical machines become even more important when you''ve gone virtual. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> i tend to use Ubuntu for my dom0, but i want to try and virtualise as > many non-windows OSs as possible. ;) > i tried the following config:<snip>> the installer then made it through to installing the RPMs .... and then it > died. am i doing this correctly?For the duration of the install process I think you ought to be giving it access to the installer ISO too as one of its VBDs. cheers, Mark> On 05/06/07, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote: > > What are you trying to install? As Daniel said, in general installing > > from CD-ROMs will only work in HVM. > > > > However, there are a number of possible options: > > > > * Fedora / RHEL (and possibly SuSE?) can be installed paravirtualised > > from CD-ROM if you boot using the Xenified install kernel and initrd from > > the disk. > > * If you have hardware virtualisation extensions, install in HVM mode > > then convert to paravirtualised by installing a Xenified kernel. > > * Install from CD-ROM in Qemu, then convert to paravirtualised by > > installing a Xenified kernel. > > * For Debian / Ubuntu installs you can just use debootstrap to build a > > filesystem in a directory tree. debootstrap runs on non-debian distros, > > I think. > > * There are other possibilities (e.g. I think RedHat''s virt-manager can > > install RH (/ SuSE guests in future?) from network shares. > > > > Would one of these work for you? (nb. Fedora / RHEL only support PAE > > hosts, so you need to have a PAE Xen installed). > > > > It''d be kinda nice if there were a standardised spec for "how to boot an > > ISO in a paravirt VM". This would require some kind of agreement between > > the distributors to do things in a uniform way, but it would move us > > closer to a "just works" type setup - surely a good thing. It seems > > relatively unfortunate for the install procedure for each paravirt guest > > to be slightly different so that the user or tools has to understand > > those differences. > > > > Cheers, > > Mark > > > > On Tuesday 05 June 2007, Andre Grove wrote: > > > hello all, > > > > > > i''ve been messing around with Xen, and it seems that most HOWTOs > > > document installs by using prebuilt images. > > > i''m rather anal about my installs though, and i want to be able to > > > boot CDs (or ISO images). i''ve tried the following config: > > > > > > kernel = "/boot/vmlinuz-2.6-xen" > > > memory = 128 > > > name = "andre_test_01" > > > cpus = "1" # leave to Xen to pick > > > vif = [ ''bridge=xenbr0'' ] > > > disk = [ ''file:/xendisks/andre_test.img,sda1,w'', > > > ''file:/xendisks/andre_test_swap.img,sda2,w'', > > > ''file:/xendisks/install-isoS/install.iso,hdc,r'' ] > > > ramdisk = "/boot/initrd.img-2.6.16.33-xen" > > > boot = "d" > > > > > > the boot = d is apparently used to boot the cdrom, but it doesn''t work > > > for me. i''ve tried copying the vmlinuz and initrd. > > > > > > does any one have any ideas? > > > > > > _______________________________________________ > > > Xen-users mailing list > > > Xen-users@lists.xensource.com > > > http://lists.xensource.com/xen-users > > > > -- > > Dave: Just a question. What use is a unicyle with no seat? And no > > pedals! Mark: To answer a question with a question: What use is a > > skateboard? Dave: Skateboards have wheels. > > Mark: My wheel has a wheel!-- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, 2007-06-06 at 19:42 +0100, Mark Williamson wrote:> What IMO we *ought* to have is a simple way of describing how _to start_ an > install of a paravirtualised Xen-aware guest. To begin with, that''d be all > we want and I think it would be a big win in itself.> Generalising slightly, I guess I''m not really proposing initially a way to > simplify installs. I''m proposing a vendor-neutral way to make an ISO > the "bootable" for a paravirtualised system.I understand the scope of what your talking about now. It would then be up to whatever reads it to provide an automated mechanism. I''m dense and your excited. It took a few times.> Can''t you do that sort of thing using RedHat''s kickstart?To a degree. What the majority of people want is something to pave and manage guests easily, way beyond the initial setup. Like you said, its way out of the scope of what your describing. But this is of particular interest to anyone writing stuff that will be the next step in the process.> Mmmmmm. Agreed on basically all counts. Also I think that this is still the > kind of thing you''d want to be able to leverage natively too so I think it > comes outside the scope of what I''m looking at...Hate to bring this up but are you going to address pciback? Some people export printers, nics or other things too.> Perhaps a wider discussion needs to be had with vendors about automating > deployment in VMs: the same things that you need with mass deployments on > physical machines become even more important when you''ve gone virtual.It is aggravating to everyone. I hope some standard can be reached. You''ll find lots of support for that here for sure. It would really be neat to be able to strap anything from anything. That takes so much work off the shoulders of anyone writing something around or with Xen. The end result would just be more people using more distros that they probably would not otherwise. Its good all around. I hope you have luck getting an agreeable standard, even just that is a big step in the right direction. Best, --Tim _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users