Hello,
I consider myself quite typical user and here is a way I use Proxmox 90% of
the time:
- I do search some VM and open console
- I do search some VM and change some settings
- I do search some VM and check stats for this VM
- I do search some VM and check logs for this VM
- I do search some
Hi all,
I just added the latest DRBD9 driver to the kernel, and assembled
Debian packages for the management tools:
https://git.proxmox.com/?p=drbd-utils.git;a=summary
https://git.proxmox.com/?p=drbdmanage.git;a=summary
https://git.proxmox.com/?p=pve-kernel-3.10.0.git;a=summary
I also uploaded
DRBD9 isn't ready for his use in a production environment, now is in
pre-release phase...
http://www.linbit.com/en/component/phocadownload/category/5-drbd
Respectfully I mean that I believe that will be good wait to that DRBD9 be
in a stable version before of release it in the pve
1- While a VM is running with LVM on top of DRBD, the replicate storages be
in secondary mode, ie, only to have a primary storage for each VM that is
running (that always was the recommendation of LINBIT for security reasons).
The concept with DRBD9 is a bit different, i.e. we will not use
I agree with Daniel, his idea is better!!!. (maybe in a phase initial can be
this feature as something pending)
And about of the verification of DRBD storages (if is that the plugin will have
it), do with the best hash algorithm, that i believe that is sha1 (that always
are the that come
I'd rather it run the resync before continuing the migration, than simply
abort. It'll take a bit longer to migrate, but I can't think of any reason
it would make sense *not* to run the resync at that point and simply keep
going once that's done.
On Fri, Mar 20, 2015, 13:30 Cesar Peschiera
Thank you very much Alexandre. Will try that next week.
On Wed, Mar 18, 2015 at 6:07 PM, Alexandre DERUMIER aderum...@odiso.com wrote:
prepare your image,
copy unattend.xml in C:\Windows\System32\sysprep
cd C:\Windows\System32\sysprep
sysprep /generalize /oobe /unattend:unattend.xml
I'd rather it run the resync before continuing the migration, than simply
abort. It'll take a bit longer to migrate, but I can't think of any reason
it would make sense *not* to run the resync at that point and simply keep
going once that's done.
Thinking again, maybe will be good that the