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

[Jeff Saxe]

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!

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