1
edit
Changes
no edit summary
''The following text is from the September 18, 2007 discussion in #seneca.''
<pre width="120">
16:02 < bhearsum> so, this was originally going to be my system projects and as such I have a lot of documentation on it
16:02 < bhearsum> i sent it to dave and chris, did they forward it to you?
16:02 < jb> yeah, chris was talking about that
16:02 < jb> no, I've talked to chris about it but he didn't tell me anything about documentation
16:03 < jb> i figured i'd get that from you
16:03 < bhearsum> let me forward you that e-mail
16:03 < jb> janowikispambuchan@learn
16:03 < bhearsum> it's got mockups, use case descriptions, class diagrams, etc.
..
16:23 < jb> bhearsum: ok, I think i understand the purpose..
16:23 < jb> now, I assume xen has an api for doing all of this?
16:23 < jb> at least, the vm-related stuff
16:27 < bhearsum> jb: libvirt is what does all of that fancy stuff
16:27 < bhearsum> libvirt.org
16:27 < jb> ok, that's what i thought
16:27 < bhearsum> so, the frontend pretty much just makes calls to libvirt
..
16:34 <@ ctyler> jb: this is a two-step process
16:34 <@ ctyler> first, you need to build the machine image
16:34 <@ ctyler> then you need to use libvirt to manage the machine
16:35 <@ ctyler> by image, I mean a disk-in-a-file
16:36 < jb> are xen's images like vmware
16:36 <@ ctyler> pretty much
16:36 < jb> can they be mounted without running a vm?
16:36 < jb> i dont know of anything like that for vmware
16:36 <@ ctyler> not directly, because they are a disk image, not a filesystem image
16:37 <@ ctyler> but you can use tools such as losetup and kpartx to dig down to the filesystem and then mount it
16:37 < jb> so would building the image require booting the VM and somehow communicating with it? or is it simpler than that
16:37 < jb> ok, as i hoped
16:37 <@ ctyler> there are three ways to do this:
16:37 jb looks up losetup and kpartx :)
16:37 <@ ctyler> boot the VM and go through an install process
16:38 <@ ctyler> or use kpartx etc and build the image without starting the vm
16:38 <@ ctyler> or copy an existing image
16:38 <@ ctyler> the last one is fastest, especially if you use something like lvm snapshots to do it quickly
16:38 <@ ctyler> you could combine several "disks" for a single machine
16:38 <@ ctyler> one might have the os, the second the tools, the third the source tree
16:39 <@ ctyler> so you'd have pre-made images for all these and you just mix and match them
16:39 <@ ctyler> the vm would see them as /dev/hda, /dev/hdb, /dev/hdc (or three scsi disks)
16:40 < jb> ah i see, so no copying files to and fro like i was thinking
16:41 <@ ctyler> you can do it that way too -- start with a basic image of the OS pre-installed and then stuff it with the files you need
16:42 <@ ctyler> you'll probably want to read up on lvm snapshots too
16:42 < jb> yes, i was just going to say..
16:43 < jb> now, what's the difference between 2) and 3), i.e. " use kpartx etc and build the image" and "copy an existing image"
16:45 < jb> by 2) do you mean copy individual files to a single image, as I was suggesting, and by 3) meaning just mounting block devices?
16:46 <@ ctyler> for (2) you'd create the disk image in a file, then create the filesystem, then mount it, and use RPM or apt-get to populate that filesystem with selected packages
16:47 <@ ctyler> for (3) you'd copy existing pre-populated disk images, if necessary modifying a few files
16:47 < shaver> COW, baby
16:48 <@ ctyler> exactly, use the Linux LVM snapshot facility to create a copy-on-write snapshot
16:48 <@ ctyler> jb: you grok copy-on-write?
16:48 < jb> not quite, i'll read up on it
16:49 <@ ctyler> short version: you have a 1000-block filesystem, you want a copy
16:49 <@ ctyler> the OS sets up a "copy" but it actually uses the same 1000 blocks for the original and the copy
16:49 <@ ctyler> as soon as you try to write to the original or the copy, though, the OS make a copy of _just that block_
16:50 <@ ctyler> so if, in the end, you only change 10% of the blocks, then you only need 1010 blocks, not 2000
16:50 <@ ctyler> plus the COW "copy" gets set up in seconds instead of minutes
16:50 <@ ctyler> whoops, 1100 blocks not 1010
16:51 <@ ctyler> all the logic for that is already in the LVM layer
16:52 < jb> aha, so any of these VM permutations would really be on one of these COW "partitions(?)", taking up a trivial amount more space than the base config images, rather than duplicating them in >1GB files over and over?
16:52 < shaver> yeah
16:52 < shaver> until you want to upgrade the OS
16:52 < shaver> but don't worry about that part
16:53 <@ ctyler> now use multiple disks per virtual machine, one disk with the OS, one with the tools, one with a particular source version
16:53 <@ ctyler> mix & match to provision the machine in a few seconds
16:55 < jb> will the tools be that easily transplanted between OS's? i assume by tools we mean dev toolchain gcc/autoconf/etc
16:55 <@ ctyler> if you pick carefully, yes
16:56 <@ ctyler> but if you don't want to use different toolchain versions then you could use two disks: OS+toolchain, source
16:57 <@ ctyler> the other gotcha is preventing machine collisions, each VM will need a separate IP address (and, in the case of Windows systems, possibly a separate activation key, let's ignore Windows ftm)
16:57 <@ ctyler> you can reach into the disk image and configure a static IP
16:58 <@ ctyler> or, through libvirt, configure the MAC address
16:58 <@ ctyler> and tell the DHCP server which IP address to serve to that MAC
17:00 <@ ctyler> likewise with auth, you can reach into the image and configure an account for the user, or the images can be configured to authenticate with LDAP
17:01 < jb> ok, so each vm will need little tweaks to make them unique
17:02 <@ ctyler> or the unique info needs to come from external servers (DHCP, LDAP, ...)
17:02 < jb> right
17:03 < shaver> there are tools to help with it, too
17:03 < shaver> like bcfg2, I think
17:03 < shaver> or cfengine
17:04 < jb> ok, I'll leave it at that for now and let my brain settle around it
17:05 < jb> in the meantime, should I be tinkering with xen on my own machine/s, or does seneca/acs have some non-production servers i can experiment with?
17:05 <@ ctyler> actually the lanux stuff from 10thpower might fit in too
17:06 <@ ctyler> there are some clusters with vm capability at school
17:06 <@ ctyler> but it's worth trying this out on your own box
17:06 <@ ctyler> do you have a machine with hardware virt capability? (Intel core2 or AMD x2?)
17:06 < jb> yeah, a laptop and a desktop
17:07 < jb> i specced out my thinkpad to make sure it had intel vt, noone at lenovo/ibm could tell me
17:07 <@ ctyler> perfect, then you have a lot more options
17:08 <@ ctyler> you can use Xen paravirt or full-virt, or kvm, or any of the newer toys
17:08 <@ ctyler> kvm is pretty nice, because the vm runs as a regular process, and you can see it with 'top', kill it, etc.
17:09 < jb> do any distros come with xen 'well integrated'?
17:09 <@ ctyler> F7 has Xen and KVM
17:09 < jb> i've played with it, but only in gentoo, and not really (i booted a domU but never got around to making a vm)
17:09 < jb> and i don't want to do this in gentoo, god save me
17:10 < jb> ok i'll look into it, get Fedora on my laptop, try getting a vm installed/booting, then start playing with libvirt
17:11 < jb> bhearsum/ctyler: do you mind if i a) put this irc log on the wiki, b) put the .tar.gz with the mockups/usecases on the wiki?
17:11 <@ ctyler> a) is ok on my end
..
17:29 < bhearsum> jb: no objections here
</pre>
<pre width="120">
16:02 < bhearsum> so, this was originally going to be my system projects and as such I have a lot of documentation on it
16:02 < bhearsum> i sent it to dave and chris, did they forward it to you?
16:02 < jb> yeah, chris was talking about that
16:02 < jb> no, I've talked to chris about it but he didn't tell me anything about documentation
16:03 < jb> i figured i'd get that from you
16:03 < bhearsum> let me forward you that e-mail
16:03 < jb> janowikispambuchan@learn
16:03 < bhearsum> it's got mockups, use case descriptions, class diagrams, etc.
..
16:23 < jb> bhearsum: ok, I think i understand the purpose..
16:23 < jb> now, I assume xen has an api for doing all of this?
16:23 < jb> at least, the vm-related stuff
16:27 < bhearsum> jb: libvirt is what does all of that fancy stuff
16:27 < bhearsum> libvirt.org
16:27 < jb> ok, that's what i thought
16:27 < bhearsum> so, the frontend pretty much just makes calls to libvirt
..
16:34 <@ ctyler> jb: this is a two-step process
16:34 <@ ctyler> first, you need to build the machine image
16:34 <@ ctyler> then you need to use libvirt to manage the machine
16:35 <@ ctyler> by image, I mean a disk-in-a-file
16:36 < jb> are xen's images like vmware
16:36 <@ ctyler> pretty much
16:36 < jb> can they be mounted without running a vm?
16:36 < jb> i dont know of anything like that for vmware
16:36 <@ ctyler> not directly, because they are a disk image, not a filesystem image
16:37 <@ ctyler> but you can use tools such as losetup and kpartx to dig down to the filesystem and then mount it
16:37 < jb> so would building the image require booting the VM and somehow communicating with it? or is it simpler than that
16:37 < jb> ok, as i hoped
16:37 <@ ctyler> there are three ways to do this:
16:37 jb looks up losetup and kpartx :)
16:37 <@ ctyler> boot the VM and go through an install process
16:38 <@ ctyler> or use kpartx etc and build the image without starting the vm
16:38 <@ ctyler> or copy an existing image
16:38 <@ ctyler> the last one is fastest, especially if you use something like lvm snapshots to do it quickly
16:38 <@ ctyler> you could combine several "disks" for a single machine
16:38 <@ ctyler> one might have the os, the second the tools, the third the source tree
16:39 <@ ctyler> so you'd have pre-made images for all these and you just mix and match them
16:39 <@ ctyler> the vm would see them as /dev/hda, /dev/hdb, /dev/hdc (or three scsi disks)
16:40 < jb> ah i see, so no copying files to and fro like i was thinking
16:41 <@ ctyler> you can do it that way too -- start with a basic image of the OS pre-installed and then stuff it with the files you need
16:42 <@ ctyler> you'll probably want to read up on lvm snapshots too
16:42 < jb> yes, i was just going to say..
16:43 < jb> now, what's the difference between 2) and 3), i.e. " use kpartx etc and build the image" and "copy an existing image"
16:45 < jb> by 2) do you mean copy individual files to a single image, as I was suggesting, and by 3) meaning just mounting block devices?
16:46 <@ ctyler> for (2) you'd create the disk image in a file, then create the filesystem, then mount it, and use RPM or apt-get to populate that filesystem with selected packages
16:47 <@ ctyler> for (3) you'd copy existing pre-populated disk images, if necessary modifying a few files
16:47 < shaver> COW, baby
16:48 <@ ctyler> exactly, use the Linux LVM snapshot facility to create a copy-on-write snapshot
16:48 <@ ctyler> jb: you grok copy-on-write?
16:48 < jb> not quite, i'll read up on it
16:49 <@ ctyler> short version: you have a 1000-block filesystem, you want a copy
16:49 <@ ctyler> the OS sets up a "copy" but it actually uses the same 1000 blocks for the original and the copy
16:49 <@ ctyler> as soon as you try to write to the original or the copy, though, the OS make a copy of _just that block_
16:50 <@ ctyler> so if, in the end, you only change 10% of the blocks, then you only need 1010 blocks, not 2000
16:50 <@ ctyler> plus the COW "copy" gets set up in seconds instead of minutes
16:50 <@ ctyler> whoops, 1100 blocks not 1010
16:51 <@ ctyler> all the logic for that is already in the LVM layer
16:52 < jb> aha, so any of these VM permutations would really be on one of these COW "partitions(?)", taking up a trivial amount more space than the base config images, rather than duplicating them in >1GB files over and over?
16:52 < shaver> yeah
16:52 < shaver> until you want to upgrade the OS
16:52 < shaver> but don't worry about that part
16:53 <@ ctyler> now use multiple disks per virtual machine, one disk with the OS, one with the tools, one with a particular source version
16:53 <@ ctyler> mix & match to provision the machine in a few seconds
16:55 < jb> will the tools be that easily transplanted between OS's? i assume by tools we mean dev toolchain gcc/autoconf/etc
16:55 <@ ctyler> if you pick carefully, yes
16:56 <@ ctyler> but if you don't want to use different toolchain versions then you could use two disks: OS+toolchain, source
16:57 <@ ctyler> the other gotcha is preventing machine collisions, each VM will need a separate IP address (and, in the case of Windows systems, possibly a separate activation key, let's ignore Windows ftm)
16:57 <@ ctyler> you can reach into the disk image and configure a static IP
16:58 <@ ctyler> or, through libvirt, configure the MAC address
16:58 <@ ctyler> and tell the DHCP server which IP address to serve to that MAC
17:00 <@ ctyler> likewise with auth, you can reach into the image and configure an account for the user, or the images can be configured to authenticate with LDAP
17:01 < jb> ok, so each vm will need little tweaks to make them unique
17:02 <@ ctyler> or the unique info needs to come from external servers (DHCP, LDAP, ...)
17:02 < jb> right
17:03 < shaver> there are tools to help with it, too
17:03 < shaver> like bcfg2, I think
17:03 < shaver> or cfengine
17:04 < jb> ok, I'll leave it at that for now and let my brain settle around it
17:05 < jb> in the meantime, should I be tinkering with xen on my own machine/s, or does seneca/acs have some non-production servers i can experiment with?
17:05 <@ ctyler> actually the lanux stuff from 10thpower might fit in too
17:06 <@ ctyler> there are some clusters with vm capability at school
17:06 <@ ctyler> but it's worth trying this out on your own box
17:06 <@ ctyler> do you have a machine with hardware virt capability? (Intel core2 or AMD x2?)
17:06 < jb> yeah, a laptop and a desktop
17:07 < jb> i specced out my thinkpad to make sure it had intel vt, noone at lenovo/ibm could tell me
17:07 <@ ctyler> perfect, then you have a lot more options
17:08 <@ ctyler> you can use Xen paravirt or full-virt, or kvm, or any of the newer toys
17:08 <@ ctyler> kvm is pretty nice, because the vm runs as a regular process, and you can see it with 'top', kill it, etc.
17:09 < jb> do any distros come with xen 'well integrated'?
17:09 <@ ctyler> F7 has Xen and KVM
17:09 < jb> i've played with it, but only in gentoo, and not really (i booted a domU but never got around to making a vm)
17:09 < jb> and i don't want to do this in gentoo, god save me
17:10 < jb> ok i'll look into it, get Fedora on my laptop, try getting a vm installed/booting, then start playing with libvirt
17:11 < jb> bhearsum/ctyler: do you mind if i a) put this irc log on the wiki, b) put the .tar.gz with the mockups/usecases on the wiki?
17:11 <@ ctyler> a) is ok on my end
..
17:29 < bhearsum> jb: no objections here
</pre>
