[PVE-User] First feeling about VE...
JSaxe at briworks.com
Thu Aug 20 20:12:17 CEST 2009
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
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 :
>> 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...
More information about the pve-user