[Qemu-devel] replies

["Jim C. Brown" <jbrown106@phreaker.net>]

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=<number of cylinders you wish to add>
$ 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 <cylinders>,<heads>,<sectors/track>
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=<number of cylinders to keep>

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.