Re: [pve-devel] qemu-server:add support for hugetlbfs
1.) Is there some edivence that it is faster (under realistic workload)? I known that transparent hugepage can be really a problem with a lot of database (oracle,mysql,redis,..) I never bench it myself, but I hope that Cesar will do it ;). Disable transparent hugepage is a solution, but it's disable it for all the vms. I think that static hugepage can do the job, but it need to be tested. 2.) Where do we free/dealloc those hugepages? Are the associated with the KVM process somehow? I'm not sure that when hupage are defined, they use memory by default. But when the kvm process is starting, the memory is allocated/reserverd for the kvm process, and the memory is free up on kvm process stop. - Mail original - De: dietmar diet...@proxmox.com À: aderumier aderum...@odiso.com, pve-devel pve-devel@pve.proxmox.com Envoyé: Samedi 20 Décembre 2014 09:32:42 Objet: Re: [pve-devel] qemu-server:add support for hugetlbfs This add support for manually defined hugepages, which can be faster than transparent hugepages for some workload like databases 1.) Is there some edivence that it is faster (under realistic workload)? 2.) Where do we free/dealloc those hugepages? Are the associated with the KVM process somehow? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] qemu-server:add support for hugetlbfs
On December 21, 2014 at 1:23 PM Alexandre DERUMIER aderum...@odiso.com wrote: 1.) Is there some edivence that it is faster (under realistic workload)? I known that transparent hugepage can be really a problem with a lot of database (oracle,mysql,redis,..) I never bench it myself, but I hope that Cesar will do it ;). Disable transparent hugepage is a solution, but it's disable it for all the vms. I think that static hugepage can do the job, but it need to be tested. Yes, before introducing such feature we want to see if there is any advantage. 2.) Where do we free/dealloc those hugepages? Are the associated with the KVM process somehow? I'm not sure that when hupage are defined, they use memory by default. But when the kvm process is starting, the memory is allocated/reserverd for the kvm process, but there is a race condition in your implementation, so it is not sure which kvm process gets the hugepages (if several VM start at once)? and the memory is free up on kvm process stop. But hugpages keep reserved? I have no idea if that is a problem? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH] this commit:
commit 1c0c1c17b020710fd841c399c1e147ccc10007cd
Author: Wolfgang Link wolfg...@linksystems.org
Date: Wed Nov 26 11:11:40 2014 +0100
shutdown by Qemu Guest Agent if the agent flag in the config is set
Important: guest-shutdown returns only by error a message.
Signed-off-by: Wolfgang Link wolfg...@linksystems.org
breaks live migration as it always tries to load the vm config - even in case
of $nocheck. Also it double loads the config ($conf $config)
Signed-off-by: Stefan Priebe s.pri...@profihost.ag
---
PVE/QemuServer.pm |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 44b192a..22de361 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -3753,11 +3753,10 @@ sub vm_stop {
}
$timeout = 60 if !defined($timeout);
- my $config = load_config($vmid);
eval {
if ($shutdown) {
- if ($config-{agent}) {
+ if (!$nocheck $conf-{agent}) {
vm_qmp_command($vmid, { execute = guest-shutdown },
$nocheck);
} else {
vm_qmp_command($vmid, { execute = system_powerdown },
$nocheck);
--
1.7.10.4
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Crashing debian wheezy guests after migration
Am 21.12.2014 08:30, schrieb Alexandre DERUMIER: Hi Stefan, I'm also manage a lot of wheezy guest (maybe 400-500 vms), but don't use stock 3.2 kernel. I'm using custom 3.7 kernel without problem, but also 3.14 and 3.16 kernel from wheezy backports. I never had screen frozen or black after migration. Yes the problem only occours with 3.2 kernel. But i'm not able to reproduce it with Qemu 2.2.0 so i upgraded my systems to latest PVE code. May be it is related to this code: http://git.qemu.org/?p=qemu.git;a=commit;h=a096b3a6732f846ec57dc28b47ee9435aa0609bf Stefan - Mail original - De: Stefan Priebe s.pri...@profihost.ag À: pve-devel pve-devel@pve.proxmox.com Envoyé: Vendredi 19 Décembre 2014 19:10:50 Objet: [pve-devel] Crashing debian wheezy guests after migration Hi, While running plain Debian wheezy as a guest I've seen 95% of the guests crashes after migration. (Screen frozen or black) I do not see this with Debian Jessie or windows. Does anybody know a workaround or solution? I have no control about the guests so I need a qemu or host based solution ;-) Greets, Stefan ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Crashing debian wheezy guests after migration
On Sun, 21 Dec 2014 21:13:01 +0100 Stefan Priebe s.pri...@profihost.ag wrote: May be it is related to this code: http://git.qemu.org/?p=qemu.git;a=commit;h=a096b3a6732f846ec57dc28b47ee9435aa0609bf I see this happen now and then but it has never caused a crash. Experienced this with: - Debian Wheezy and Ubuntu server 10.04 and 12.04 - FreeBSD 8.x - 10.x - Omnios 151008 - 151012 - CentOS 5,6,7 and RHEL 5,6,7 -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: Sorry, no fortune this time. pgpqvqAcysgdr.pgp Description: OpenPGP digital signature ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] qemu-server:add support for hugetlbfs
Yes i will do the test for MS-SQL-Server 2008 STD with and without THP (Transparent Huge Pages) in a VM with 243 GB RAM (without KSM and Balloon enabled) as soon as i have solved my problem of quorum, and i will communicate the results. Moreover, i guess that the best choice is that you can enable or disable static hugepage for each VM, that in my case with MS-SQL, i guess that will be better have it disabled, and i will be communicating it. Moreover, to short term, with some extra HDDs in one of these servers, i believe that i can do tests as help for the future versions of PVE if you believe to will find it useful (always that the proprietary of these Dell servers also be agree, that as he has PVE, i guess that he also will be interested). - Original Message - From: Alexandre DERUMIER aderum...@odiso.com To: dietmar diet...@proxmox.com Cc: pve-devel pve-devel@pve.proxmox.com Sent: Sunday, December 21, 2014 9:23 AM Subject: Re: [pve-devel] qemu-server:add support for hugetlbfs 1.) Is there some edivence that it is faster (under realistic workload)? I known that transparent hugepage can be really a problem with a lot of database (oracle,mysql,redis,..) I never bench it myself, but I hope that Cesar will do it ;). Disable transparent hugepage is a solution, but it's disable it for all the vms. I think that static hugepage can do the job, but it need to be tested. 2.) Where do we free/dealloc those hugepages? Are the associated with the KVM process somehow? I'm not sure that when hupage are defined, they use memory by default. But when the kvm process is starting, the memory is allocated/reserverd for the kvm process, and the memory is free up on kvm process stop. - Mail original - De: dietmar diet...@proxmox.com À: aderumier aderum...@odiso.com, pve-devel pve-devel@pve.proxmox.com Envoyé: Samedi 20 Décembre 2014 09:32:42 Objet: Re: [pve-devel] qemu-server:add support for hugetlbfs This add support for manually defined hugepages, which can be faster than transparent hugepages for some workload like databases 1.) Is there some edivence that it is faster (under realistic workload)? 2.) Where do we free/dealloc those hugepages? Are the associated with the KVM process somehow? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Quorum problems with NICs Intel of 10 Gb/s and VMsturns off
After several checks, I found the problem in these two servers: a configuration in the Hardware Bios that isn't compatible with the pve-kernel-3.10.0-5, and my NICs was getting the link to down and after up. (i guess that soon i will comunicate my setup of BIOS in Dell R720). ... :-) But now i have other problem, with the mix of PVE-manager 3.3-5 and 2.3-13 versions in a PVE cluster of 8 nodes: I am losing quorum in several nodes very often. Moreover, for now i can not apply a upgrade to my old PVE nodes, so for the moment i would like to know if is possible to make a quick configuration for that all my nodes always has quorum. The strange behaviour is that when i run pvecm status, i get this message: Version: 6.2.0 Config Version: 41 Cluster Name: ptrading Cluster Id: 28503 Cluster Member: Yes Cluster Generation: 8360 Membership state: Cluster-Member Nodes: 8 Expected votes: 8 Total votes: 8 Node votes: 1 Quorum: 5 Active subsystems: 6 Flags: Ports Bound: 0 177 Node name: pve5 Node ID: 5 Multicast addresses: 239.192.111.198 Node addresses: 192.100.100.50 And in the PVE GUI i see the red light in all the others nodes. Can apply a some kind of temporal solution as Quorum: 1 for that my nodes can work well and not has this strange behaviour? (Only until I performed the updates) Or, what will be the more simple and quick temporal solution for avoid to do a upgrade in my nodes? (something as for example: add to the rc.local file a line that says: pvecm expected 1) Note about of the Quorum: I don't have any Hardware fence device enabled, so i do not care that each node always have quorum (i always can turns off the server manually and brutally if it is necessary). - Original Message - From: Cesar Peschiera br...@click.com.py To: Alexandre DERUMIER aderum...@odiso.com Cc: pve-devel pve-devel@pve.proxmox.com Sent: Saturday, December 20, 2014 9:30 AM Subject: Re: [pve-devel] Quorum problems with NICs Intel of 10 Gb/s and VMsturns off Hi Alexandre I put 192.100.100.51 ip address directly to bond0, and i don't have network enabled (as if the node is totally isolated) This was my setup: --- auto bond0 iface bond0 inet static address 192.100.100.51 netmask 255.255.255.0 gateway 192.100.100.4 slaves eth0 eth2 bond_miimon 100 bond_mode 802.3ad bond_xmit_hash_policy layer2 auto vmbr0 iface vmbr0 inet manual bridge_ports bond0 bridge_stp off bridge_fd 0 post-up echo 0 /sys/devices/virtual/net/vmbr0/bridge/multicast_snooping post-up echo 1 /sys/class/net/vmbr0/bridge/multicast_querier .. :-( Some other suggestion? - Original Message - From: Alexandre DERUMIER aderum...@odiso.com To: Cesar Peschiera br...@click.com.py Cc: pve-devel pve-devel@pve.proxmox.com Sent: Friday, December 19, 2014 7:59 AM Subject: Re: [pve-devel] Quorum problems with NICs Intel of 10 Gb/s and VMsturns off maybe can you try to put 192.100.100.51 ip address directly to bond0, to avoid corosync traffic going through to vmbr0. (I remember some old offloading bugs with 10gbe nic and linux bridge) - Mail original - De: Cesar Peschiera br...@click.com.py À: aderumier aderum...@odiso.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Vendredi 19 Décembre 2014 11:08:33 Objet: Re: [pve-devel] Quorum problems with NICs Intel of 10 Gb/s and VMsturns off can you post your /etc/network/interfaces of theses 10gb/s nodes ? This is my configuration: Note: The LAN use 192.100.100.0/24 #Network interfaces auto lo iface lo inet loopback iface eth0 inet manual iface eth1 inet manual iface eth2 inet manual iface eth3 inet manual iface eth4 inet manual iface eth5 inet manual iface eth6 inet manual iface eth7 inet manual iface eth8 inet manual iface eth9 inet manual iface eth10 inet manual iface eth11 inet manual #PVE Cluster and VMs (NICs are of 10 Gb/s): auto bond0 iface bond0 inet manual slaves eth0 eth2 bond_miimon 100 bond_mode 802.3ad bond_xmit_hash_policy layer2 #PVE Cluster and VMs: auto vmbr0 iface vmbr0 inet static address 192.100.100.51 netmask 255.255.255.0 gateway 192.100.100.4 bridge_ports bond0 bridge_stp off bridge_fd 0 post-up echo 0 /sys/devices/virtual/net/vmbr0/bridge/multicast_snooping post-up echo 1 /sys/class/net/vmbr0/bridge/multicast_querier #A link for DRBD (NICs are of 10 Gb/s): auto bond401 iface bond401 inet static address 10.1.1.51 netmask 255.255.255.0 slaves eth1 eth3 bond_miimon 100 bond_mode balance-rr mtu 9000 #Other link for DRBD (NICs are of 10 Gb/s): auto bond402 iface bond402 inet static address 10.2.2.51 netmask 255.255.255.0 slaves eth4 eth6 bond_miimon 100 bond_mode balance-rr mtu 9000 #Other link for DRBD (NICs are of 10 Gb/s): auto bond403 iface bond403 inet static address 10.3.3.51 netmask 255.255.255.0 slaves eth5 eth7 bond_miimon 100 bond_mode balance-rr mtu 9000 #A link for the NFS-Backups (NICs are of 1 Gb/s): auto bond10 iface bond10 inet static address 10.100.100.51 netmask 255.255.255.0 slaves eth8 eth10 bond_miimon 100 bond_mode
Re: [pve-devel] Crashing debian wheezy guests after migration
Am 21.12.2014 um 22:51 schrieb Michael Rasmussen: On Sun, 21 Dec 2014 21:13:01 +0100 Stefan Priebe s.pri...@profihost.ag wrote: May be it is related to this code: http://git.qemu.org/?p=qemu.git;a=commit;h=a096b3a6732f846ec57dc28b47ee9435aa0609bf I see this happen now and then but it has never caused a crash. Experienced this with: - Debian Wheezy and Ubuntu server 10.04 and 12.04 - FreeBSD 8.x - 10.x - Omnios 151008 - 151012 - CentOS 5,6,7 and RHEL 5,6,7 I only saw this on Debian Wheezy with 3.2 Kernel and only after migration. But it'S fixed with qemu 2.2.0 this indicates it was a qemu bug or a qemu and a kernel bug. Stefan ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
