Hi, I''m trying to setup Xen guests on LVM logical volumes. What I want to achieve is: - better performance as with file based VBDs - easy resizing options for guest filesystems So my plan was to use LVs directly as partitions in the guest /dev/vg/lv1 -> /dev/hda1 /dev/vg/lv2 -> /dev/hda2 (or /dev/hdb1 FWIW) According to documentation I found, that should be possible but I wasn''t able to get it to work. Probably my issue is that I want to install the guest OS from scratch which includes creating filesystems and (if needed) partitions. So the installer displays /dev/hda1 as disk instead of just a partition and doesn''t allow to create a filesystem on it. Is there a way to show the DomU a (faked) disk /dev/hda with partition table so that /dev/hda1 and /dev/hda2 would be available to create filesystems on them? Or any other possibility to achieve that? While using one LV for the whole DomU disk would be possible it makes resizing much harder since DomU doesn''t know about LVM so I can resize the "disk" but it''s not really possible to resize the partitions within DomU. Any hints? Thanks, Wolfgang _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Wolfgang Rosenauer <wolfgang.rosenauer@an-netz.de> wrote:> > So my plan was to use LVs directly as partitions in the guest > /dev/vg/lv1 -> /dev/hda1 > /dev/vg/lv2 -> /dev/hda2 (or /dev/hdb1 FWIW)AFAIK this way is not to be supported in the future. I''ve managed to make it work (for each disk but /root (or /boot)) but then I''ve realised there are no advantages of such setup. So IMHO a better way to do it is to export each lv as a separate disk and make one single partition of whole such disk in domU: /dev/vg/lv1 -> /dev/hda -> /dev/hda1 --> / /dev/vg/lv2 -> /dev/hdb -> /dev/hdb1 --> /var /dev/vg/lv3 -> /dev/hdc -> /dev/hdc1 --> /home Resizing is extremly easy (lvextend, resize2fs) and it can be done online if ext3 is used. The only disadvantage is you can''t mount such filesystem directly, you need to run ''kpartx -a'' first to map nested domuU block devies in dom0. But that''s also pretty easy. -- Tomek _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tomasz Nowak wrote:> Wolfgang Rosenauer <wolfgang.rosenauer@an-netz.de> wrote: >> >> So my plan was to use LVs directly as partitions in the guest >> /dev/vg/lv1 -> /dev/hda1 >> /dev/vg/lv2 -> /dev/hda2 (or /dev/hdb1 FWIW) > > AFAIK this way is not to be supported in the future. > I''ve managed to make it work (for each disk but /root (or /boot)) > but then I''ve realised there are no advantages of such setup.Really? I kind of like the one lv per partition. -- Nick Anderson <nick@anders0n.net> http://www.cmdln.org http://www.anders0n.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, Age_M wrote:> Hi Wolfgang, > > here my domU config file. I am using LVM for DomU without problems: > > name="tfx" > bootloader = "/usr/bin/pygrub" > memory=512 > vcpu=1 > disk=[ ''phy:/dev/mapper/vgrp0-tfx,sda1,w'', > ''phy:/dev/mapper/vgrp0-tfx.swp,sda2,w'' ] > vif=[ ''bridge=eth0,mac=00:16:3e:00:01:41'' ] > extra="console=xvc0"I wonder what fdisk -l shows in your guest? Because the issue I have with that config is that the installer expects real disks with real partition tables it seems. Thanks, Wolfgang _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nick Anderson <nick@anders0n.net> wrote:> > Really? I kind of like the one lv per partition.Don''t you get one lv per partition in the following setup? -- Tomek _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tomasz Nowak wrote:> Wolfgang Rosenauer <wolfgang.rosenauer@an-netz.de> wrote: >> >> So my plan was to use LVs directly as partitions in the guest >> /dev/vg/lv1 -> /dev/hda1 >> /dev/vg/lv2 -> /dev/hda2 (or /dev/hdb1 FWIW) > > AFAIK this way is not to be supported in the future. > I''ve managed to make it work (for each disk but /root (or /boot)) > but then I''ve realised there are no advantages of such setup. > > So IMHO a better way to do it is to export each lv as > a separate disk and make one single partition of whole > such disk in domU: > /dev/vg/lv1 -> /dev/hda -> /dev/hda1 --> / > /dev/vg/lv2 -> /dev/hdb -> /dev/hdb1 --> /var > /dev/vg/lv3 -> /dev/hdc -> /dev/hdc1 --> /home > > Resizing is extremly easy (lvextend, resize2fs) > and it can be done online if ext3 is used.hmm, ok, sounds good. Do I understand correctly that resizing involves the following tasks then: - lvextend from Dom0 - modify partition table in DomU to use the new whole disk (raising the last block number?) - resize2fs in DomU Thanks, Wolfgang _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tomasz Nowak wrote:> Nick Anderson <nick@anders0n.net> wrote: >> >> Really? I kind of like the one lv per partition. > > Don''t you get one lv per partition in the following setup? >You do but you have the partition table on the block device to deal with. I like the simplicity of using the full block device as a partition inside of xen -- Nick Anderson <nick@anders0n.net> http://www.cmdln.org http://www.anders0n.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tomasz Nowak wrote:> > Wolfgang Rosenauer <wolfgang.rosenauer@an-netz.de> wrote: > > > > So my plan was to use LVs directly as partitions in the guest > > /dev/vg/lv1 -> /dev/hda1 > > /dev/vg/lv2 -> /dev/hda2 (or /dev/hdb1 FWIW) > > AFAIK this way is not to be supported in the future. > I''ve managed to make it work (for each disk but /root (or /boot)) > but then I''ve realised there are no advantages of such setup. > > So IMHO a better way to do it is to export each lv as > a separate disk and make one single partition of whole > such disk in domU: > /dev/vg/lv1 -> /dev/hda -> /dev/hda1 --> / > /dev/vg/lv2 -> /dev/hdb -> /dev/hdb1 --> /var > /dev/vg/lv3 -> /dev/hdc -> /dev/hdc1 --> /home > > Resizing is extremly easy (lvextend, resize2fs) > and it can be done online if ext3 is used. > > The only disadvantage is you can''t mount such filesystem > directly, you need to run ''kpartx -a'' first to map nested > domuU block devies in dom0. But that''s also pretty easy.What would be the practical reason for that as opposed to allocating a bigger LV to contain all partitions? It seems they are all running across the same spindles, so there is no real performance improvement. Your splitting the lanes, but they still merge back before they hit the disk... Typically I use one LV for the guest, I put /home on a NFS share and for high performance apps setup an iSCSI volume. That for me makes the best use of space while providing the best performance. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ross S. W. Walker wrote:>> So IMHO a better way to do it is to export each lv as >> a separate disk and make one single partition of whole >> such disk in domU: >> /dev/vg/lv1 -> /dev/hda -> /dev/hda1 --> / >> /dev/vg/lv2 -> /dev/hdb -> /dev/hdb1 --> /var >> /dev/vg/lv3 -> /dev/hdc -> /dev/hdc1 --> /home >> >> Resizing is extremly easy (lvextend, resize2fs) >> and it can be done online if ext3 is used. >> >> The only disadvantage is you can''t mount such filesystem >> directly, you need to run ''kpartx -a'' first to map nested >> domuU block devies in dom0. But that''s also pretty easy. > > What would be the practical reason for that as opposed to > allocating a bigger LV to contain all partitions?For me the advantage would be that I''m able to resize the different partitions. If I use the LV as complete disk I only could extend the last partition in DomU. Wolfgang _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ross S. W. Walker <rwalker@medallion.com> wrote:> > What would be the practical reason for that as opposed to > allocating a bigger LV to contain all partitions?If you had 3 partitions on one virtual disk, it''s easy to resize only the last one. -- Tomek _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ross S. W. Walker wrote:> What would be the practical reason for that as opposed to > allocating a bigger LV to contain all partitions?One reason I can think of is for snapshots of the data you want to snapshot. If I dont care whats in /var why waste time in backing it up. I might want to snapshot home more often than /. If its all on one big LV you cant get that fine grained snapshotting can you? -- Nick Anderson <nick@anders0n.net> http://www.cmdln.org http://www.anders0n.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Thu, May 8, 2008 at 8:59 AM, Nick Anderson <nick@anders0n.net> wrote:> One reason I can think of is for snapshots of the data you want to > snapshot. If I dont care whats in /var why waste time in backing it up. I > might want to snapshot home more often than /. If its all on one big LV you > cant get that fine grained snapshotting can you?even worse than /var would be snapshotting the swap partition! -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tomasz Nowak wrote:> Ross S. W. Walker <rwalker@medallion.com> wrote: >> >> What would be the practical reason for that as opposed to >> allocating a bigger LV to contain all partitions? > > If you had 3 partitions on one virtual disk, it''s > easy to resize only the last one.What about the first 2 partitions? If I upgrade the memory in the physical machine and then allocate more memory to a domU I might want to increase the swap space, its really easy to just extend the lv when its one partition per lv -- Nick Anderson <nick@anders0n.net> http://www.cmdln.org http://www.anders0n.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Javier Guerra wrote:> On Thu, May 8, 2008 at 8:59 AM, Nick Anderson <nick@anders0n.net> wrote: >> One reason I can think of is for snapshots of the data you want to >> snapshot. If I dont care whats in /var why waste time in backing it up. I >> might want to snapshot home more often than /. If its all on one big LV you >> cant get that fine grained snapshotting can you? > > even worse than /var would be snapshotting the swap partition! >Just to be obtuse ... Unless your trying to make a "warm" backup where you take the memory state and entire disk contents. Then it would be convenient to have it all in one disk and preferable to snapshot the swap. At any rate I sure hope support for using an entire lv as a partition does not go away. I have not heard a good reason for it to yet. -- Nick Anderson <nick@anders0n.net> http://www.cmdln.org http://www.anders0n.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Thu, May 8, 2008 at 8:12 AM, Tomasz Nowak <tnowak-p@netventure.pl> wrote:> Wolfgang Rosenauer <wolfgang.rosenauer@an-netz.de> wrote: > > > > > So my plan was to use LVs directly as partitions in the guest > > /dev/vg/lv1 -> /dev/hda1 > > /dev/vg/lv2 -> /dev/hda2 (or /dev/hdb1 FWIW) > > > > AFAIK this way is not to be supported in the future.it would be a real shame. i think most installers can respect an existing partition scheme. if not, they should soon, since most integrators are realizing that installing an OS doesn''t mean owning the whole hardware -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Javier Guerra wrote:> On Thu, May 8, 2008 at 8:12 AM, Tomasz Nowak <tnowak-p@netventure.pl> wrote: >> Wolfgang Rosenauer <wolfgang.rosenauer@an-netz.de> wrote: >> >>> So my plan was to use LVs directly as partitions in the guest >>> /dev/vg/lv1 -> /dev/hda1 >>> /dev/vg/lv2 -> /dev/hda2 (or /dev/hdb1 FWIW) >>> >> AFAIK this way is not to be supported in the future. > > it would be a real shame. > > i think most installers can respect an existing partition scheme. if > not, they should soon, since most integrators are realizing that > installing an OS doesn''t mean owning the whole hardwareThe thing is that it actually is no paritioning scheme and that''s why most installers are not working that way. Installers are using partition tables to find partitions but there are none available. So fdisk -l shows just "/dev/hda1 contains no valid partition table". I''m speaking at least for paravirtualized guests here. Wolfgang _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tomasz Nowak wrote on Thu, 8 May 2008 15:12:03 +0200:> AFAIK this way is not to be supported in the future.What exactly do you mean by that? *Installing* "raw" on it doesn''t seem to be supported *now*. Do you want to say that it''s going to stay that way? On the other hand you *can* copy the installed system from a xvda to a "raw" LV and then boot from that. Do you want to say usage of raw LV will not be supported in the future? Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Wolfgang Rosenauer wrote on Thu, 08 May 2008 15:18:12 +0200:> Because the issue I have > with that config is that the installer expects real disks with real > partition tables it seems.It may depend on the OS you want to install, allegedly there are installers that can install to a partition instead of a whole disk. I tried that with CentOS and it didn''t work. The installer *can* install to that partition (LV or partition, that''s just the same for this purpose), but it wants to see it as one disk or Xen presents it as one disk (not sure which one is true). So, it mounts it as xvda or as /dev/hda1 and creates a "complete" virtual disk on it. If you do not partition this in any way, you can then copy all the contents to a "raw" LV and you can boot from that. With "raw" I mean it''s not a virtual disk and you can mount it from Dom0 like a normal lv/partition and work on it (while the DomU is shut down, of course). You can also attach directly any raw LV devices to the DomU and mount them for instance as /var or /home or swap. But you cannot install on an LV without getting that "virtual disk", although you can boot from one. I don''t know why this is not supported. There was a thread about this "Partition vs disk images", that started end of April, you''ll get more details from it. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nick Anderson wrote:> > Ross S. W. Walker wrote: > > > What would be the practical reason for that as opposed to > > allocating a bigger LV to contain all partitions? > > One reason I can think of is for snapshots of the data you want to > snapshot. If I dont care whats in /var why waste time in backing it up. > I might want to snapshot home more often than /. If its all on one big > LV you cant get that fine grained snapshotting can you?Just to poke a little further, why take snapshots in dom0 instead of within domU? You could provide a second LV to each domU located on different spindles that provide snapshotting within the domUs. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Wolfgang Rosenauer wrote:> > Ross S. W. Walker wrote: > >> So IMHO a better way to do it is to export each lv as > >> a separate disk and make one single partition of whole > >> such disk in domU: > >> /dev/vg/lv1 -> /dev/hda -> /dev/hda1 --> / > >> /dev/vg/lv2 -> /dev/hdb -> /dev/hdb1 --> /var > >> /dev/vg/lv3 -> /dev/hdc -> /dev/hdc1 --> /home > >> > >> Resizing is extremly easy (lvextend, resize2fs) > >> and it can be done online if ext3 is used. > >> > >> The only disadvantage is you can''t mount such filesystem > >> directly, you need to run ''kpartx -a'' first to map nested > >> domuU block devies in dom0. But that''s also pretty easy. > > > > What would be the practical reason for that as opposed to > > allocating a bigger LV to contain all partitions? > > For me the advantage would be that I''m able to resize the different > partitions. If I use the LV as complete disk I only could extend the > last partition in DomU.You can resize within the domU if you don''t overallocate up front. Typically I will create a 16GB LV for a 8GB / and 2GB swap, or a 32GB LV for a 16GB / and 4GB swap and always leave around 30% available for future expansion or additional needs. But you could always bring in another LV to the domU and add it to the VG within the domU and resize from that. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nick Anderson wrote:> Tomasz Nowak wrote: > > Ross S. W. Walker <rwalker@medallion.com> wrote: > >> > >> What would be the practical reason for that as opposed to > >> allocating a bigger LV to contain all partitions? > > > > If you had 3 partitions on one virtual disk, it''s > > easy to resize only the last one. > > What about the first 2 partitions? If I upgrade the memory in the > physical machine and then allocate more memory to a domU I might want to > increase the swap space, its really easy to just extend the lv when its > one partition per lvIf you used LVM within the domU and always kept space in reserve this wouldn''t be an issue. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ross S. W. Walker wrote:> Just to poke a little further, why take snapshots in dom0 instead > of within domU? > > You could provide a second LV to each domU located on different spindles > that provide snapshotting within the domUs.How will I get a complete point in time snapshot if I am doing LV from inside each domU? Would it not be introducing unnecessary overhead to do LV -> domU(disk) -> 1 partition/disk -> LV And do so for each partition you want? -- Nick Anderson <nick@anders0n.net> http://www.cmdln.org http://www.anders0n.net _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nick Anderson wrote:> Ross S. W. Walker wrote: > > Just to poke a little further, why take snapshots in dom0 instead > > of within domU? > > > > You could provide a second LV to each domU located on different spindles > > that provide snapshotting within the domUs. > > How will I get a complete point in time snapshot if I am > doing LV from inside each domU?Snapshots of the LVs within a domU will be point in time in respect of the domU. Basically they work just as if the domU was a standalone.> Would it not be introducing unnecessary overhead to do > LV -> domU(disk) -> 1 partition/disk -> LV > And do so for each partition you want?Device mapper, LVM is actually device mapper now, is an extremely low overhead process that uses the same techniques as virtual memory mapping to map physical storage. In fact the page cache integrates tightly with device mapper to provide robust disk to memory mapping and access. There is absolutely no reason these days to not base all, except removable and backwards compatible, storage on LVM. Back in the LVMv1 days I would see your argument, but these days the same device mapper that handles your software based RAID storage handles the logical volume management and there is negligiable performance loss. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ross S. W. Walker wrote:>>> What would be the practical reason for that as opposed to >>> allocating a bigger LV to contain all partitions? >> For me the advantage would be that I''m able to resize the different >> partitions. If I use the LV as complete disk I only could extend the >> last partition in DomU. > > You can resize within the domU if you don''t overallocate up front. > > Typically I will create a 16GB LV for a 8GB / and 2GB swap, or a > 32GB LV for a 16GB / and 4GB swap and always leave around 30% > available for future expansion or additional needs. But you > could always bring in another LV to the domU and add it to the > VG within the domU and resize from that.That''s true but in the end that needs LVM in Dom0 _and_ LVM in DomU. Somehow I think that gets complicated especially if the LVs of the guest should be accessible from Dom0. Wolfgang _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Wolfgang Rosenauer wrote:> Ross S. W. Walker wrote: > >>> What would be the practical reason for that as opposed to > >>> allocating a bigger LV to contain all partitions? > >> For me the advantage would be that I''m able to resize the different > >> partitions. If I use the LV as complete disk I only could extend the > >> last partition in DomU. > > > > You can resize within the domU if you don''t overallocate up front. > > > > Typically I will create a 16GB LV for a 8GB / and 2GB swap, or a > > 32GB LV for a 16GB / and 4GB swap and always leave around 30% > > available for future expansion or additional needs. But you > > could always bring in another LV to the domU and add it to the > > VG within the domU and resize from that. > > That''s true but in the end that needs LVM in Dom0 _and_ LVM in DomU. > Somehow I think that gets complicated especially if the LVs of the guest > should be accessible from Dom0.It''s very rare that I personally need to touch the domU''s data without the domU, besides converting from LV to image or vise-versa. Probably because my domUs are online all the time. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Javier Guerra wrote:> On Thu, May 8, 2008 at 8:12 AM, Tomasz Nowak <tnowak-p@netventure.pl> wrote: > >> Wolfgang Rosenauer <wolfgang.rosenauer@an-netz.de> wrote: >> >> >>> So my plan was to use LVs directly as partitions in the guest >>> /dev/vg/lv1 -> /dev/hda1 >>> /dev/vg/lv2 -> /dev/hda2 (or /dev/hdb1 FWIW) >>> >>> >> AFAIK this way is not to be supported in the future. >> > > it would be a real shame. > > i think most installers can respect an existing partition scheme. if > not, they should soon, since most integrators are realizing that > installing an OS doesn''t mean owning the whole hardware >Agreed. It makes snapshotting and backup of the mountable filesystems one heck of a lot easier to manage, without the vagaries of having to interpret the disk images internal file structure. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ross S. W. Walker wrote:> Nick Anderson wrote: > >> Ross S. W. Walker wrote: >> >> >>> What would be the practical reason for that as opposed to >>> allocating a bigger LV to contain all partitions? >>> >> One reason I can think of is for snapshots of the data you want to >> snapshot. If I dont care whats in /var why waste time in backing it up. >> I might want to snapshot home more often than /. If its all on one big >> LV you cant get that fine grained snapshotting can you? >> > > Just to poke a little further, why take snapshots in dom0 instead > of within domU? > > You could provide a second LV to each domU located on different spindles > that provide snapshotting within the domUs. > > -Ross > > __To avoid having to get nutso about decoding and mounting LVM tools in Dom0, and to use the superior disk I/O of Dom0 for doing the backups or duplication of its contents. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, Am Donnerstag, 8. Mai 2008 16:55 schrieb Ross S. W. Walker:> Wolfgang Rosenauer wrote: > > Ross S. W. Walker wrote: > > >> So IMHO a better way to do it is to export each lv as > > >> a separate disk and make one single partition of whole > > >> such disk in domU: > > >> /dev/vg/lv1 -> /dev/hda -> /dev/hda1 --> / > > >> /dev/vg/lv2 -> /dev/hdb -> /dev/hdb1 --> /var > > >> /dev/vg/lv3 -> /dev/hdc -> /dev/hdc1 --> /home > > >> Resizing is extremly easy (lvextend, resize2fs) > > >> and it can be done online if ext3 is used.why use multiple partitions if you can resize? /dev/vg/lv1 -> /dev/hda -> /dev/hda1 --> / /dev/vg/lv2 -> /dev/hdb -> /dev/hdb1 --> swap But i also prefer to use lvs as partitions inside domU because you don''t loose any byte for a (needless) partitiontable. It''s also easier to backup these unpartitioned lvs (you don''t need any "-o offset=XXXXX" while mounting a snapshot of this lv). Where is the discussion why this is not to be supported in the future? I''ve seen that it was mentioned here a few times but i''ve never found out what the reason could be? -- greetings eMHa _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Markus Hochholdinger <Markus@hochholdinger.net> wrote:> > why use multiple partitions if you can resize?For many other reasons partitions are made for. -- Tomek _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users