Hi list,
I''ve been playing with XCP for the first time the last couple of days.
I like the ''xe'' commands. With other systems that have a
complex
command line tool, I often have trouble remembering all the different
command names and exceptions to arguments (''koji'' is the
latest that
really pains me), but ''xe'' is clean and clear, nice!
I had intended to install the host OS on a separate disk, but that
didn''t work out, so instead it''s going onto the pair of very
small 10k
RPM disks that I had hoped to devote entirely to domU filesystems.
The XCP installer creates two partitions of about 4GB each on the first
disk. The first is the root / filesystem, clear enough. I can''t seem
to find any documentation about it. The beginning appears to contain
all NULLs, and ''strings'' finds nothing human-legible in it.
Anyone know what that partition is for? Can it be removed, or else
moved to the beginning of the second disk?
I''m also curious about the status of XCP RPM packages, parallel to the
Debian packages that already exist. I''m a tad uncomfortable with
''appliances'', and would like to get the system under
configuration
management, although XCP really does give enough value that I''m willing
to deal with it for now. ;)
Thanks-
John
Hi John, XCP questions are in general more likely to get answered on the (badly named) xen-api@ list. On Thu, 2012-08-16 at 05:09 +0100, John Morris wrote:> Hi list, > > I''ve been playing with XCP for the first time the last couple of days. > I like the ''xe'' commands. With other systems that have a complex > command line tool, I often have trouble remembering all the different > command names and exceptions to arguments (''koji'' is the latest that > really pains me), but ''xe'' is clean and clear, nice! > > I had intended to install the host OS on a separate disk, but that > didn''t work out, so instead it''s going onto the pair of very small 10k > RPM disks that I had hoped to devote entirely to domU filesystems. > > The XCP installer creates two partitions of about 4GB each on the first > disk. The first is the root / filesystem, clear enough. I can''t seem > to find any documentation about it. The beginning appears to contain > all NULLs, and ''strings'' finds nothing human-legible in it.You mean the second partition? IIRC it is a backup root partition, i.e. if you upgrade the host then (optionally?) the existing root partition can be copied there.> Anyone know what that partition is for? Can it be removed, or else > moved to the beginning of the second disk?I don''t think it can be moved.> I''m also curious about the status of XCP RPM packages, parallel to the > Debian packages that already exist. I''m a tad uncomfortable with > ''appliances'', and would like to get the system under configuration > management, although XCP really does give enough value that I''m willing > to deal with it for now. ;) > > Thanks- > > John > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users
Hello. El 15/08/12 23:09, John Morris escribió:> The XCP installer creates two partitions of about 4GB each on the first > disk. The first is the root / filesystem, clear enough. I can''t seem > to find any documentation about it. The beginning appears to contain > all NULLs, and ''strings'' finds nothing human-legible in it. > > Anyone know what that partition is for? Can it be removed, or else > moved to the beginning of the second disk?XCP team would be the authoritative source for that answer. So far, it seems like the second partition could be reserved for upgrades. The upgrade may be installed on the reserved partition, inf something goes wrong you can easily roll back to the previous installation. This is just a hypothesis. I guess you can do whatever you wish with the partitions, Linux is very transparent for this kind of modifications. Just make sure to update references in fstab and stuff. Personally, I would advice against it. XCP is a consistent, compact system, made to have a _very_ predictable behavior. If you start to mess with it beyond the expectation of the developers, you are risking to find all sort of dark places. In that case, you better go for Debian/CentOS/whatever, with regular Xen hypervisor and XenAPI. In order to dedicate the HDD to the DomU''s, consider installing the host system on a USB flash drive. Some server have a nice internal USB connector. In case of XCP, it will require some tricks to make it boot (re-build initrd), but it''s less invasive than re-ordering partitions. You will need at least 16GB drive. It is also possibleto install it on a 4GB drive, that is slightly more invasive. -- Alexandre Kouznetsov
Hi Alexandre,> Personally, I would advice against it. XCP is a consistent, compact > system, made to have a _very_ predictable behavior. If you start to mess > with it beyond the expectation of the developers, you are risking to > find all sort of dark places. In that case, you better go for > Debian/CentOS/whatever, with regular Xen hypervisor and XenAPI.I agree with you under normal circumstances. Difference here is I expect to convert to CentOS with XCP RPMs whenever they become available, even if I end up writing them myself. I''m not afraid of the source. ;)> In order to dedicate the HDD to the DomU''s, consider installing the host > system on a USB flash drive. Some server have a nice internal USB > connector. In case of XCP, it will require some tricks to make it boot > (re-build initrd), but it''s less invasive than re-ordering partitions. > You will need at least 16GB drive. It is also possibleto install it on a > 4GB drive, that is slightly more invasive.Great idea, that''s what I decided to do. My original attempt I alluded to where I tried to install the host OS onto a ''separate disk'' was a similar idea that didn''t work out. The root fs was an 8GB CF card tested in all kinds of converters (SATA, USB, PCMCIA), but it refused to write faster than 1.8 MB/s (despite being 133x, theoretically ~19 MB/s). The USB flash drive is also pretty slow, but not nearly as bad. I wrote up a cookbook to automate the initrd rebuild with a post-install script for those using an XCP answer file. It occurs to me that /etc/fstab should mount / with the noatime option, and (something a script can''t know how to do) move the swapfile somewhere else. http://www.zultron.com/2012/08/xcp-on-usb-automate-initrd-rebuild/ John
El 17/08/12 01:02, John Morris escribió:> I''m not afraid of the source. ;)Heh, sorry for the underestimation. (: Never felt like the Flash speed has been an issue for me. Some bit slow on response, nothing more. Ah, and my installation was from network, so I had to use NFS instead of HTTP to fetch the data, the writing was slow and http suffered timeouts. But, I must add, I never wen beyond pilot tests with XCP, no production. In my case I stuck with the setup of a orchestration platform.> I wrote up a cookbook to automate the initrd rebuild with a post-install > script for those using an XCP answer file. It occurs to me that > /etc/fstab should mount / with the noatime option, and (something a > script can''t know how to do) move the swapfile somewhere else. > > http://www.zultron.com/2012/08/xcp-on-usb-automate-initrd-rebuild/Great reference. In my case, I have generated the initrd once and then booted the nodes from PXE using it, with the same mechanism I used to install them initially. -- Alexandre Kouznetsov
On 08/17/2012 11:10 AM, Alexandre Kouznetsov wrote:> El 17/08/12 01:02, John Morris escribió: >> I''m not afraid of the source. ;) > Heh, sorry for the underestimation. > (:Well, just because I''m fearless doesn''t mean I''m not green. Maybe being fearless implies greenness? :)> Never felt like the Flash speed has been an issue for me. Some bit slow > on response, nothing more. Ah, and my installation was from network, so > I had to use NFS instead of HTTP to fetch the data, the writing was slow > and http suffered timeouts.Have you ever enabled the yum repos and installed an RPM? That can take 30s on my Patriot 16GB USB stick (that''s reputedly a good brand, last I heard, so that''s one less of a whole slew of things to suspect). So far the slowness doesn''t matter too much, although it does take quite a while to initialize a VM boot. I didn''t have the same trouble you did with TCP timeouts though. That really does sound excessively slow. Like I said though, I still hope to get the domU under configuration management (with XenAPI, with or without XCP), and my first tests are fairly painful, scanning the system.> But, I must add, I never wen beyond pilot tests with XCP, no production. > In my case I stuck with the setup of a orchestration platform.That sounds like fun! I''m just setting up shop, so only two hosts in a resource pool. Please wish me enough luck to scale up to where I''ll get to play too. ;) John