Well, now that I''ve figured out that network booting XCP is not really going to be feasible, I''m moving on to my next option: flash media installation. The systems that I purchased have SDHC slots on them, so I figured I''d attempt to install XCP to one of these cards. I had already read that there''s a minimum disk size in the installer (apparently 12 GB in XCP) and so have factored in that. However, whenever I try to install I get an error message that the "Partition size in sectors is negative." Any ideas on this one? Any better way to install to flash media? I suppose I could go ahead and do the install to a regular HD, then use a rescue system and dd to grab an image of the system partition, then transfer it to the flash media. Any other possible paths? Anyone running XCP or XenServer off SDHC or other flash-based media? Thanks - Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
2012/2/8 Nick Couchman <Nick.Couchman@seakr.com>:> Well, now that I've figured out that network booting XCP is not really > going to be feasible, I'm moving on to my next option: flash media > installation. The systems that I purchased have SDHC slots on them, so > I figured I'd attempt to install XCP to one of these cards. I had > already read that there's a minimum disk size in the installer > (apparently 12 GB in XCP) and so have factored in that. However, > whenever I try to install I get an error message that the "Partition > size in sectors is negative." Any ideas on this one?I've successfully installed XCP on a SD card some time ago, but I don't recommend that. Running an OS from a SD is not recommended because the access time is large, and the system can feel irresponsible some times.> Any better way to > install to flash media? I suppose I could go ahead and do the install > to a regular HD, then use a rescue system and dd to grab an image of the > system partition, then transfer it to the flash media. Any other > possible paths?Installing the image and doing a dd will not work straight away, you will have to use syslinux to make the usb bootable, but again you will face access problems.> Anyone running XCP or XenServer off SDHC or other > flash-based media?I'm using a SD card to boot a regular Xen install (4.1.2) on some of my servers, using Alpine Linux which is easy to install to a SD card, has a very small footprint and works great with Xen. Don't have experience with XenServer.> > Thanks - Nick > > > > -------- > This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. > > _______________________________________________ > 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 Thu, 2012-02-09 at 10:01 +0100, Roger Pau Monné wrote:> 2012/2/8 Nick Couchman <Nick.Couchman@seakr.com>: > > Well, now that I''ve figured out that network booting XCP is not really > > going to be feasible, I''m moving on to my next option: flash media > > installation. The systems that I purchased have SDHC slots on them, so > > I figured I''d attempt to install XCP to one of these cards. I had > > already read that there''s a minimum disk size in the installer > > (apparently 12 GB in XCP) and so have factored in that. However, > > whenever I try to install I get an error message that the "Partition > > size in sectors is negative." Any ideas on this one? > > I''ve successfully installed XCP on a SD card some time ago, but I > don''t recommend that. Running an OS from a SD is not recommended > because the access time is large, and the system can feel > irresponsible some times.I''m willing to take the risk - I''m using Class 10 SDHC cards (10MB/s), and there isn''t going to be a lot going on at the dom0 level that is going to require responsiveness. Additionally, I''ll be doing syslog to a remote machine, so this should take care of some of the normal read/write traffic that would be on the local disk.> > > Any better way to > > install to flash media? I suppose I could go ahead and do the install > > to a regular HD, then use a rescue system and dd to grab an image of the > > system partition, then transfer it to the flash media. Any other > > possible paths? > > Installing the image and doing a dd will not work straight away, you > will have to use syslinux to make the usb bootable, but again you will > face access problems. > > > Anyone running XCP or XenServer off SDHC or other > > flash-based media? > > I''m using a SD card to boot a regular Xen install (4.1.2) on some of > my servers, using Alpine Linux which is easy to install to a SD card, > has a very small footprint and works great with Xen. Don''t have > experience with XenServer. >I did throw a 16GB SDHC card into one of the systems and ran the XCP install, and it worked fine. It installed to the SDHC card. The only issue I ran into is that in the case the SDHC card is seen as a USB storage device by the O/S, and the default XCP initrd did not have usb-storage loaded. So, I had to boot into a rescue system, mount the SDHC card, and regenerate the initrd, and reboot. It is working well, now, and I''ve ordered SDHC cards for the rest of the systems so that I can install XCP this way. I will have to see longer-term if there are any adverse side-effects of install XCP this way - performance, degradation of the flash devices, etc. -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
> > > I did throw a 16GB SDHC card into one of the systems and ran the XCP > install, and it worked fine. It installed to the SDHC card. The only > issue I ran into is that in the case the SDHC card is seen as a USB > storage device by the O/S, and the default XCP initrd did not have > usb-storage loaded. So, I had to boot into a rescue system, mount the > SDHC card, and regenerate the initrd, and reboot. It is working well, > now, and I''ve ordered SDHC cards for the rest of the systems so that I > can install XCP this way. I will have to see longer-term if there are > any adverse side-effects of install XCP this way - performance, > degradation of the flash devices, etc. > > -Nick > > >I considered this option on my hosts but then I realized that the price of the 16 GB SDHC card and reader was the same price of a 300 GB hard drive. By the time I ordered equipment I paid another $10 for 1 TB drives. They stay mostly empty but I figure I could repurpose them if I decide to change it. Grant McWilliams http://grantmcwilliams.com/ Some people, when confronted with a problem, think "I know, I''ll use Windows." Now they have two problems. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, 2012-02-10 at 10:42 -0800, Grant McWilliams wrote:> I considered this option on my hosts but then I realized that the > price of the 16 GB SDHC card and reader was the same price of a 300 GB > hard drive. By the time I ordered equipment I paid another $10 for 1 > TB drives. They stay mostly empty but I figure I could repurpose them > if I decide to change it. >I got the 16GB SDHC cards for $20/ea (yes, I realize that the quality may not be top-notch, but I''ll risk it for now) - quite a bit less than the 300 - 500 GB drives I was looking at. Additionally, power consumption will be lower, if only marginally so (yes, I realize that HDDs are not the consumers of most of the power in a system). :-) -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
I like using SSD drives for boot drives in each XCP blade. It is flash media, but uses a SATA connection and requires a drive bay. Boots very quickly. If you don''t have room for a drive in your chassis, you could try using a SATA DOM (disk on module). I don''t store any VM images on the local drives, though. I use ZFS based NFS targets for storing all of the VMs. -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Nick Couchman Sent: Wednesday, February 08, 2012 10:19 AM To: xen-users@lists.xensource.com Subject: [Xen-users] [XCP] Install to Flash Media Well, now that I''ve figured out that network booting XCP is not really going to be feasible, I''m moving on to my next option: flash media installation. The systems that I purchased have SDHC slots on them, so I figured I''d attempt to install XCP to one of these cards. I had already read that there''s a minimum disk size in the installer (apparently 12 GB in XCP) and so have factored in that. However, whenever I try to install I get an error message that the "Partition size in sectors is negative." Any ideas on this one? Any better way to install to flash media? I suppose I could go ahead and do the install to a regular HD, then use a rescue system and dd to grab an image of the system partition, then transfer it to the flash media. Any other possible paths? Anyone running XCP or XenServer off SDHC or other flash-based media? Thanks - Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
What file system are you going to use? With flash media you will eventually wear out your device, wearing out specific blocks and then using up spare blocks which will then cause the device to go offline or the filesystem to go readonly. While each block can be written millions of times, all it takes is a the same block to be repeatedly written to. There are parts of the filesystem that are like that. Such as a journal. You can go with extending the commit interval but that is dangerous. Maybe not so much if you consider that you''re not writing important data. Just boot files etc. But still your not going to like that if the writes were needless. So some extra work on your part can help identify and weed out those processes. I''d recommend a ext2, and also mount with noatime to reduce the unnecessary writes. Beware of lock or stat files that get touched regularly. Those too create lots of writes unnecessarily. You could use a really small ramfs for those dirs. This is great for a file or directory that has state information which won''t matter after a reboot. You can do some tests watching for io to the disks to see what processes are writing to what parts. echo 1 > /proc/sys/vm/block_dump Use dmesg or redirect with klog to a file to see the process name, id, inode, filename, and device. On a journaled file system like ext3, you''ll see your write, and then a few seconds later you''ll see the journal commit the changes. Notice that the same inodes get written to over and over. Sort and word count those to see how many times in a minute or hour and you''ll see the heavily used blocks. Doing this upfront can give you many years of reliable usage. Without it, you could easily wear out your device in a year. Also, flash blocks or pages are not the same as your file system blocks. It''s not a 1 to 1 relationship. So 1 512byte FS block, could be sharing a page with other blocks. Writes to 2 separate FS blocks could affect the same flash page. There are also flash file systems (i.e. jffs2 and a number of others) that are supported by the linux kernel. Most distributions don''t support those by default, so you may have to recompile your kernel to include it. They are more common on embedded systems. But they are out there and they do the extra work for you of leveling the where on on the flash device. Thanks Scott On Feb 10, 2012, at 8:30 AM, Nick Couchman wrote:> On Thu, 2012-02-09 at 10:01 +0100, Roger Pau Monné wrote: >> 2012/2/8 Nick Couchman <Nick.Couchman@seakr.com>: >>> Well, now that I''ve figured out that network booting XCP is not really >>> going to be feasible, I''m moving on to my next option: flash media >>> installation. The systems that I purchased have SDHC slots on them, so >>> I figured I''d attempt to install XCP to one of these cards. I had >>> already read that there''s a minimum disk size in the installer >>> (apparently 12 GB in XCP) and so have factored in that. However, >>> whenever I try to install I get an error message that the "Partition >>> size in sectors is negative." Any ideas on this one? >> >> I''ve successfully installed XCP on a SD card some time ago, but I >> don''t recommend that. Running an OS from a SD is not recommended >> because the access time is large, and the system can feel >> irresponsible some times. > > I''m willing to take the risk - I''m using Class 10 SDHC cards (10MB/s), > and there isn''t going to be a lot going on at the dom0 level that is > going to require responsiveness. Additionally, I''ll be doing syslog to > a remote machine, so this should take care of some of the normal > read/write traffic that would be on the local disk. > >> >>> Any better way to >>> install to flash media? I suppose I could go ahead and do the install >>> to a regular HD, then use a rescue system and dd to grab an image of the >>> system partition, then transfer it to the flash media. Any other >>> possible paths? >> >> Installing the image and doing a dd will not work straight away, you >> will have to use syslinux to make the usb bootable, but again you will >> face access problems. >> >>> Anyone running XCP or XenServer off SDHC or other >>> flash-based media? >> >> I''m using a SD card to boot a regular Xen install (4.1.2) on some of >> my servers, using Alpine Linux which is easy to install to a SD card, >> has a very small footprint and works great with Xen. Don''t have >> experience with XenServer. >> > > I did throw a 16GB SDHC card into one of the systems and ran the XCP > install, and it worked fine. It installed to the SDHC card. The only > issue I ran into is that in the case the SDHC card is seen as a USB > storage device by the O/S, and the default XCP initrd did not have > usb-storage loaded. So, I had to boot into a rescue system, mount the > SDHC card, and regenerate the initrd, and reboot. It is working well, > now, and I''ve ordered SDHC cards for the rest of the systems so that I > can install XCP this way. I will have to see longer-term if there are > any adverse side-effects of install XCP this way - performance, > degradation of the flash devices, etc. > > -Nick > > > > -------- > This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users
On Fri, 2012-02-10 at 16:06 -0800, Scott Mewett wrote:> What file system are you going to use?Since I''m using XCP, I don''t think I have choice in the matter. XCP uses ext3 as the default FS.> > With flash media you will eventually wear out your device, wearing out specific blocks and then using up spare blocks which will then cause the device to go offline or the filesystem to go readonly. While each block can be written millions of times, all it takes is a the same block to be repeatedly written to. There are parts of the filesystem that are like that. Such as a journal. > > You can go with extending the commit interval but that is dangerous. Maybe not so much if you consider that you''re not writing important data. Just boot files etc. But still your not going to like that if the writes were needless. So some extra work on your part can help identify and weed out those processes. > > I''d recommend a ext2, and also mount with noatime to reduce the unnecessary writes.Thanks for the hints. I''ve mounted with the noatime and noload parameters. The noload disabled loading of the journal; however, I''m not sure whether it actually disables the journal functionality or not. I may need to remount with ext2 instead of ext3, which should be the same as disabling journaling. However, since this is just the dom0 management interface and the hypervisor, and I''m logging to a remote host, I don''t think it''ll be too bad.> > Beware of lock or stat files that get touched regularly. Those too create lots of writes unnecessarily. You could use a really small ramfs for those dirs. This is great for a file or directory that has state information which won''t matter after a reboot. > > You can do some tests watching for io to the disks to see what processes are writing to what parts. > echo 1 > /proc/sys/vm/block_dump > Use dmesg or redirect with klog to a file to see the process name, id, inode, filename, and device. > On a journaled file system like ext3, you''ll see your write, and then a few seconds later you''ll see the journal commit the changes. > Notice that the same inodes get written to over and over. Sort and word count those to see how many times in a minute or hour and you''ll see the heavily used blocks. > > Doing this upfront can give you many years of reliable usage. Without it, you could easily wear out your device in a year. > > Also, flash blocks or pages are not the same as your file system blocks. It''s not a 1 to 1 relationship. So 1 512byte FS block, could be sharing a page with other blocks. Writes to 2 separate FS blocks could affect the same flash page.I''ll definitely look into all of these things, as well.> > There are also flash file systems (i.e. jffs2 and a number of others) that are supported by the linux kernel. Most distributions don''t support those by default, so you may have to recompile your kernel to include it. They are more common on embedded systems. But they are out there and they do the extra work for you of leveling the where on on the flash device.Yeah, it''d be nice if the XCP or XenServer products had an option to install to flash media - many of the newer servers still include flash-based devices as options for loading hypervisors and the like. -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Hi, My experience has shown me that just remounting an ext3 file system as ext2, doesn''t fully disable all the journal bits. You have to remove the journal as well. I found that by watching the io debug output after remounting. Thanks Scott On Feb 12, 2012, at 2:51 PM, Nick Couchman wrote:> On Fri, 2012-02-10 at 16:06 -0800, Scott Mewett wrote: >> What file system are you going to use? > > Since I''m using XCP, I don''t think I have choice in the matter. XCP > uses ext3 as the default FS. > >> >> With flash media you will eventually wear out your device, wearing out specific blocks and then using up spare blocks which will then cause the device to go offline or the filesystem to go readonly. While each block can be written millions of times, all it takes is a the same block to be repeatedly written to. There are parts of the filesystem that are like that. Such as a journal. >> >> You can go with extending the commit interval but that is dangerous. Maybe not so much if you consider that you''re not writing important data. Just boot files etc. But still your not going to like that if the writes were needless. So some extra work on your part can help identify and weed out those processes. >> >> I''d recommend a ext2, and also mount with noatime to reduce the unnecessary writes. > > Thanks for the hints. I''ve mounted with the noatime and noload > parameters. The noload disabled loading of the journal; however, I''m > not sure whether it actually disables the journal functionality or not. > I may need to remount with ext2 instead of ext3, which should be the > same as disabling journaling. However, since this is just the dom0 > management interface and the hypervisor, and I''m logging to a remote > host, I don''t think it''ll be too bad. > >> >> Beware of lock or stat files that get touched regularly. Those too create lots of writes unnecessarily. You could use a really small ramfs for those dirs. This is great for a file or directory that has state information which won''t matter after a reboot. >> >> You can do some tests watching for io to the disks to see what processes are writing to what parts. >> echo 1 > /proc/sys/vm/block_dump >> Use dmesg or redirect with klog to a file to see the process name, id, inode, filename, and device. >> On a journaled file system like ext3, you''ll see your write, and then a few seconds later you''ll see the journal commit the changes. >> Notice that the same inodes get written to over and over. Sort and word count those to see how many times in a minute or hour and you''ll see the heavily used blocks. >> >> Doing this upfront can give you many years of reliable usage. Without it, you could easily wear out your device in a year. >> >> Also, flash blocks or pages are not the same as your file system blocks. It''s not a 1 to 1 relationship. So 1 512byte FS block, could be sharing a page with other blocks. Writes to 2 separate FS blocks could affect the same flash page. > > I''ll definitely look into all of these things, as well. > >> >> There are also flash file systems (i.e. jffs2 and a number of others) that are supported by the linux kernel. Most distributions don''t support those by default, so you may have to recompile your kernel to include it. They are more common on embedded systems. But they are out there and they do the extra work for you of leveling the where on on the flash device. > > Yeah, it''d be nice if the XCP or XenServer products had an option to > install to flash media - many of the newer servers still include > flash-based devices as options for loading hypervisors and the like. > > -Nick > > > > -------- > This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users