[colug-432] virtualization, clouds, and infrastructure

[Scott McCarty]

On Thu, Dec 16, 2010 at 2:27 PM, Richard Troth <rmt at casita.net> wrote:

> Oh goodie ... my FAVorite topic.
> It's something well worth discussing because the industry is mixed up
> about managing V12N.  Vendors want to sell you tools which do *some*
> things but not enough and then also want to play the lock-in game.  On
> the other extreme is OpenVirt, (not a vendor, but a standard) which
> covers all the bases, in a vendor-neutral way, but tries to boil the
> ocean.
>
> First thing:  be careful to distinguish between resource allocation
> (creating and managing virtual machines, including cloning) and
> software provisioning (yum, zypper, apt-get).  A lot of V12N
> manglement solutions (OVirt) try to do too much and wind up not doing
> any of it well.  If you have a working config database, it's a good
> idea to hold information about physical machines and virtual machines
> in the same place.  If you're going with an open solution (Xen or KVM)
> you can wire that in with your CMDB.  If you go with a vended solution
> (VMware, Citrix) you will have to pressure them to get config
> transparency.  Good luck there.
>

On the devops toolchain mailing list CMDBs came up a while back and if I
remember right, it is pretty hard to find a good standalone solution that
has an API and is open source. What are you using?


>
> Second thing:  avoid partitioning virtual disks.  If the hypervisor
> exposes the virtual disks as files (to the host environment) and you
> DON'T partition them (in the guests) then you can mount them  '-o
> loop'  and fix things ... even play 'chroot' if you need.  All kinds
> of good things happen when you remove the partitioning layer.  If you
> need something that works like partitioning, go LVM.  It's better
> anyway.  (Any virtual disk used as a PV will not be as readily usable,
> I am aware, but you should avoid partitioning PV containers too.)  I
> run LVM on the host but not on the guests.  GRUB fights me on this.
> [sigh]
>

I think libguestfs and guestfish solves most of this. You can even modify a
file live if you are super careful.

http://libguestfs.org/recipes.html#editgrub


>
> Angelo is spot-on:  cold migration is easy (on the same V12N tech).
> Thankfully, Xen and KVM (and VMware) all use plain text to define a
> virtual machine.  I presume VMware still does.  They used to.  (But I
> haven't gotten my fingers into ESX4.)  You can copy it.  You can also
> eyeball it so that you know what pieces the hypervisor is pointing to.
>  You do not need a costly tool for cold migration.  You just need to
> properly inventory the pieces.
>
> I have heard others bemoan the on-again / off-again SNMP support in
> VMware.  Only way they'll get it right is customer pressure.  Demand
> it.  Heck, demand a decent CLI for that matter.  (Xen and KVM have
> solid CLI.  VMware never has.)
>

Agreed


>
> -- R;   <><
>
>
>
>
>
> On Wed, Dec 15, 2010 at 15:38, Scott Merrill <skippy at skippy.net> wrote:
> > The discussion on Hadoop is interesting, and I do hope a presentation
> > or two results. If I can help coordinate, please let me know.
> >
> > On a similar vein, how are you folks handling the management of
> > virtualized servers in your environments? It's trivial with KVM and
> > similar tools to run a couple of virtual instances on a single
> > physical box. It's not so trivial to run those virtual instances in a
> > highly available fashion across a cluster of physical machines.
> >
> > VMware makes a pretty penny with VMotion, Storage VMotion, and similar
> > technology, and by providing a nice management interface to this
> > issue. Alas, those management tools are Windows-only.
> >
> > Red Hat has a product (by way of acquisition) called Red Hat
> > Enterprise Virtualization Manager (RHEV-M). This, too, is currently a
> > Windows-only solution.
> >
> > I've looked at a lot of IaaS ("Infrastructure as a Service"), elastic
> > cloud, and similar solutions in the last couple of days. None of these
> > are what I want, particularly. I'm not looking to sell or chargeback
> > for our infrastructure, and I'm not looking for variable ad-hoc
> > resource allocation.
> >
> > What I want is a reliable means of keeping a number of virtual servers
> > up and accessible across a number of physical boxes, such that any
> > physical box can be taken offline for maintenance (for example,
> > rolling reboots across physical hosts).
> >
> > luci and ricci are are start, but they're nowhere near as end user
> > friendly as the VMware tools. This is not a big concern for me, but it
> > is an issue for those with whom I work, who might be expected to
> > provide on-demand support if I get hit by a bus (or am just home
> > sick).
> >
> > Anyone else tackling these issues? Would you care to present to COLUG
> > on how you're managing things?
> >
> > Thanks,
> > Scott
> > _______________________________________________
> > colug-432 mailing list
> > colug-432 at colug.net
> > http://lists.colug.net/mailman/listinfo/colug-432
> >
>
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20101216/a0c0749a/attachment.html