[PVE-User] First feeling about VE...

[Gilberto Nunes]

Hi Jeff...
Can you point some docs to do this hacking...??? 
Thanks

Em Qui, 2009-08-20 às 14:12 -0400, Jeff Saxe escreveu:

> Careful evaluating and recommending solutions; there are a number of
> components here, and they can be used for different purposes, but you
> want to know what you're doing. In my opinion...
> 
> 
> 
>       * The basic Proxmox VE (up to v. 1.3) can do a very nice, simple
>         job of virtualization, including moving VM's "rather quickly"
>         although not instantaneously between two servers that are
>         right next to each other on the LAN. For a system with a total
>         software license cost of zero, Martin and Dieter and their
>         buddies have produced an amazing, decently polished,
>         easy-to-use system, with remarkable capabilities and with very
>         low hardware requirements. They are to be commended, and I
>         continue to push within my employer to use this system in
>         production and to donate to this fantastic project.
>       * With a little bit of hacking under the table, the current 1.3
>         version can be reconstructed on top of DRBD storage (I
>         recently did this in a lab). However, this should not be
>         thought of as a way to make VM migration faster. Migrating
>         VM's in PVE involves two servers, with no shared storage, each
>         handling its own block of disk, and
>         copying-and-then-safely-deleting the VM storage and machine
>         state from one server to the other. But the network bandwidth
>         between the two nodes doesn't much matter until you want to
>         move a VM -- it's not used continuously, but only during a
>         migration, and then you want that to go as fast as possible.
>         DRBD, by contrast, maintains two identical copies of a block
>         of storage, only one of which can normally (ext3 filesystems)
>         be mounted at a time, and replicates continuously between them
>         as long as the network bandwidth can handle the rate of disk
>         writes to the primary side. So this should be thought of as
>         either a primary PVE site with disaster recovery (when the
>         nodes are far apart), or a primary / warm backup, kind of a
>         cheapskate's version of shared SAN storage, but with no SAN
>         (if the nodes are right next to each
>         other). Just think carefully about what you want to accomplish, what data and what VM operations you want to protect against the failure of what, and how you want the recovery scenario to be.
>         
> 
> 
> I am extremely excited to hear about the beta 1.4 version, and I will
> eagerly download and try it when it's available. Being able to do more
> of the things that people pay large amounts of money to VMWare to do
> (guest auto-restart when the hosting server goes down,
> close-to-instantaneous VM migrations) again for close to zero dollars
> is even more amazing.
> 
> 
> Messrs. Maurer, let me know how I can contribute to your project,
> apart from the obvious of money. Do you want my hacked-up code for a
> "qmclone" utility? I basically adapted some of the Perl code from
> "qmigrate", added some shell calls to instantiate LVM read-only
> snapahots, read and wrote a new, modified config file to change the
> names of the .cow files and comment out networking cards (to prevent
> static IP conflicts when the machine is started), and poof! I can
> clone a KVM machine (while either running or stopped) to a new,
> branched-off copy that can then be renamed and re-IP-addressed and
> become a developer or Q/A testing machine. The code is definitely not
> pretty (no error checking) and it's not integrated into the GUI of
> PVE, but it does function. Open source rules!
> 
> 
> Let me know if I should email it to you. Or with your new storage
> model, this kind of cloning of a machine to the same node might be
> much easier, so you might already have written a cloning process in
> your 1.4 version. If you haven't, I can give it a shot in my spare
> time.
> 
> 
> -- Jeff Saxe, Network Engineer
> Blue Ridge InternetWorks, Charlottesville, VA
> CCIE # 9376
> 434-817-0707 ext. 2024 (work)  /  434-882-3508
> (cell)  /  JSaxe at briworks.com
> 
> 
> 
> 
> 
> 
> 
> 
> On Aug 20, 2009, at 1:04 PM, Eric Bollengier wrote:
> 
> 
> 
> > Yes, definitly, PVE + DRBD would be a great solution !
> > 
> > Le Thursday 20 August 2009 18:51:39 Gilberto Nunes, vous avez
> > écrit :
> > 
> > > OK
> > > I do it!
> > > I thing that PVE is much better that using DRBD and not rsync.
> > > I think that rsync is more slow than DRBD.
> > > But whatever!
> 
> 
> 

Gilberto Nunes Ferreira
TI
Selbetti Gestão de Documentos
Telefone: +55 (47) 3441-6004
Celular: +55 (47) 8861-6672 







Disse Jesus: Eu sou o Caminho, a Verdade e a Vida. Ninguém vem ao Pai a
não ser por Mim.
<><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-user/attachments/20090820/215508ed/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 16538 bytes
Desc: not available
URL: <http://lists.proxmox.com/pipermail/pve-user/attachments/20090820/215508ed/attachment.jpg>