There's a discussion floating around on the list of a new CPU type which
includes all the CPU flags supported on all nodes in a cluster. It's
similar to 'host', obviously, but would ensure that migrations would always
succeed by ensuring that only the flags available on *all* nodes are active
in t
Hi all,
Martin has kindly redirected me to the list as the appropriate place to ask /
discuss this:
I noticed that, even though a kvm guest is set to CPU type 'host', the live
migration feature does not check for compatibility with the destination host.
E.g. Moving from a Opteron 6366 to an Int
> 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'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 use
Thank you very much Alexandre. Will try that next week.
On Wed, Mar 18, 2015 at 6:07 PM, Alexandre DERUMIER wrote:
> prepare your image,
>
> copy unattend.xml in C:\Windows\System32\sysprep>
>
> cd C:\Windows\System32\sysprep>
> sysprep /generalize /oobe /unattend:unattend.xml /shutdown
>
>
> th
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 suppo
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 wrote
It is fantastic !!!
Talking about of DRBD, for now, and if is possibe, i would like to order a
features:
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 recommen
I just want to note that the new DRBD9 has some cool feature
- support more that 2 nodes
- support snapshots
- as fast as DRBD 8.X
I am now writing a storage plugin, so that we can do further tests...
> Oh, OK, sorry
>
> >> DRBD9 isn't ready for his use in a production environment, now is in
> >
Oh, OK, sorry
- Original Message -
From: "Dietmar Maurer"
To: "Cesar Peschiera" ; "PVE Development List"
Sent: Friday, March 20, 2015 12:50 PM
Subject: Re: [pve-devel] DRBD9 test packages for jessie
DRBD9 isn't ready for his use in a production environment, now is in
pre-release p
> 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 repo
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 b
12 matches
Mail list logo
