Hi, I am wanting to set up a bunch of system templates for my Xen servers, to save me from running some standard package installs and configuration. I can see 4 alternatives, but all seem to have issues and I''m wondering what works in practice: 1) LVM snapshot Problem with this is that I don''t see any way to change the disk size of the new disk ever. Fast though. 2) New device and block level copy (dd) Seems to work fine, but the disk needs to be repartitioned and filesystem resized for bigger disks on the new guest. Takes a while. 3) New device and file level copy (cpio) Can completely change the partition scheme and filesystem. Complex to do from dom0. Slow. 4) virt-clone? I couldn''t get this to work at all. Either the domU was running and I got "ERROR Domain status must be SHUTOFF" or the domU was shutdown and I got "ERROR Domain test is not found". Regards, Jeff _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, about LVM : one the big advantages of LVM is the resize... "lvresize" on Dom0, then (for ext3/ext4) resize2fs in DomU. Olivier Jeff Williams a écrit :> Hi, > > I am wanting to set up a bunch of system templates for my Xen servers, > to save me from running some standard package installs and > configuration. I can see 4 alternatives, but all seem to have issues > and I''m wondering what works in practice: > > 1) LVM snapshot > > Problem with this is that I don''t see any way to change the disk size > of the new disk ever. Fast though. > > 2) New device and block level copy (dd) > > Seems to work fine, but the disk needs to be repartitioned and > filesystem resized for bigger disks on the new guest. Takes a while. > > 3) New device and file level copy (cpio) > > Can completely change the partition scheme and filesystem. Complex to > do from dom0. Slow. > > 4) virt-clone? > > I couldn''t get this to work at all. Either the domU was running and I > got "ERROR Domain status must be SHUTOFF" or the domU was shutdown > and I got "ERROR Domain test is not found". > > Regards, > Jeff > > _______________________________________________ > 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 Mon, Jun 8, 2009 at 9:42 AM, Olivier B.<xen.list@daevel.fr> wrote:> about LVM : one the big advantages of LVM is the resize... "lvresize" on > Dom0, then (for ext3/ext4) resize2fs in DomU.add a partition resize step. even so, this only works if the filesystem you want to resize is the last partition in the virtual device -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Javier Guerra a écrit :> On Mon, Jun 8, 2009 at 9:42 AM, Olivier B.<xen.list@daevel.fr> wrote: > >> about LVM : one the big advantages of LVM is the resize... "lvresize" on >> Dom0, then (for ext3/ext4) resize2fs in DomU. >> > > add a partition resize step. even so, this only works if the > filesystem you want to resize is the last partition in the virtual > device >I never partition LVM "virtual device", I used different LV. So there is no problem to resize any of this partitions. About the additionnal step, I don''t really see where it is a problem. Olivier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Olivier B. > Sent: Monday, June 08, 2009 11:02 AM > To: xen-users@lists.xensource.com > Subject: Re: [Xen-users] Making system templates > > I never partition LVM "virtual device", I used different LV. > So there is no problem to resize any of this partitions. > About the additionnal step, I don''t really see where it is a problem.We do the same, to the extent that we''ve often stripped away partition tables even when doing a physical->virtual migration. LVM makes partition tables seem entirely obsolete for paravirtualized hosts--they are an artifact of the system BIOS. (In some cases those partitions contained their own volume group, so a trival migration results in logical volumes inside a volume group inside a partion table inside a logical volume...ewww.) I''m new to the list, but from what reading I''ve done I notice there are two broad methodologies forming around virtual system management: One that wants to treat virtual images as identical to physical systems with disk partitions, native installers, boot loaders, etc. while another, simpler approach takes fuller advantage of the paravirtualized model and Dom0 capabilities (LVM etc). For whatever reason, most of the tools I find (koan, virt-install) seem to fall into the former group. We''ve fallen back on rolling our own techniques to create and manage DomU templates. One comment to the original poster-- if your procedure to clone a system involves copying files rather than filesystem images, you need to additionally perform a filesystem relabeling in case you need or want SELinux. Jeff _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Jun 8, 2009 at 10:57 AM, Jeff Sturm<jeff.sturm@eprize.com> wrote:> I''m new to the list, but from what reading I''ve done I notice there are > two broad methodologies forming around virtual system management: One > that wants to treat virtual images as identical to physical systems with > disk partitions, native installers, boot loaders, etc. while another, > simpler approach takes fuller advantage of the paravirtualized model and > Dom0 capabilities (LVM etc).I wholeheartedly agree that partitions are a thorn and should be deprecated. unfortunately, HVM DomU''s require them; and most tools (libvirt in this case) default to creating them in most (all?) cases. i might be wrong, but i think that even recent linux installers, which are virtualization aware (ubuntu jeos and suse limejuice) do the same, using the same old partitioners as always (with just a few tweaks, like using the noop scheduler by default) so, i think partitions are going to stay bothering us for a while. -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Jun 8, 2009 at 4:37 PM, Jeff Williams <jeffw@globaldial.com> wrote:> Hi, > > I am wanting to set up a bunch of system templates for my Xen servers, to > save me from running some standard package installs and configuration. I can > see 4 alternatives, but all seem to have issues and I''m wondering what works > in practice: > > 1) LVM snapshot > > Problem with this is that I don''t see any way to change the disk size of > the new disk ever. Fast though. > > 2) New device and block level copy (dd) > > Seems to work fine, but the disk needs to be repartitioned and filesystem > resized for bigger disks on the new guest. Takes a while. > > 3) New device and file level copy (cpio) > > Can completely change the partition scheme and filesystem. Complex to do > from dom0. Slow. > > 4) virt-clone? > > I couldn''t get this to work at all. Either the domU was running and I got > "ERROR Domain status must be SHUTOFF" or the domU was shutdown and I got > "ERROR Domain test is not found". > > Regards, > Jeff > > _______________________________________________ >Jeff, take a look @ HyperVM. We use it for this exact same reason. I can setup a cPanel VPS, pre-configure it with all the security tools, etc and then make it a template, ready to deploy for the new client. Upgrading (more RAM / HDD space / IP''s / bandwidth / etc) is a click of a button as well. -- Kind Regards Rudi Ahlers CEO, SoftDux Hosting Web: http://www.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
For linux templates (W/pvm), I use tar+gzip/bzip to preserve the contents of the drive. The script that provisions new VMs creates a new drive using lvm and untars the desired initialization contents. Size is determined before the untar operation so as long as the new lv is at least as large as the original volume, no problem. In this case the lv is a partition, not a drive so lvresize will work fine. No partition tables either. The LV just mounts on the Dom0 for setup. -----Original Message----- From: Jeff Williams [mailto:jeffw@globaldial.com] Sent: Monday, June 08, 2009 7:38 AM To: xen-users@lists.xensource.com Subject: [Xen-users] Making system templates Hi, I am wanting to set up a bunch of system templates for my Xen servers, to save me from running some standard package installs and configuration. I can see 4 alternatives, but all seem to have issues and I''m wondering what works in practice: 1) LVM snapshot Problem with this is that I don''t see any way to change the disk size of the new disk ever. Fast though. 2) New device and block level copy (dd) Seems to work fine, but the disk needs to be repartitioned and filesystem resized for bigger disks on the new guest. Takes a while. 3) New device and file level copy (cpio) Can completely change the partition scheme and filesystem. Complex to do from dom0. Slow. 4) virt-clone? I couldn''t get this to work at all. Either the domU was running and I got "ERROR Domain status must be SHUTOFF" or the domU was shutdown and I got "ERROR Domain test is not found". Regards, Jeff _______________________________________________ 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
For my templates here (Windows XP/2003 Server/Linux/Solaris etc.) I make a copy of the disk image (not using LVMs so migration between servers is easier) once I have it configured to a "base" setting and have them sitting on an NFS share. I created a script to be run on the Xen host that will ask for the amount of RAM/CPU, the name and which directory to copy it into. The script then copies the disk files and base config file, edits the config file to include the path to the disk file as well as how much RAM/CPUs the machine needs. This makes for a 30 minute rollout for a new server from when I start the copy to renaming and handing over to the end user who requires it. I realize this doesn''t help for you if you are using LVMS (which I think you are), but if you can agree on a uniform size for all your VMs you could DD the LVM partition into a file then DD it onto a new partition of the exact same size when you want to provision a new VM. For example, our Windows Server 2003 VMs are 20GB in size, Linux is 20GB, XP is 10GB... Then if you want to have more disk space, carve out another LVM and attach it to the domU in the config file. It tends to work really well here. Tait> -----Original Message----- > From: xen-users-bounces@lists.xensource.com [mailto:xen-users- > bounces@lists.xensource.com] On Behalf Of David Morris > Sent: Monday, June 08, 2009 4:21 PM > To: xen-users@lists.xensource.com > Subject: RE: [Xen-users] Making system templates > > > For linux templates (W/pvm), I use tar+gzip/bzip to preserve the > contents of the drive. The script that provisions new VMs creates a new > drive using lvm and untars the desired initialization contents. Size is > determined before the untar operation so as long as the new lv is at > least as large as the original volume, no problem. In this case the lv > is a partition, not a drive so lvresize will work fine. No partition > tables either. The LV just mounts on the Dom0 for setup. > > -----Original Message----- > From: Jeff Williams [mailto:jeffw@globaldial.com] > Sent: Monday, June 08, 2009 7:38 AM > To: xen-users@lists.xensource.com > Subject: [Xen-users] Making system templates > > Hi, > > I am wanting to set up a bunch of system templates for my Xen servers, > to save me from running some standard package installs and > configuration. I can see 4 alternatives, but all seem to have issues > and > I''m wondering what works in practice: > > 1) LVM snapshot > > Problem with this is that I don''t see any way to change the disk size > of > the new disk ever. Fast though. > > 2) New device and block level copy (dd) > > Seems to work fine, but the disk needs to be repartitioned and > filesystem resized for bigger disks on the new guest. Takes a while. > > 3) New device and file level copy (cpio) > > Can completely change the partition scheme and filesystem. Complex to > do > from dom0. Slow. > > 4) virt-clone? > > I couldn''t get this to work at all. Either the domU was running and I > got "ERROR Domain status must be SHUTOFF" or the domU was shutdown > and I got "ERROR Domain test is not found". > > Regards, > Jeff > > _______________________________________________ > 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_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Jeff Williams wrote:> Hi, > > I am wanting to set up a bunch of system templates for my Xen servers, > to save me from running some standard package installs and > configuration. I can see 4 alternatives, but all seem to have issues and > I''m wondering what works in practice: > > 1) LVM snapshot > 2) New device and block level copy (dd) > 3) New device and file level copy (cpio) > 4) virt-clone?Hi, The best way ever is... to NOT use templates or images. Templates gets outdated, and soon have loads of package to upgrade. The best way (whenever possible, this is not always the case) is to use tools to pull and setup packages out of FTP repositories. In Debian, there is "debootstrap" to build a debian (and many other debian based systems) OS in a chroot. There is also yum to bootstrap RPM based distributions (previously we were using rpmstrap, but it''s not a good idea, it gets outdated so fast...). When bootstraping is not possible, we use tar.gz archives that we extract, then scripts to setup things like fstab, network config, and so on. We have availble Fedora 9 and 10, gentoo, Ubuntu 8.04 and 9.04, Mandriva 2009. There is a special case: NetBSD. As it''s using its own filesystem with no write access in Debian, we just use the netbsd INSTALL kernel so our users can use the setup software of NetBSD directly. Last, we have a 3rd system: appliances. Whenever someone selects it, the operating system on which it depends is setup, then a startup script is added together with a folder of the appliance. Then, at first boot, the setup start and the appliance is installed. As appliance, we have for the moment: FreeNX, OpenVPN, FreePBX. We intend to do more of them in the near future. Note that all the above is available in our FTP repositories and their mirrors, as it''s all in open source (DTC, DTC-Xen, dtc-xen-os-* and dtc-xen-app-*). Thomas Goirand (GPLHost) _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> -----Original Message----- > From: Thomas Goirand [mailto:thomas@goirand.fr] > Sent: Monday, June 08, 2009 2:15 PM > Cc: xen-users@lists.xensource.com > Subject: Re: [Xen-users] Making system templates > > The best way ever is... to NOT use templates or images. > Templates gets outdated, and soon have loads of package to > upgrade. The best way (whenever possible, this is not always > the case) is to use tools to pull and setup packages out of > FTP repositories.That is not always true ... Templates provide stability in terms of the environment. It is often desireable to reproduce consistent configurations so as to avoid unexpected changes. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 08/06/09 23:02, Olivier B. wrote:> Javier Guerra a écrit : >> On Mon, Jun 8, 2009 at 9:42 AM, Olivier B.<xen.list@daevel.fr> wrote: >> >>> about LVM : one the big advantages of LVM is the resize... >>> "lvresize" on >>> Dom0, then (for ext3/ext4) resize2fs in DomU. >>> >> >> add a partition resize step. even so, this only works if the >> filesystem you want to resize is the last partition in the virtual >> device >> > I never partition LVM "virtual device", I used different LV. So there > is no problem to resize any of this partitions. > About the additionnal step, I don''t really see where it is a problem.So to confirm, rather than making /dev/xenvg/domudisk and doing: disk = [''phy:/dev/xenvg/domudisk,xvda,w''] and partitioning /dev/xenvg/domudisk in the guest, you''d make (for example): /dev/xenvg/domudisk-root /dev/xenvg/domudisk-home /dev/xenvg/domudisk-swap and configure it like: disk = [ ''phy:/dev/xenvg/domudisk-root,xvda1,w'', ''phy:/dev/xenvg/domudisk-home,xvda2,w'', ''phy:/dev/xenvg/domudisk-swap,xvda3,w'' ] Is that right? The idea had crossed my mind, but all the tools seemed to want to do it the other way. Regards, Jeff _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
David Morris wrote:> > >> -----Original Message----- >> From: Thomas Goirand [mailto:thomas@goirand.fr] >> Sent: Monday, June 08, 2009 2:15 PM >> Cc: xen-users@lists.xensource.com >> Subject: Re: [Xen-users] Making system templates >> >> The best way ever is... to NOT use templates or images. >> Templates gets outdated, and soon have loads of package to >> upgrade. The best way (whenever possible, this is not always >> the case) is to use tools to pull and setup packages out of >> FTP repositories. > > That is not always true ... Templates provide stability in terms of the > environment. It is often desireable to reproduce consistent > configurations so as to avoid unexpected changes.Oh, you are the first guy I met that is telling me that Debian evolves too fast then! :) I supposed by the way that you have noticed we support both types... Thomas _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> -----Original Message----- > From: Thomas Goirand [mailto:thomas@goirand.fr] > Sent: Monday, June 08, 2009 6:37 PM > Cc: xen-users@lists.xensource.com > Subject: Re: [Xen-users] Making system templates > > David Morris wrote: > > > > > >> -----Original Message----- > >> From: Thomas Goirand [mailto:thomas@goirand.fr] > >> Sent: Monday, June 08, 2009 2:15 PM > >> Cc: xen-users@lists.xensource.com > >> Subject: Re: [Xen-users] Making system templates > >> > >> The best way ever is... to NOT use templates or images. > >> Templates gets outdated, and soon have loads of package to > upgrade. > >> The best way (whenever possible, this is not always the > case) is to > >> use tools to pull and setup packages out of FTP repositories. > > > > That is not always true ... Templates provide stability in terms of > > the environment. It is often desireable to reproduce consistent > > configurations so as to avoid unexpected changes. > > Oh, you are the first guy I met that is telling me that > Debian evolves too fast then! :)Too fast or too slow ... Unexpected changes introduced into an environment can cause grief. I''m only challenging the assertion that "The best way" is to create each new machine on the fly. Whether or not it is best depends on organizational needs.> > I supposed by the way that you have noticed we support both types... > > Thomas > > _______________________________________________ > 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
Certainly it''s hard to claim that any one way is always ''best''. Ultimately, being closer to current is generally better than being further away from it - not that this is exactly news to anyone. My solution is very close to Thomas'', except that I debootstrap from a local mirror which is updated only after the upstream packages are tested against common configurations. That way, I can use debootstrap to get my definition of ''current-stable'', while simultaneously being reassured that the packages I am pulling down are of a version I have tested and verified to work. This is part of my upgrade cycle, so if I add a tenth machine to a cluster using the debootstrap method, I am pulling down the same version of packages as those already on the production machines Thank You, Nathan Eisenberg Sr. Systems Administrator Atlas Networks, LLC Atlas Networks is an Atlas Accelerator Company -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of David Morris Sent: Monday, June 08, 2009 7:29 PM Cc: xen-users@lists.xensource.com Subject: RE: [Xen-users] Making system templates> -----Original Message----- > From: Thomas Goirand [mailto:thomas@goirand.fr] > Sent: Monday, June 08, 2009 6:37 PM > Cc: xen-users@lists.xensource.com > Subject: Re: [Xen-users] Making system templates > > David Morris wrote: > > > > > >> -----Original Message----- > >> From: Thomas Goirand [mailto:thomas@goirand.fr] > >> Sent: Monday, June 08, 2009 2:15 PM > >> Cc: xen-users@lists.xensource.com > >> Subject: Re: [Xen-users] Making system templates > >> > >> The best way ever is... to NOT use templates or images. > >> Templates gets outdated, and soon have loads of package to > upgrade. > >> The best way (whenever possible, this is not always the > case) is to > >> use tools to pull and setup packages out of FTP repositories. > > > > That is not always true ... Templates provide stability in terms of > > the environment. It is often desireable to reproduce consistent > > configurations so as to avoid unexpected changes. > > Oh, you are the first guy I met that is telling me that > Debian evolves too fast then! :)Too fast or too slow ... Unexpected changes introduced into an environment can cause grief. I''m only challenging the assertion that "The best way" is to create each new machine on the fly. Whether or not it is best depends on organizational needs.> > I supposed by the way that you have noticed we support both types... > > Thomas > > _______________________________________________ > 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 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Jun 9, 2009 at 4:14 AM, Thomas Goirand<thomas@goirand.fr> wrote:>> I am wanting to set up a bunch of system templates for my Xen servers, >> to save me from running some standard package installs and >> configuration.> The best way ever is... to NOT use templates or images. Templates gets > outdated, and soon have loads of package to upgrade. The best way > (whenever possible, this is not always the case) is to use tools to pull > and setup packages out of FTP repositories. > > In Debian, there is "debootstrap" to build a debian (and many other > debian based systems) OS in a chroot. There is also yum to bootstrap RPM > based distributions (previously we were using rpmstrap, but it''s not a > good idea, it gets outdated so fast...).I work mainly with RHEL, and while it''s possible to use kickstart or "yum --installroot", it''s still significantly slower compared to using tar.gz templates. So what I did is I maintain a set of templates which are updated regularly using crontab (extract, yum-update, repack). This way I get up-to-date template which allows domU deployment in 5 minutes or less. -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Jun 9, 2009 at 7:08 AM, Jeff Williams<jeffw@globaldial.com> wrote:> So to confirm, rather than making /dev/xenvg/domudisk and doing: > > disk = [''phy:/dev/xenvg/domudisk,xvda,w''] > > and partitioning /dev/xenvg/domudisk in the guest, you''d make (for example): > > /dev/xenvg/domudisk-root > /dev/xenvg/domudisk-home > /dev/xenvg/domudisk-swap > > and configure it like: > > disk = [ > ''phy:/dev/xenvg/domudisk-root,xvda1,w'', > ''phy:/dev/xenvg/domudisk-home,xvda2,w'', > ''phy:/dev/xenvg/domudisk-swap,xvda3,w'' > ] > > Is that right?That''s what I do with templates-based installation.> The idea had crossed my mind, but all the tools seemed to > want to do it the other way.For some tools (like virt-manager), yes. Other tools (like eucalyptus) seems to use tar.gz. images. Personally I don''t use provisioning tools, but rather doing it all manually (lvcreate, mkfs, tar xfvz, etc.). -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I use "xen-tools", which works like this yes. Olivier Jeff Williams a écrit :> On 08/06/09 23:02, Olivier B. wrote: >> Javier Guerra a écrit : >>> On Mon, Jun 8, 2009 at 9:42 AM, Olivier B.<xen.list@daevel.fr> wrote: >>> >>>> about LVM : one the big advantages of LVM is the resize... >>>> "lvresize" on >>>> Dom0, then (for ext3/ext4) resize2fs in DomU. >>>> >>> >>> add a partition resize step. even so, this only works if the >>> filesystem you want to resize is the last partition in the virtual >>> device >>> >> I never partition LVM "virtual device", I used different LV. So there >> is no problem to resize any of this partitions. >> About the additionnal step, I don''t really see where it is a problem. > So to confirm, rather than making /dev/xenvg/domudisk and doing: > > disk = [''phy:/dev/xenvg/domudisk,xvda,w''] > > and partitioning /dev/xenvg/domudisk in the guest, you''d make (for > example): > > /dev/xenvg/domudisk-root > /dev/xenvg/domudisk-home > /dev/xenvg/domudisk-swap > > and configure it like: > > disk = [ > ''phy:/dev/xenvg/domudisk-root,xvda1,w'', > ''phy:/dev/xenvg/domudisk-home,xvda2,w'', > ''phy:/dev/xenvg/domudisk-swap,xvda3,w'' > ] > > Is that right? The idea had crossed my mind, but all the tools seemed > to want to do it the other way. > > Regards, > Jeff > > _______________________________________________ > 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 08/06/09 22:42, Olivier B. wrote:> Hi, > > about LVM : one the big advantages of LVM is the resize... "lvresize" > on Dom0, then (for ext3/ext4) resize2fs in DomU.This is good for normal lvs, but it seems that snapshots will always have the same size as the original disk (which makes some sense). But this means for me that I can''t use lvm snapshot to provision a new server from a lv template if the disk size is possibly going to change at sometime in the future. Regards, Jeff _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I suggest the virt-clone method since I use it for cloning windows and
linux. It is a perfect tool. I created a template windows and linux
setup. First, shut the main copy, after virt-clone, change the temp name
and IP and use it.
* vserver01 template copy to vserver0X example,
* *virt-clone*
* (file path)? /var/lib/xen/images/*xserver0X.img*
* the name of the original virtual machine? *xserver01*
* the name for the cloned virtual machine? *xserver0X*
* Cloning from /var/lib/xen/images/*xserver01*.img to
/var/lib/xen/images/*xserver0X*.img
* Change IP address
* Change name if Windows as xserver0X
Jeff Williams wrote:> On 08/06/09 23:02, Olivier B. wrote:
>> Javier Guerra a écrit :
>>> On Mon, Jun 8, 2009 at 9:42 AM, Olivier
B.<xen.list@daevel.fr> wrote:
>>>
>>>> about LVM : one the big advantages of LVM is the resize...
>>>> "lvresize" on
>>>> Dom0, then (for ext3/ext4) resize2fs in DomU.
>>>>
>>>
>>> add a partition resize step. even so, this only works if the
>>> filesystem you want to resize is the last partition in the virtual
>>> device
>>>
>> I never partition LVM "virtual device", I used different LV.
So there
>> is no problem to resize any of this partitions.
>> About the additionnal step, I don''t really see where it is a
problem.
> So to confirm, rather than making /dev/xenvg/domudisk and doing:
>
> disk = [''phy:/dev/xenvg/domudisk,xvda,w'']
>
> and partitioning /dev/xenvg/domudisk in the guest, you''d make (for
> example):
>
> /dev/xenvg/domudisk-root
> /dev/xenvg/domudisk-home
> /dev/xenvg/domudisk-swap
>
> and configure it like:
>
> disk = [
> ''phy:/dev/xenvg/domudisk-root,xvda1,w'',
> ''phy:/dev/xenvg/domudisk-home,xvda2,w'',
> ''phy:/dev/xenvg/domudisk-swap,xvda3,w''
> ]
>
> Is that right? The idea had crossed my mind, but all the tools seemed
> to want to do it the other way.
>
> Regards,
> Jeff
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
--
Umut Arus
Sabancı Üniversitesi - Bilgi Teknolojisi
http://www.sabanciuniv.edu
Tel: (+90 216) 483 9172
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
On 09/06/09 12:04, Fajar A. Nugraha wrote:> On Tue, Jun 9, 2009 at 7:08 AM, Jeff Williams<jeffw@globaldial.com> wrote: > >> So to confirm, rather than making /dev/xenvg/domudisk and doing: >> >> disk = [''phy:/dev/xenvg/domudisk,xvda,w''] >> >> and partitioning /dev/xenvg/domudisk in the guest, you''d make (for example): >> >> /dev/xenvg/domudisk-root >> /dev/xenvg/domudisk-home >> /dev/xenvg/domudisk-swap >> >> and configure it like: >> >> disk = [ >> ''phy:/dev/xenvg/domudisk-root,xvda1,w'', >> ''phy:/dev/xenvg/domudisk-home,xvda2,w'', >> ''phy:/dev/xenvg/domudisk-swap,xvda3,w'' >> ] >> >> Is that right? >> > > That''s what I do with templates-based installation. > > >> The idea had crossed my mind, but all the tools seemed to >> want to do it the other way. >> > > For some tools (like virt-manager), yes. Other tools (like eucalyptus) > seems to use tar.gz. images. > Personally I don''t use provisioning tools, but rather doing it all > manually (lvcreate, mkfs, tar xfvz, etc.). > >Interesting. So what I have so far is: - no-one seems to use lvm snap shot for provisioning as I guess it is too inflexible. - no-one seems to use dd either - no-one seems to use virt-clone either - most people seem to do one of: 1) Create the disks and file systems and do a file level copy of the template (tar seems to be preferred over cpio) 2) Use some sort of bootstrap procedure to do a network install of the OS, followed optionally by a start -up script which installs and configures required packages. Also interesting was that a few people are doing "partitioning" at the Dom0/LVM level with a separate LV per partition and passing those partitions through to the DomU rather than passing an LV as a disk and partitioning at the DomU level. Thanks for all the input. At this point I''ll be using templates with a file level copy and a separate LV per partition to make resize easier. Regards, Jeff _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I use DD :) I use LVM partitioning at Dom 0 level with DRBD and pass each VM a partition as a disk (For DBs I have faster discs for DB storage so I pass two disks to the PV, One for boot and one for DB storage). I specify a specific MAC in the config file, this way when the cloned machine starts it won''t apply an previous IP addresses the image had to the differing MAC. Works fine. Resizing seems to work OK, I just use LVM on DOM0 and then LVM on the DOMU. Rob -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Jeff Williams Sent: 09 June 2009 06:56 To: Fajar A. Nugraha Cc: Xen User-List Subject: Re: [Xen-users] Making system templates On 09/06/09 12:04, Fajar A. Nugraha wrote:> On Tue, Jun 9, 2009 at 7:08 AM, Jeff Williams<jeffw@globaldial.com>wrote:> >> So to confirm, rather than making /dev/xenvg/domudisk and doing: >> >> disk = [''phy:/dev/xenvg/domudisk,xvda,w''] >> >> and partitioning /dev/xenvg/domudisk in the guest, you''d make (forexample):>> >> /dev/xenvg/domudisk-root >> /dev/xenvg/domudisk-home >> /dev/xenvg/domudisk-swap >> >> and configure it like: >> >> disk = [ >> ''phy:/dev/xenvg/domudisk-root,xvda1,w'', >> ''phy:/dev/xenvg/domudisk-home,xvda2,w'', >> ''phy:/dev/xenvg/domudisk-swap,xvda3,w'' >> ] >> >> Is that right? >> > > That''s what I do with templates-based installation. > > >> The idea had crossed my mind, but all the tools seemed to >> want to do it the other way. >> > > For some tools (like virt-manager), yes. Other tools (like eucalyptus) > seems to use tar.gz. images. > Personally I don''t use provisioning tools, but rather doing it all > manually (lvcreate, mkfs, tar xfvz, etc.). > >Interesting. So what I have so far is: - no-one seems to use lvm snap shot for provisioning as I guess it is too inflexible. - no-one seems to use dd either - no-one seems to use virt-clone either - most people seem to do one of: 1) Create the disks and file systems and do a file level copy of the template (tar seems to be preferred over cpio) 2) Use some sort of bootstrap procedure to do a network install of the OS, followed optionally by a start -up script which installs and configures required packages. Also interesting was that a few people are doing "partitioning" at the Dom0/LVM level with a separate LV per partition and passing those partitions through to the DomU rather than passing an LV as a disk and partitioning at the DomU level. Thanks for all the input. At this point I''ll be using templates with a file level copy and a separate LV per partition to make resize easier. Regards, Jeff _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users The SAQ Group Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ SAQ is the trading name of SEMTEC Limited. Registered in England & Wales Company Number: 06481952 http://www.saqnet.co.uk AS29219 SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business. Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support. ISPA Member _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
David Morris wrote:> Too fast or too slow ... Unexpected changes introduced into an > environment can cause grief. I''m only challenging the assertion that > "The best way" is to create each new machine on the fly. Whether or not > it is best depends on organizational needs.Well, to me, the "best way" to use, is the one of the distribution. That is: debootstrap when setting-up a Debian, and yum when setting-up a CentOS. These 2 are used by them, so I don''t see why they would fail. Plus with years of experience: IT IS reliable. Thomas _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nathan Eisenberg wrote:> My solution is very close to Thomas'', except that I debootstrap from a local mirror which is updated only after the upstream packages are tested against common configurations. > > That way, I can use debootstrap to get my definition of ''current-stable'', while simultaneously being reassured that the packages I am pulling down are of a version I have tested and verified to work. This is part of my upgrade cycle, so if I add a tenth machine to a cluster using the debootstrap method, I am pulling down the same version of packages as those already on the production machinesHaving a package that changes behavior in the Stable version of Debian shall NEVER happen. If so, then you can file a bug in the tracker. But I never saw this happening over the last 5 years. We simply use approx to do package download caching. This is really enough, no need to manually create your own set of package. You are being over paranoid here. Thomas _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
The maintenance cycle is frequent and requires a very small amount of work to maintain (it''s probably entirely automatable); and in exchange, I gain the ability to state that we independently test upstream patches before applying them. Now, whether this is technically necessary is a point I''ll happily concede. Debian-Stable is so named because only very well tested, stable changes are committed to it. However, I manage OS''s other than Debian (CentOS, Gentoo, Windows, etc), and it seems logical to apply the same general process to every OS - as they are not all so well tested before patches are released - than to have an exception for Debian based solely on the fact that you and I have never had a problem patching Debian. Plus, having a local repository is very nice. Best Regards Nathan Eisenberg Sr. Systems Administrator Atlas Networks, LLC support@atlasnetworks.us http://support.atlasnetworks.us/portal -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Thomas Goirand Sent: Tuesday, June 09, 2009 10:16 PM To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Making system templates Nathan Eisenberg wrote:> My solution is very close to Thomas'', except that I debootstrap from a local mirror which is updated only after the upstream packages are tested against common configurations. > > That way, I can use debootstrap to get my definition of ''current-stable'', while simultaneously being reassured that the packages I am pulling down are of a version I have tested and verified to work. This is part of my upgrade cycle, so if I add a tenth machine to a cluster using the debootstrap method, I am pulling down the same version of packages as those already on the production machinesHaving a package that changes behavior in the Stable version of Debian shall NEVER happen. If so, then you can file a bug in the tracker. But I never saw this happening over the last 5 years. We simply use approx to do package download caching. This is really enough, no need to manually create your own set of package. You are being over paranoid here. Thomas _______________________________________________ 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