Web-based Virtual Machine Management - Preliminary IRC Discussion

The following text is from the September 18, 2007 discussion in #seneca.

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