From: ruben.cervantes <rub...@cm...> - 2012-12-12 13:45:20
|
hello friends am writing to see if you possible for developers of this project will include support for virtualbox vdi file is an idea that occurred to me as these files are smaller and are easier to transport. I implemented a of thin clients network with this technology and so far everything works fine but I vastante occupies a great in the hard disk, well this is the idea that make your images smaller, best regards -- Nombre: Lic. Ruben Cervantes Rodríguez Cargo: Instructor y administrador de red Municipio: Vertientes Provincia: Camagüey Cuba Teléfono: 30-7406 |
From: Ross S. W. W. <RW...@me...> - 2012-12-12 14:20:36
Attachments:
vaca.png
eslogan.jpg
|
On Dec 12, 2012, at 8:45 AM, "ruben.cervantes" <rub...@cm...> wrote: > hello friends am writing to see if you possible for developers of this project will include support for virtualbox vdi file is an idea that occurred to me as these files are smaller and are easier to transport. I implemented a of thin clients network with this technology and so far everything works fine but I vastante occupies a great in the hard disk, well this is the idea that make your images smaller, best regards Well supporting proprietary technology as a backend is just asking for patent trouble in the future. Besides it would severely bloat the kernel module at the very least, or complicate things with multiple kernel modules. If you want small storage explore the use of sparse files for backing stores. Different file systems give different sparse file performance characteristics, so look at all the currently supported file systems, ext3, ext4, xfs, etc. I believe utilities exist to convert virtual disks from one format to another you just need to google. -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. |
From: ruben.cervantes <rub...@cm...> - 2012-12-12 15:55:14
|
El 12/12/12 09:20, Ross S. W. Walker escribió: > On Dec 12, 2012, at 8:45 AM, "ruben.cervantes"<rub...@cm...> wrote: > > >> hello friends am writing to see if you possible for developers of this project will include support for virtualbox vdi file is an idea that occurred to me as these files are smaller and are easier to transport. I implemented a of thin clients network with this technology and so far everything works fine but I vastante occupies a great in the hard disk, well this is the idea that make your images smaller, best regards >> > Well supporting proprietary technology as a backend is just asking for patent trouble in the future. Besides it would severely bloat the kernel module at the very least, or complicate things with multiple kernel modules. > > If you want small storage explore the use of sparse files for backing stores. Different file systems give different sparse file performance characteristics, so look at all the currently supported file systems, ext3, ext4, xfs, etc. > > I believe utilities exist to convert virtual disks from one format to another you just need to google. > > -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. > if it know it is something complicated to do, well I found a converter that has served me of much and so far I've solved. Thanks for the reply -- Nombre: Lic. Ruben Cervantes Rodríguez Cargo: Instructor y administrador de red Municipio: Vertientes Provincia: Camagüey Cuba Teléfono: 30-7406 |
From: Ross S. W. W. <RW...@me...> - 2012-12-12 14:35:15
|
On Dec 12, 2012, at 9:25 AM, "Turbo Fredriksson" <tu...@ba...> wrote: > On Dec 12, 2012, at 3:20 PM, Ross S. W. Walker wrote: > >> If you want small storage explore the use of sparse files for backing stores. > > Or try ZFS and enable deduplication. Dedup is slower than sparse files, but I don't think the issue the OP mentions has to do with duplicate data, but wasted space from thick allocation (unused data). If you have cloned VMs though using ZFS cloned sparse zdevs could provide both performance and space savings. ZFS is a COW file system so data gets random over time, which happens also with sparse files, so sparse files on ZFS go hand-in-hand with the file system itself. -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. |
From: Turbo F. <tu...@ba...> - 2012-12-12 14:47:42
|
[sorry, should have gone to the list, not Ross] On Dec 12, 2012, at 3:20 PM, Ross S. W. Walker wrote: > If you want small storage explore the use of sparse files for backing stores. Or try ZFS and enable deduplication. -- As soon as you find a product that you really like, they will stop making it. - Wilson's Law |
From: Turbo F. <tu...@ba...> - 2012-12-12 16:34:38
|
On Dec 12, 2012, at 3:34 PM, Ross S. W. Walker wrote: > Dedup is slower than sparse files, but I don't think the issue the OP mentions has to do with duplicate data, but wasted space from thick allocation (unused data). > If you have cloned VMs though using ZFS cloned sparse zdevs could provide both performance and space savings. So sparse + dedup is a very nice combination that isn't available (stable) in any other FS that I know of. |
From: Ross S. W. W. <RW...@me...> - 2012-12-12 17:12:30
|
Turbo Fredriksson [mailto:tu...@ba...] wrote: > On Dec 12, 2012, at 3:34 PM, Ross S. W. Walker wrote: > > > Dedup is slower than sparse files, but I don't think the issue the OP > > mentions has to do with duplicate data, but wasted space from thick > > allocation (unused data). > > > If you have cloned VMs though using ZFS cloned sparse zdevs could > > provide both performance and space savings. > > So sparse + dedup is a very nice combination that isn't available > (stable) in any other FS that I know of. There are storage solutions though from EMC, NetApp, Compellent and others that can provide sparse (thin provisioned) and deduplicated volumes through FC, iSCSI, FCoE and CIFS/NFS, so it isn't the only game in town. All VMware ESX VMDK files on top of NFS shares are thin, so if you use a ZFS deduplicated volume over NFS then it will be both thin and deduplicated by default. My personal best practice is to store VMDK files on NFS and put application data on RDMs using block storage protocols such as FC, iSCSI or FCoE. To that end ZFS is best for those NFS VMDK volumes of gigantic size. ZFS's self healing and data integrity checks are a life saver for those volumes that are too big to backup. Please note, that setup works for us because we have redundant virtual servers in multiple data centers with application data replicated and backed up in each data center. -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. |