>>What do you think?
yes, sure, we can wait.
(I just have done some qemu 2.4 like memory unplug for now, to prepare
qemu-server patches)
- Mail original -
De: "Wolfgang Bumiller"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Mercredi 1 Juillet 2015 15:26:45
Objet: Re: [pve-devel] [PATCH]
Am 02.07.2015 um 08:17 schrieb Alexandre DERUMIER:
> About ceph jessie support,
>
> seem that ceph team have problem with cloud-init for jessie
> (they use cloud-init to deploy with teuthology their building tests)
>
> I'm currently looking that with them (and fixing some jessie systemd
> cloud-
About ceph jessie support,
seem that ceph team have problem with cloud-init for jessie
(they use cloud-init to deploy with teuthology their building tests)
I'm currently looking that with them (and fixing some jessie systemd cloud-init
bug).
But I can tell when it'll be ready.
So maybe for now
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Current make too much sleep because
if (now - last_pause_ns > SLICE_TIME) {
last_pause_ns = now;
block_job_sleep_ns(&s->common, QEMU_CLOCK_REALTIME, SLICE_TIME);
so, we sleep SLICE_TIME, then at next iteration if lastpause("SLICE_TIME") >
SLICE_TIME, we sleep again.
So, it almo
Hi,
Redhat has officially released hammer. (Attention this is not the last
tagged point release v0.94.1.2 instead it is current ceph/hammer (no tag))
http://redhatstorage.redhat.com/2015/06/25/announcing-red-hat-ceph-storage-1-3/
--
tTefan
___
pve-d
qemu 2.4 feature
Signed-off-by: Alexandre Derumier
---
PVE/QemuServer.pm | 101 --
1 file changed, 83 insertions(+), 18 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index f035b67..36bed4a 100644
--- a/PVE/QemuServer.pm
+++ b
My patch doesn't actually apply to the current master branch any longer.
And a big migration related pull request appeared on the mailing list
today, so I'm sure if we fixup the patches today they'll be broken again
tomorrow.
But if you want to test them early I can still help going over the C
code
Yes, in this case we can simply use a fixed method. Thanks.
On 07/01/2015 02:13 PM, Dietmar Maurer wrote:
+ PVE.Utils.API2Request({
+ url: me.url,
+ waitMsgTarget: me,
+ method: me.method || (me.backgroundDelay ? 'POST' : 'PUT'),
Can we simply
> + PVE.Utils.API2Request({
> + url: me.url,
> + waitMsgTarget: me,
> + method: me.method || (me.backgroundDelay ? 'POST' : 'PUT'),
Can we simply used fixed method here?
method: 'PUT',
___
pve-devel mailing l
Deduplicated network setup code.
Using 'ip route replace' to replace or add the route.
This strategy can be rolled back safely:
1) add new ip (no harm done, old ip still exists)
2) replace route
on error:
Delete the new ip, old one is still in place.
If deleting the new ip fails, it was a
Deduplicated network setup code.
Using 'ip route replace' to replace or add the route.
This strategy can be rolled back safely:
1) add new ip (no harm done, old ip still exists)
2) replace route
on error:
Delete the new ip, old one is still in place.
If deleting the new ip fails, it was a
Changes since [PATCH]:
- removed all the unnecessary code
- direct call of the warning message without using the hook method
- additional function submit_first to pass the enable flag parameter in the
correct way
- added additional condition for the close method
- optimized enable flag change con
14 matches
Mail list logo
