From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BeRrf-0008PB-OK for qemu-devel@nongnu.org; Sun, 27 Jun 2004 01:06:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BeRre-0008Os-U4 for qemu-devel@nongnu.org; Sun, 27 Jun 2004 01:06:03 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BeRre-0008Oi-R8 for qemu-devel@nongnu.org; Sun, 27 Jun 2004 01:06:02 -0400 Received: from [38.113.3.51] (helo=snickers.hotpop.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BeRpx-0005ew-59 for qemu-devel@nongnu.org; Sun, 27 Jun 2004 01:04:17 -0400 Received: from phreaker.net (kubrick.hotpop.com [38.113.3.103]) by snickers.hotpop.com (Postfix) with SMTP id B9C367124E for ; Sun, 27 Jun 2004 04:01:02 +0000 (UTC) Date: Sun, 27 Jun 2004 01:01:11 -0400 From: "Jim C. Brown" Message-ID: <20040627050111.GA24787@jbrown.mylinuxbox.org> References: <20040626184535.GA19123@jbrown.mylinuxbox.org> <200406271007.11404.a_mulyadi@telkom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406271007.11404.a_mulyadi@telkom.net> Subject: [Qemu-devel] replies Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mulyadi Santosa Cc: qemu-devel@nongnu.org I thought that some of the information i said was of use to the list, so I post it here. I hope you don't mind. On Sun, Jun 27, 2004 at 10:07:11AM +0700, Mulyadi Santosa wrote: > > I didn't add in the use of tun0 because tun0 is for emulating the ip layer, > > while tap0 is used to emulate ethernet frames. VDE emulates a full nic, > > ethernet and all, at a lower level, so using vde_switch -tap tap0 is more > > consistent. > > Jim, Renzo, maybe the following questions is a bit OOT: Not really. > 1. If I don't use VDE, how can I tell Qemu to use "tap" instead of "tun"? Or > maybe this related with question: why Qemu by default use "tun" instead of > "tap"? >>From http://openvpn.sourceforge.net/tuntap.html: 6. What is the difference between TUN driver and TAP driver? TUN works with IP frames. TAP works with Ethernet frames. I don't know why qemu uses "tunX". You'd think it would be better off using the "tapX" device instead. "tunX" is like "tapX" only it is point-to-point (no ethernet frames). tun is meant for ip tunnelling and passes ip frames while tap is for ethernet tunnelling. If I understand right tunX will only support ip (and tcp/ip and udp/ip and etc) while tap also supports ipx, ipv6, etc. Not 100% sure on this point. renzo could probably answer better on this than I could. > > 2. Can I do traffic shaping / policing against TUN/TAP device attached to Qemu > guest system? And if I can do it, should I attach the shaper against tun/tap > or vde switch? > > Right now, I am playing with several QoS method (CBQ, HTB, SFQ) to control > traffic between Qemu guest system....and Qemu surely helps me to avoid messin > around with real PC :-) I assume this can be done. I don't know how as I'm not familar with traffic shaping. As for policy, I'm not sure what you mean. I run the shorewall firewall, and it has a default policy based on zones (such as local network, dmz, internet) which in turn are based on interfaces (eth0, eth1, ppp0). Default policy is to accept from local and drop from internet etc. I can put tap0 in the shorewall setup and it works fine. I don't know about tun. (shorewall is a shell script that works on top of iptables btw). > > 3. Do you know how to resize disk image? I have been looking for the answer on > Qemu mailing list archieve but nothing is found..... > This method only works for raw disk images! It will not work for actual hard disks/disk partitions or other disk image formats. Resizing along cylinder boundaries is easy. Assuming a geo of 16 heads, 63 sectors on a track, and 512 bytes per sector, you get 516096 bytes for each cylinder, or 504KB. (16 * 63 * 512 = 516096) Note that fdisk -lu will give us the 512 bytes per sector but not the rest of the info. You'll have to know the geo of your disk already (but it is usually #cyl,16,63). The heads, sectors per track, and bytes per sector are from the disk image you want to resize. Be sure to keep the original disk image after you've made the new one, just in case. Make an image larger: $ dd if=/dev/zero of=some-temp-file bs=516096 count= $ cat disk.img some-temp-file > newdisk.img newdisk.img will have the resized disk image (note that the partitions are not resized so you'll have to grow/add the new partitions manually). If you make some-temp-file 12 cylinders big, and disk.img was 200 cylinders big, newdisk.img is now 212 cylinders big. Also note that you'll have to pass qemu the -hdachs ,, option (for the above example it would be -hdachs 212,16,63), else weird things may happen. Make an image smaller: $ dd if=disk.img of=newdisk.img bs=516096 count= e.g. if disk.img is 200 cylinders long and you want to shrink it to 100 cylinders: $ dd if=disk.img of=newdisk.img bs=516096 count=100 Note: partitions do not have to end on a cylinder, so you may end up with the last part of the disk image filled with half a partition or something. It should be ok to just delete it but I'm not 100% sure. (It will be hard to trust your partition table after this.) To resize outside of cylinder boundaries is the same except for more math (to calculate the number of bytes you need to grow/shrink by and to calculate what to pass as the geo for -hdachs). Good luck! > NB: Jim, lomount rocks !! i send my "patch" because fdisk on Redhat box is > sending useless text before "Disk..."....in case you are wondering why I do > such a loop for detecting "Disk..." word I had the same problem. Of course I counted the number of lines that fdisk spit at me and hardcoded the number to skip.. it's possible that your fdisk spit out more. Your solution is better since it is more flexible. BTW why do you check for total sectors? This isn't needed (so removing it doesnt break anything) and it breaks on my fdisk v2.10s (also you scan for one extra line). Can I see the output of fdisk -lu and what your fdisk version is? Odds are good that lomount will need to know the fdisk version to correctly parse the output. > > regards > > Mulyadi -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.