[Qemu-devel] [Bug 1174654] Re: qemu-system-x86_64 takes 100% CPU after host machine resumed from suspend to ram
I don't know if this will help, but I had a similar problem. When creating a snapshot image of an XP machine, all works just fine when loading it. As time passes on the host the loadvm start to become very slow. To reproduce: 1. Create a snapshot image (savevm) 2. leave QEMU 3. move the *HOST* clock one month in the future 4. Start QEMU with -loadvm It turns out that the -rtc clock=vm made this disappear. When using the default caused the problem. John -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1174654 Title: qemu-system-x86_64 takes 100% CPU after host machine resumed from suspend to ram Status in QEMU: Confirmed Status in “qemu” package in Ubuntu: Invalid Bug description: I have Windows XP SP3 inside qemu VM. All works fine in 12.10. But after upgraiding to 13.04 i have to restart the VM each time i resuming my host machine, because qemu process starts to take CPU cycles and OS inside VM is very slow and sluggish. However it's still controllable and could be shutdown by itself. According to the taskmgr any active process takes 99% CPU. It's not stucked on some single process. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1174654/+subscriptions
[Qemu-devel] Adding support for Stateless Static NAT for TAP devices
When running multiple instances of QEMU from the same image file
(using -snapshot) and connecting each instance to a dedicated TAP
device, the Guest OS will most likely not be able to communicate
with the outside world as all packets leave the Guest OS from the
same IP and thus the Host OS will have difficulty returning the
packets to the correct TAP device/Guest OS. Stateless Static
Network Address Translation or SSNAT allows the QEMU to map the
network of the Guest OS to the network of the TAP device allowing
a unique IP address for each Guest OS that ease such case.
The only mandatory argument to the SSNAT is the Guest OS network
IP, the rest will be figured out from the underlying TAP device.
Signed-off-by: John Basila jbas...@checkpoint.com
---
net/tap.c| 369 +-
qapi-schema.json |5 +-
qemu-options.hx | 10 ++-
3 files changed, 381 insertions(+), 3 deletions(-)
diff --git a/net/tap.c b/net/tap.c
index 1971525..2408a49 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -39,16 +39,88 @@
#include qemu-char.h
#include qemu-common.h
#include qemu-error.h
+#include qemu_socket.h
#include net/tap-linux.h
#include hw/vhost_net.h
+#include checksum.h
+
+#define ETH_P_ARP 0x0806 /* Address Resolution packet */
+#define ETH_P_IP 0x0800 /* Internet Protocol packet */
+#define ETH_P_IPV6 0x86DD /* IPv6 over blueblook */
+
+#define ETH_ALEN 6
+
+struct ethhdr {
+unsigned char h_dest[ETH_ALEN]; /* destination eth addr */
+unsigned char h_source[ETH_ALEN]; /* source ether addr*/
+unsigned short h_proto;/* packet type ID field */
+};
+
+#define IP_PROTO_TCP 6
+#define IP_PROTO_UDP 17
+#define IPV4_ADRESS_LENGTH 4
+
+struct arphdr {
+unsigned short ar_hrd; /* format of hardware address */
+unsigned short ar_pro; /* format of protocol address */
+unsigned char ar_hln; /* length of hardware address */
+unsigned char ar_pln; /* length of protocol address */
+unsigned short ar_op; /* ARP opcode (command) */
+
+/*
+ * Ethernet looks like this : This bit is variable sized however...
+ */
+unsigned char ar_sha[ETH_ALEN];/* sender hardware
address */
+unsigned char ar_sip[IPV4_ADRESS_LENGTH]; /* sender IP address */
+unsigned char ar_tha[ETH_ALEN];/* target hardware
address */
+unsigned char ar_tip[IPV4_ADRESS_LENGTH]; /* target IP address */
+};
+
+#define IP_HEADER_LENGTH(ip) (((ip-ip_hlv)0xf) 2)
+
+/** An IPv4 packet header */
+struct iphdr {
+ uint8_t ip_hlv; /** Header length and version of the header
*/
+ uint8_t ip_tos; /** Type of Service
*/
+ uint16_t ip_len; /** Length in octets, inlc. this header and data
*/
+ uint16_t ip_id; /** ID is used to aid in assembling framents
*/
+ uint16_t ip_off; /** Info about fragmentation (control, offset)
*/
+ uint8_t ip_ttl; /** Time to Live
*/
+ uint8_t ip_p;/** Next level protocol type
*/
+ uint16_t ip_sum; /** Header checksum
*/
+ uint32_t ip_src; /** Source IP address
*/
+ uint32_t ip_dst; /** Destination IP address
*/
+};
+
+/** UDP packet header */
+typedef struct udphdr {
+uint16_t uh_sport; /* source port */
+uint16_t uh_dport; /* destination port */
+uint16_t uh_ulen; /* udp length */
+uint16_t uh_chksum;/* udp checksum */
+} udp_header;
+
+
/* Maximum GSO packet size (64k) plus plenty of room for
* the ethernet and virtio_net headers
*/
#define TAP_BUFSIZE (4096 + 65536)
+typedef struct SSNATInfo {
+ unsigned int ssnat_active : 1;
+
+ struct in_addr ssnat_ifaddr;
+ struct in_addr ssnat_ifmask;
+ uint8_t ssnat_hwaddr[ETH_ALEN];
+
+ struct in_addr ssnat_guest;
+ struct in_addr ssnat_host;
+ struct in_addr ssnat_mask;
+} SSNATInfo;
+
typedef struct TAPState {
NetClientState nc;
int fd;
@@ -59,6 +131,9 @@ typedef struct TAPState {
unsigned int write_poll : 1;
unsigned int using_vnet_hdr : 1;
unsigned int has_ufo: 1;
+
+ SSNATInfo ssnat_info;
+
VHostNetState *vhost_net;
unsigned host_vnet_hdr_len;
} TAPState;
@@ -154,11 +229,154 @@ static ssize_t tap_receive_raw(NetClientState *nc, const
uint8_t *buf, size_t si
return tap_write_packet(s, iov, iovcnt);
}
+#define SSNAT_MAP_IP(_orig, _to, _mask) ( (_orig.s_addr ~_mask.s_addr) |
(_to.s_addr _mask.s_addr) )
+#define SSNAT_IS_MATCH(_orig, _from, _mask)( (_orig.s_addr _mask.s_addr)
== (_from.s_addr _mask.s_addr) )
+
+static void tap_ssnat_translate_arp(uint8_t* buf, size_t size, const struct
in_addr from, const struct in_addr to, const
Re: [Qemu-devel] Adding support for Stateless Static NAT for TAP devices
Please allow me to add a few comments: The problem here is related to the fact that QEMU is executed with multiple instances and all instances start from the same snapshot, thus if they all send a UDP DNS query, they will all create a packet - for example - 10.0.0.2:2345 - DNSERVER:53. The source port is the same. The first packet that reaches the ipfilter will result in going over the iptables rules and get NATed properly, the second QEMU instance that will send the same UDP packet will not get to run over the iptables rules as the ipfilter already saw this packet and the packet should be RELATED to a different connection and thus will cause the response packets of machine B to be received via machine A as the NAT rule will de-NAT the return packet to to the relevant connection which is related to machine A. John -Original Message- From: Stefan Hajnoczi [mailto:stefa...@gmail.com] Sent: Thursday, August 30, 2012 1:44 PM To: John Basila Cc: qemu-devel@nongnu.org; Anthony Liguori; Rusty Russell; netfil...@vger.kernel.org Subject: Re: Adding support for Stateless Static NAT for TAP devices On Thu, Aug 30, 2012 at 10:27 AM, John Basila jbas...@checkpoint.com wrote: I have tried NAT and this is why I came up with this feature. QEMU's net/tap.c is the wrong place to add NAT code. The point of tap is to use the host network stack. If you want userspace networking, use -netdev user or -netdev socket. Please look into iptables more. I have CCed the netfilter mailing list. The question is: The host has several tap interfaces (tap0, tap1, ...) and the machine on the other end of each tap interface uses IP address 10.0.0.2. So we have: tap0 - virtual machine #0 (10.0.0.2) tap1 - virtual machine #1 (10.0.0.2) tap2 - virtual machine #2 (10.0.0.2) Because the virtual machines all use the same static IP address, they cannot communicate with each other or the outside world (they fight over ARP). We'd like to NAT the tap interfaces: tap0 - virtual machine #0 (10.0.0.2 NAT to 192.168.0.2) tap1 - virtual machine #1 (10.0.0.2 NAT to 192.168.0.3) tap2 - virtual machine #2 (10.0.0.2 NAT to 192.168.0.4) This would allow the virtual machines to communicate even though each believes it is 10.0.0.2. How can this be done using iptables and friends? Thanks, Stefan Scanned by Check Point Total Security Gateway.
Re: [Qemu-devel] Adding support for Stateless Static NAT for TAP devices
I have tried NAT and this is why I came up with this feature. When starting multiple QEMU instances from the same snapshot image, the Guest OS in all instances from the same state and if they start a connection to the DNS server for example, they will all use the same source port. The iptables will NAT the first packet it sees, but when the second QEMU instance sends the same packet, the iptables will match the already NATed connection and thus cause problems from returning packets. Using the SSNAT, this solves the problem by allowing a unique connection to be observed by the iptables. Regarding the vhost=on, I can disallow the use of both which I think is fair. John -Original Message- From: Stefan Hajnoczi [mailto:stefa...@gmail.com] Sent: Thursday, August 30, 2012 12:14 PM To: John Basila Cc: qemu-devel@nongnu.org; Anthony Liguori Subject: Re: Adding support for Stateless Static NAT for TAP devices On Thu, Aug 30, 2012 at 09:12:19AM +0300, John Basila wrote: When running multiple instances of QEMU from the same image file (using -snapshot) and connecting each instance to a dedicated TAP device, the Guest OS will most likely not be able to communicate with the outside world as all packets leave the Guest OS from the same IP and thus the Host OS will have difficulty returning the packets to the correct TAP device/Guest OS. Stateless Static Network Address Translation or SSNAT allows the QEMU to map the network of the Guest OS to the network of the TAP device allowing a unique IP address for each Guest OS that ease such case. The only mandatory argument to the SSNAT is the Guest OS network IP, the rest will be figured out from the underlying TAP device. Signed-off-by: John Basila jbas...@checkpoint.com --- net/tap.c| 369 +- qapi-schema.json |5 +- qemu-options.hx | 10 ++- 3 files changed, 381 insertions(+), 3 deletions(-) This does not work with vhost=on because the host-guest packet processing happens in vhost_net.ko instead of in QEMU. Use iptables on the host to NAT the tap interface. Stefan Scanned by Check Point Total Security Gateway.
Re: [Qemu-devel] Adding support for Stateless Static NAT for TAP devices
I have a setup that requires to run virtual machines using QEMU. All these machines will be executed from the same snapshot thus giving them the save same state when they come to life, this is why they all will have the same source IP, the only difference between them is that each one is connected to a different TAP device. I have tried using iptables to NAT the connections based on the TAP interface and make it change the source IP of the connection to an IP that upon return will go back to the correct TAP device, but alas, the problem of state fullness of the iptables caused the problem with the second instance of the virtual machine that sent the same packet that was did pass the rule base as it was matched on an already opened connection that thus was NATed to the first virtual machine source IP. -Original Message- From: Dennis Jacobfeuerborn [mailto:denni...@conversis.de] Sent: Thursday, August 30, 2012 3:38 PM To: John Basila Cc: Stefan Hajnoczi; qemu-devel@nongnu.org; Anthony Liguori; Rusty Russell; netfil...@vger.kernel.org Subject: Re: Adding support for Stateless Static NAT for TAP devices On 08/30/2012 12:58 PM, John Basila wrote: Please allow me to add a few comments: The problem here is related to the fact that QEMU is executed with multiple instances and all instances start from the same snapshot, thus if they all send a UDP DNS query, they will all create a packet - for example - 10.0.0.2:2345 - DNSERVER:53. The source port is the same. The first packet that reaches the ipfilter will result in going over the iptables rules and get NATed properly, the second QEMU instance that will send the same UDP packet will not get to run over the iptables rules as the ipfilter already saw this packet and the packet should be RELATED to a different connection and thus will cause the response packets of machine B to be received via machine A as the NAT rule will de-NAT the return packet to to the relevant connection which is related to machine A. John -Original Message- From: Stefan Hajnoczi [mailto:stefa...@gmail.com] Sent: Thursday, August 30, 2012 1:44 PM To: John Basila Cc: qemu-devel@nongnu.org; Anthony Liguori; Rusty Russell; netfil...@vger.kernel.org Subject: Re: Adding support for Stateless Static NAT for TAP devices On Thu, Aug 30, 2012 at 10:27 AM, John Basila jbas...@checkpoint.com wrote: I have tried NAT and this is why I came up with this feature. QEMU's net/tap.c is the wrong place to add NAT code. The point of tap is to use the host network stack. If you want userspace networking, use -netdev user or -netdev socket. Please look into iptables more. I have CCed the netfilter mailing list. The question is: The host has several tap interfaces (tap0, tap1, ...) and the machine on the other end of each tap interface uses IP address 10.0.0.2. So we have: tap0 - virtual machine #0 (10.0.0.2) tap1 - virtual machine #1 (10.0.0.2) tap2 - virtual machine #2 (10.0.0.2) Because the virtual machines all use the same static IP address, they cannot communicate with each other or the outside world (they fight over ARP). We'd like to NAT the tap interfaces: tap0 - virtual machine #0 (10.0.0.2 NAT to 192.168.0.2) tap1 - virtual machine #1 (10.0.0.2 NAT to 192.168.0.3) tap2 - virtual machine #2 (10.0.0.2 NAT to 192.168.0.4) This would allow the virtual machines to communicate even though each believes it is 10.0.0.2. How can this be done using iptables and friends? Why do the systems have the same IP? That seems like a broken network config to me. Regards, Dennis Scanned by Check Point Total Security Gateway.
