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

[Martin Maurer]

Hi Jeff,

Yes, send the code to dietmar at proxmox.com<mailto:dietmar at proxmox.com>, he will take a look on it to see if it fits to the new system.
Cloning is not that simple and there are a lot of OS specific issues also but if someone knows what he is doing it could be quite useful.

Proxmox VE and DRBD.
DRBD is already in but not configured. We improve the integration step by step but keep in mind, DRBD will always needs deep knowledge to optimize and configure for the specific situation – therefore if you consider running DRBD on a production environment think of going for an DRBD support package from www.linbit.com<http://www.linbit.com>.

Thanks,

Best Regards,

Martin Maurer

martin at proxmox.com<mailto:martin at proxmox.com>
http://www.proxmox.com

____________________________________________________________________
Proxmox Server Solutions GmbH
Kohlgasse 51/10, 1050 Vienna, Austria
Phone: +43 1 545 4497 11 Fax: +43 1 545 4497 22
Commercial register no.: FN 258879 f
Registration office: Handelsgericht Wien

From: pve-user-bounces at pve.proxmox.com [mailto:pve-user-bounces at pve.proxmox.com] On Behalf Of Jeff Saxe
Sent: Donnerstag, 20. August 2009 20:12
To: Eric Bollengier; gilberto.nunes at selbetti.com.br
Cc: proxmoxve
Subject: Re: [PVE-User] First feeling about VE...

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<mailto: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!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-user/attachments/20090820/7bfdd2eb/attachment.htm>