[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Preferred Disk Image Format / Kernel Location
Trevor Orsztynowicz <trevoro@xxxxxxxxxxxxx> writes: > I'm working on a project right now focused on Xen and I'm curious what > everyones experiences / preferences are regarding the following two > aspects > > Preferred Disk Partition Format > and > Location of the Kernel (ie Pygrub / Kernel outside an Image) I have a strong preference for keeping the kernel in the image. I understand the security concerns, but I consider it worth it to get the ease of management and flexibility. Of course, now that 3.3 out, I'm going to move all my stuff over to pvgrub. Either way, allowing the DomU administrator to change the kernel allows you to separate the 'virtual server administrator' and 'hardware/Dom0 administrator' roles much better than keeping the kernel in the Dom0. > For the disk format I've tried all sorts of approach and I can't find > any specific benefits one way or the other, however I have been > leaning more towards representing disk images as partition /dev/sda1. > The other options of course are that I present the target as an entire > drive, or as 'xvda' Largely preference. Personally, I like to give each DomU 2 LVM partitions from the dom0 point of view, the partition is named after the DomUs name, and the second partition is domuname_boot. this lets me put the PyGrub stuff on it's own partition (meaning that a user can more freely screw up her main partition and then reboot into PyGrub, and choose the rescue image to fix the problem without pestering me) From within the DomU, the user sees xvda and xvdb (or sda and sdb, depending) so the user can partition xvdb however they like. Long term, I'd like to integrate some kind of PyPXEboot type thing into pvgrub, so that a user can boot her own kernels off disk, or alternately hit a key and download pxe kernels (to get a rescue/install image or the like, assuming they blew away the disk) but I've not spent the time to set that working. but I know people who prefer to partition sda in the Dom0 as /dev/sda5 for vm 1, /dev/sda6 for vm 2, etc. Personally, I think that is difficult to manage, but again, it's largely preference. The real performance differences are between file: vs. phy: vs nfs or iscsi (or AoE or gnbd or other 'load the filesystem from within the DomU over the network') devices. phy: as a general rule, works well and is faster than most anything else, but doesn't do live migration. Network file systems are all pretty slow until you get into the 'silly expensive' range. as for file: devices, they are easy, fine for testing. some people find files easier to deal with organizationally. tap:// devices are a good answer for those people, but tap: lacks many of the advantages of files. tap: is picky about the filesystem and type of file... you aren't going to be able to tap: a file over NFS, and tap: is weird with sparse files (see qcow, but I think sparse files are generally a bad idea.) > The kernel location question seems more interesting to me. I've had a > lot of success using pygrub within the different environments I've > managed, and I personally prefer this method, but I'm interested in > hearing arguments as to why this should or shouldn't be done. pvgrub overcomes most of the reasons why you wouldn't want to use PyGRUB. the only time when I think it might be easier to keep the kernels in the Dom0 is if you were using a kernel with no modules, and all your DomUs always used the same kernel. In that case, it could be easier to keep it in the Dom0. But in most situations where I've used Xen, keeping the kernel in the DomU is much easier. _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |