applied, thanks!
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
CVE-2016-7116:
9pfs: forbid illegal path names
9pfs: forbid . and .. in file names
9pfs: handle walk of ".." in the root directory
CVE-2016-7155: scsi: check page count while initialising descriptor rings
CVE-2016-7156: scsi: pvscsi: avoid infinite loop while building SG list
CVE-2016-7157:
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
>>small question to live migration, you wrote the hot plug features breaks
>>live migration but the qemu wiki says that this should work.
The wiki is pretty old.
When I said that it break live migration,It's only if you have already enable
livemigration on qemu 2.6 and try to migrate to new
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Signed-off-by: Dominik Csapak
---
PVE/CephTools.pm | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/PVE/CephTools.pm b/PVE/CephTools.pm
index 6497d52..0d26ea3 100644
--- a/PVE/CephTools.pm
+++ b/PVE/CephTools.pm
@@ -37,7 +37,7 @@ sub get_config {
Signed-off-by: Dominik Csapak
---
this needs the previous patch
PVE/CephTools.pm | 160 ---
1 file changed, 160 deletions(-)
diff --git a/PVE/CephTools.pm b/PVE/CephTools.pm
index c3eac48..6497d52 100644
---
applied
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
I pushed my current qemu-2.7 WIP to github.
It seems to work, still needs more testing & some cleanup (need to
squash all those small fixes for the older patches together).
I dropped the patch which adds support for a secondary server for
glusterfs as qemu can do this now - with a different
Hi,
small question to live migration, you wrote the hot plug features breaks
live migration but the qemu wiki says that this should work.
The only limitations are:
1. migration target should be started with initial CPU count '-smp XX'
that includes hot-added CPUs on migration source side.
I'm okay with 4K. Again, anything other than default is fine by me.
On Thu, Aug 25, 2016 at 3:55 AM, Wolfgang Bumiller
wrote:
> On Wed, Aug 24, 2016 at 07:19:04PM +0200, Dietmar Maurer wrote:
> > I am afraid that increasing block size is bad for sparse file detection.
>
12 matches
Mail list logo