From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 0/3] domUloader Date: Tue, 17 Jan 2006 05:52:14 -0600 Message-ID: <43CCDA6E.5040608@us.ibm.com> References: <20060116234330.GC17087@tpkurt.wlan.garloff.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060116234330.GC17087@tpkurt.wlan.garloff.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Kurt Garloff Cc: Xen development list List-Id: xen-devel@lists.xenproject.org Hi Kurt, Kurt Garloff wrote: >domUloader parses the bootentry (passed via --entry=) and the disk >setup (passed via --disks=). It then sets up loop devices as needed, >scans for partition tables (the exported disks / loop devs can >contain partitions) using kpartx (dm) and sets them up, so the kernel >and initrd can be copied to a temporary location in dom0. > > Just to clarify, this means that domU filesystems are being mounted in dom0? I knew there was some security concerns voiced about this many months ago. I think one of the advantages to using libext2 was that it theoritically allowed the filesystem parsing to be done as a non-privileged user. Regards, Anthony Liguori >The bootentry may contain a dev: prefix describing the partition >(from a domU perspective!) where kernel and initrd are located, >followed by kernel filename and (optional) initrd filenames relative >to the filesystem on dev:. >The kernel and initrd filename can also be relative to the domU root >filesystem. The domUloader than evaluates /etc/fstab found in the >root filesystem (passed via --root=) to locate kernel and initrd. >Afterwards everything is cleaned up. (We use the destructors, so >python reference counting makes sure this also happens when >exceptions occur.) > >Unlike pygrub, it does use any code to understand filesystems or >partitions; the filesystem support comes from the dom0 kernel, >whereas kpartx (from multipath-tools) is used for the knowledge >of partitions and for setting up device-mapper. > >More details by calling domUloader.py --help. > >An example config could look like this: >bootentry = hda2:/vmlinuz-xen,/initrd-xen >bootloader = /path/to/domUloader.py >disks = ['phy:VG_Xen/LV_dom5,hda,w', 'file:/var/lib/xen/test,sda,w'] >... >assuming LV_dom5 has a second partition with a filesystem containing >vmlinuz-xen and initrd-xen in its root fs (the /boot partition). > >or >bootentry = /boot/vmlinuz-xen,/boot/initrd-xen >bootloader = /path/to/domUloader.py >root = /dev/hda1 >disk = ... >assuming that the root filesystem has an /etc/fstab that points the >way to /boot/vmlinuz-xen. (Does not need to be a separate FS.) > >The following three mails will contain >(1) A patch to xend/XenDomainInfo.py, xend/XenBootloader.py and > xm/create.py, making sure that all the needed info is passed > to the bootloader and also stored for reuse on rebooting. >(2) A patch to make pygrub accept the new parameters passed by > XendBootloader.py (but so far pygrub just ignores them ...) >(3) The domUloader.py script. > > >Patches are against a working copy (8259) on my laptop; if noone >else will, I can create diffs against mercurial tip. > >I hope this is useful to someone and can be integrated into the >Xen distribution. > >Enjoy, > > >------------------------------------------------------------------------ > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > >