Hi, D'ar lun 04 a viz C'hwevrer 2013 e 07 eur 29, « Carsten Haitzler » he deus skrivet : > On Wed, 30 Jan 2013 12:32:23 +0100 Bertrand Jacquin <be...@meleeweb.net> said: > > while this would be nice... we don't even have our "home turf" vm's all set up > yet. > > 1. we need to drop lvm. qcow+file images. it just makes migrating vms > elsehwere > a lot harder if you put them on lvm requiring extra levels of special setup to > use them.
I do agree that qcow can be more easy, but here is the trick. We have
two cases : VM migration, VM duplication for tests purpose.
** VM duplication :
Using libvirt to migrate need one of Fibre Channel, NFS, GFS or
iSCSI between the two hosts. We don't have it. I asked to OSUOSL what is
their internal process so maybe we can use it in the future.
For the moment there is nothing, so here is the process :
= Using LVM :
pv /dev/vg-data/e5-template1-sys | ssh osuosl dd of=/somewhere/e5-t1-sys.img
<repeat for each disk>
= Using qcow :
scp /somewhere/e5-template1-sys.img osuosl:/somewhere
<repeat for each disk>
So here it's the same and not so much complicated for one way or one
other.
** Dump to test purpose
That's already what we did with Tom and Dan needed a fresh VM :
pv /dev/vg-data/e5-template1-sys | xz -f | dd of=/root/e5-template1-sys.img.xz
In all case, the source file is just different, so it's not higly more
complicated, it's the same.
Using FS over FS in not really efficace, plus, you need to care of the
multiple sync that append on the VM FS, on the host FS, on the host
RAID, on the host disks. Using LVM, there is one less layer.
Also, all resize feature etc are still available.
I do think performance is a criteria as we can observe on e2 for now. We
should avoid to reproduce a such situation at the very begenning to not
be surprise in some times.
Also, yes we have a lot of RAM and CPU on e5, that's really fine. But
I/O are absolutely not better with a lot of RAM or CPU.
> 2. nfs homedirs are a no-go. homedirs must/should be local to the vm fs image.
> making them nfs makes them non-portable. the whole POINT of using qemu/kvm in
> the first place is, that if we get overloaded, or if e5 goes down, or whatever
> we can TRIVALLY just move any vm over to osuosl's vm cluster system and
> re-point dns and presto... it works. this is WHY we want a SIMPLE setup. not
> complex. SIMPLE.
Yep ! NFS is here to speed up thing for now, it's temporary and will not
stay. Never wanted to.
> 3. firewall needs to go - NAT is enough.
NAT is not firewalling, hope we agree on this.
> firewall just wastes peoples time
> debugging services.
We should not have to debug anything when thing are up, when we deploy
new since I agree, it's normal. And this does not happend so often.
> in all the years e1/e2 have been up we have nver needed or
> uses a fw.
And for 4 years, MySQL has been opened to whole internet. This just
prevent mistakes.
> if someone "breaks in" and then can "get data out"... WHO CARES...
> we arent hiding secret data! this is not a paranoid corporate system.
I can be really more paranoid than that ;)
> if they
> broke in and start modifying our git repos and then people download src with
> trojans in it.. thats bad.. but a fw wont stop that... and tbh... we havent
> had
> this problem before (i know there is a 1st time), and if we do. thats WHY we
> have vm filesystem images and qcoq deltas/backups
I also do FS backup with delta on my own.
> we can just pull out of cold
> storage. with qcow we can keep fs DELTAS offline "at home" trivially by just
> scping a qcow snapshot (or series) and simply upload any compromised one and
> restart from there. enough devs have home storage to keep enough of these
> images copied and safe in case this happens.
> :)
>
> > Hi,
> >
> > For e5 buildbot/whatever we will need different OS and architecture to
> > test. So if some volunteer are free to build some, we can gladly host
> > them.
> >
> > Needed OS :
> >
> > - Windows XP x86
> > - Windows XP x86_64
> > - Windows Vista x86_64
> > - Windows 7 x86_64
> > - Windows 8 x86_64
> >
> > (maybe more declination are needed ?)
> >
> > - Mac OS X Snow Leopard
> > - Mac OS X Lion
> > - Mac OS X Mountain Lion
> >
> > - FreeBSD 8
> > - FreeBSD 9
> >
> > - NetBSD 4.0 (still supported)
> > - NetBSD 6.0 (still supported)
> > - NetBSD 6.0
> >
> > - OpenBSD 5.2
> >
> > - ?? Other, and maybe more declination on previous list
> >
> > Here are characteristics :
> >
> > - More the system is light, faster we can transfer it
> > - dd if=/dev/zero of=/device at first
> > - Make the image available as a disk gzip/xz format (as main content will
> > be unused space defined with zeros previously)
> > - Use virtIO for network, disk and console
> > - kernel parameters:
> > panic=5 clocksource=kvm-clock console=tty0 console=ttyS0,115200
> > - 1 network interface with DHCP
> > - syslog everything to host: log.e5 (I can send you a syslog-ng conf if
> > necessery)
> > - smtp relay: smtp.e5 (I can send you a exim config)
> > - minimal install
> > - watchdog (wdd prefered http://linux.exosec.net/watchdog/daemon/)
> > - necessary packages
> > - snmpd
> > - acpid
> >
> > Thanks,
> >
> > --
> > Beber
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com
>
--
Beber
pgpaGWCPRMP8d.pgp
Description: PGP signature
------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
