qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] VDE HOWTO version 0.1
@ 2004-06-26 18:45 Jim C. Brown
       [not found] ` <200406271007.11404.a_mulyadi@telkom.net>
  0 siblings, 1 reply; 9+ messages in thread
From: Jim C. Brown @ 2004-06-26 18:45 UTC (permalink / raw)
  To: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

Here is the next verion. Changes from Revision 1 added in. Added update on
Minix (nothing very big) and on ifconfig. Nothing major.

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.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

[-- Attachment #2: qemu-vde-HOWTO --]
[-- Type: text/plain, Size: 7580 bytes --]

Using VDE with Qemu HOWTO
by Jim Brown
26 June 2004
Version 0.1

-----------------------------------------------------------------------------

Introduction
	Copyright
	What is qemu?
	What is VDE?

Configuring and Installing VDE
	Installation
	vdeq & vdeqemu

User-mode networking
	How to enable user-mode networking
	Firewall configuration

Setting up qemu
	How to set up the guest OS

Credits

-----------------------------------------------------------------------------

Introduction

Copyright

Copyright (c) 2004 Jim Brown.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts.  A copy of the license is available at http://www.gnu.org/licenses/fdl.txt

What is qemu?

	Qemu is a FAST! processor emulator by Fabrice Bellard, available at
http://fabrice.bellard.free.fr/qemu/. It is capable of emulationg the x86 and
PowerPC processors with support for other processors on the way. The original
purpose of qemu was to allow running x86-specific Linux applications, such as
WINE or DosEmu, on non-x86 systems. However, qemu has expanded into becoming
a full-fledged emulator. On the x86 side, it is capable of running Linux,
MS-DOS, Windows 95/98/Me, Windows NT/2k, Windows XP, Solaris, OpenBSD, and
FreeBSD. See http://fabrice.bellard.free.fr/qemu/ossupport.html for the full
listing.

	This howto assumes that you have already installed and set up qemu.

What is VDE?

	VDE is short for Virtual Distributed Ethernet. VDE, written by
Renzo Davoli, is based off of uml_switch by Jeff Dike. It is available at
http://sourceforge.net/projects/vde/. It has many uses, the main one providing
support for networking with emulated computers. (Not just qemu, but support
for user-mode linux and Bochs also exists). VDE must be set up and installed by
root, but the programs which use it do not need root privligies.

	This howto will walk you through the simple process of installing
VDE and setting up qemu to use it.

-----------------------------------------------------------------------------

Configuring and Installing VDE

Installation

	You may obtain the source code at http://sourceforge.net/projects/vde/.
The version of VDE which I used was 1.4.1, but this HOWTO should apply to all
versions.

	Once you have downloaded the source code, extract it. I assume you
will have extracted it to /space/vde. Go into that directory, and simply type
"make" followed by "make install". Now you should have vde_switch in /usr/bin.

vdeq & vdeqemu

	Now cd into the qemu directory. Type "make". This will build vdeq.
Qemu on its own only supports full networking with tuntap, which requires
root priviliges or an exposed /dev/net/tun. There is a -user-net option, but
that is not as useful as full networking. In order for qemu to use VDE, it must
be passed the file descriptor for a tun device. Futhermore the tun device itself
must already be configured to use VDE. vdeq sets this up and passes it to qemu
via the -tun-fd switch.

	There is no "make install". Instead, you just manually copy vdeq to
/usr/bin. It might also be helpful to copy or link vdeq to vdeqemu. vdeq
requires that the location of the qemu binary be passes to it as the first
command line parameter, but vdeqemu only needs the options you want to pass to
qemu. vdeqemu will locate the qemu binary itself (this requires that you install
qemu system-wide or have the qemu directory in your PATH).

For example if you have:
vdeq qemu -hda /mnt/myimage -m 64 -boot a

you can shorten this into

vdeqemu -hda /mnt/myimage -m 64 -boot a

-----------------------------------------------------------------------------

User-mode Networking

How to enable user-mode networking

	The following commands will need to be run as root:

# vde_switch -tap tap0 -daemon

If you need to run a sniffer, just in case you want to analyze the traffic,
you can also run it like this:

# vde_switch -hub -tap tap0 -daemon

(The -hub option is not available for version 1.4.1 of VDE, you will need a
later version. I don't know what the minimal version is but 1.5.1 does support
this option.)

Then you must run this:

# ifconfig tap0 <ip>
# chmod 755 /tmp/vde.ctl

	The vde_switch command will run VDE in the background. The -tap tap0
parameter tells VDE to set up the device tap0 using tuntap. -daemon runs
vde_switch in the background. -hub tells VDE to broadcast the message to all 
segment, just like real hub that you use on real network.

	<ip> is the ip address of the gateway you want to use for the guest
OS(es). For example:

# ifconfig tap0 192.168.254.254

	will make 192.168.254.254 the gateway between guest and host, and your 
guest OS(es) will belong to the subnet 192.168.254.0 with a netmask of 255.255.255.0 
and an ip address of 192.168.254.XXX (where you get to pick the XXX). You must have
the IP of the qemu guest and the IP of the gateway on the same subnet! While it
may be possible to have them on separate subnets, it will certainly be harder
to configure (and you won't like the way your routing tables will look either).

[Sidebar: The "gateway" is actually the host OS itself on the tap0 interface.
The host on the tap0 interface, aka 192.168.254.254, routes between the guest
OS and the host's eth0 interface (which on is the real network). The host on the
eth0 interface (ex. 192.168.0.2) can then route between the tap0 interface and
the real network / the internet.]

(Note that you might be required to do this:

# ifconfig tap0 192.168.254.254 netmask 255.255.255.0

Normally ifconfig should pick the correct netmask for you, but if it doesn't
for some reason then you will have to specify it manually. See ifconfig(8) for
details.

)

Note that you must run this before you run your firewall. I found it helpful
to put this into a script, and have the script load before the firewall does.

Firewall configuration

	You will need to enable masquerading between tap0 and your local area
network (for example, eth0). You will also need to enable masquerading between
tap0 and ppp0 if you use a dialup connection to the internet. The commands

# echo "1" > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

	will allow you to enable this manually.

-----------------------------------------------------------------------------

Setting up qemu

How to set up the guest OS

	Set up the guest OS so that the default route is through the gateway
ip, <ip> (for example 192.168.254.254). Also set up the subnet and netmask
parameters as appropriate (for example 192.168.254.0 and 255.255.255.0).
The guest OS should see the ethernet device and be able to use it to access
the gateway. (Caveat: I haven't been able to do this for MS-DOS, and for Minix
2.0.4 I had to apply a patch to qemu since Minix is broken. Uodate: Minix 2.0.4
is still broken but a patch has been released to fix it. Using this patch,
Minix works on a vanilla qemu.) Also don't forget to set up the IP of the guest
OS itself (for example 192.168.254.1).

-----------------------------------------------------------------------------

Credits

	This HOWTO relied heavily on the documentation that Renzo wrote for
vde-1.4.1.
	Thanks to Mulyadi Santosa for helping with the first revision of
this document, and to Renzo for his input. (P.S. Will add info for ale4net
and slirpvde as soon as I figure out how to use it ;)


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Qemu-devel] replies
       [not found] ` <200406271007.11404.a_mulyadi@telkom.net>
@ 2004-06-27  5:01   ` Jim C. Brown
  2004-06-27  5:21     ` Renzo Davoli
  2004-06-27  7:12     ` [Qemu-devel] replies Mulyadi Santosa
  0 siblings, 2 replies; 9+ messages in thread
From: Jim C. Brown @ 2004-06-27  5:01 UTC (permalink / raw)
  To: Mulyadi Santosa; +Cc: qemu-devel

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] replies
  2004-06-27  5:01   ` [Qemu-devel] replies Jim C. Brown
@ 2004-06-27  5:21     ` Renzo Davoli
  2004-06-27  7:04       ` Renzo Davoli
  2004-06-27  7:12     ` [Qemu-devel] replies Mulyadi Santosa
  1 sibling, 1 reply; 9+ messages in thread
From: Renzo Davoli @ 2004-06-27  5:21 UTC (permalink / raw)
  To: qemu-devel

> 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.

Tap would be the more appropriate as entire packets with data-link header 
are exchanged.
> 
> > 
> > 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? 
> > 
VDE does not handle traffic shaping/filtering. It is an emulated
Ethernet with switches and cables. Consistently with the real world
counterpart it is not its role to do that.

You can do filtering/shaping on the linux box that works as a router.
Tap0 for it is a standard interface thus all the iptables options can be
applied.
> 
I am leaving for a conference. Dunno how frequently I'll be able to read
my mail and answer....

If you have spare time and need something to read for the sleep instead
of counting jumping sheeps, I have published a techreport on VDE (no
commands, philosophy only, what you can do with it) 
http://www.cs.unibo.it/techreports/2004/2004-12.pdf

ciao
	renzo

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] replies
  2004-06-27  5:21     ` Renzo Davoli
@ 2004-06-27  7:04       ` Renzo Davoli
  2004-06-27 17:33         ` Jim C. Brown
  0 siblings, 1 reply; 9+ messages in thread
From: Renzo Davoli @ 2004-06-27  7:04 UTC (permalink / raw)
  To: qemu-devel

> Tap would be the more appropriate as entire packets with data-link header 
> are exchanged.
I mean, tun or tap are just names, the interfaces within vde or qemu
(AFAIK) are opened as "IFF_TAP" so they are tap even when named tun.

renzo

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Qemu-devel] Re: replies
  2004-06-27  5:01   ` [Qemu-devel] replies Jim C. Brown
  2004-06-27  5:21     ` Renzo Davoli
@ 2004-06-27  7:12     ` Mulyadi Santosa
  2004-06-27 18:26       ` Jim C. Brown
  1 sibling, 1 reply; 9+ messages in thread
From: Mulyadi Santosa @ 2004-06-27  7:12 UTC (permalink / raw)
  To: Jim C. Brown; +Cc: qemu-devel

Hello Jim :-)

> 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.
No problem....go ahead....i love open discussion...it is just me that ... at 
the first time I think better to talk about it head to head :-)

> 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.

:-) Oh geez, maybe I forgot to by "bypass" total sector :-)
BTW, here is output of fdisk -lu /mnt/qemu/myimage (my fdisk version is v2.11y 
on RH 9 GPL edition):
[[Start of Output]]
You must set cylinders.
You can do this from the extra functions menu.

Disk /mnt/qemu/myimage: 0 MB, 0 bytes
16 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes

            Device Boot    Start       End    Blocks   Id  System
/mnt/qemu/myimage1   *        63   1016063    508000+  83  Linux
/mnt/qemu/myimage2       1016064   1228751    106344   82  Linux swap
Partition 2 has different physical/logical endings:
     phys=(1023, 15, 63) logical=(1218, 15, 63)
[[end of output]]

Maybe it is caused by version difference in fdisk, what do you think?

NB: Jim, maybe we can do "tag team" again on disk resizing......how do you 
think? I will write resizer once I have spare time ASAP...but first I will 
follow your tips for resizing raw disk image

regards

Mulyadi

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] replies
  2004-06-27  7:04       ` Renzo Davoli
@ 2004-06-27 17:33         ` Jim C. Brown
  0 siblings, 0 replies; 9+ messages in thread
From: Jim C. Brown @ 2004-06-27 17:33 UTC (permalink / raw)
  To: qemu-devel

On Sun, Jun 27, 2004 at 09:04:53AM +0200, Renzo Davoli wrote:
> > Tap would be the more appropriate as entire packets with data-link header 
> > are exchanged.
> I mean, tun or tap are just names, the interfaces within vde or qemu
> (AFAIK) are opened as "IFF_TAP" so they are tap even when named tun.
> 
> renzo
> 

If that is the case, then qemu should be naming the devices as "tap0",
"tap1", etc. To open a TAP device with the name of "tun0" is just plain
confusing. (Unless we want to go "qemu0", "qemu1", etc.)

> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Qemu-devel] Re: replies
  2004-06-27  7:12     ` [Qemu-devel] replies Mulyadi Santosa
@ 2004-06-27 18:26       ` Jim C. Brown
  2004-06-28  1:30         ` Damien Mascord
  0 siblings, 1 reply; 9+ messages in thread
From: Jim C. Brown @ 2004-06-27 18:26 UTC (permalink / raw)
  To: Mulyadi Santosa; +Cc: qemu-devel

On Sun, Jun 27, 2004 at 02:12:07PM +0700, Mulyadi Santosa wrote:
> Hello Jim :-)
> 
> > 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.
> 
> :-) Oh geez, maybe I forgot to by "bypass" total sector :-)
> BTW, here is output of fdisk -lu /mnt/qemu/myimage (my fdisk version is v2.11y 
> on RH 9 GPL edition):
> [[Start of Output]]
> You must set cylinders.
> You can do this from the extra functions menu.
> 
> Disk /mnt/qemu/myimage: 0 MB, 0 bytes
> 16 heads, 63 sectors/track, 0 cylinders, total 0 sectors

I get this:

Disk mnx2.img: 0 heads, 0 sectors, 0 cylinders

I am curious ... how does your fdisk know what the heads and sectors/track are?

> Units = sectors of 1 * 512 = 512 bytes

For this line, mine only shows:

Units = sectors of 1 * 512 bytes

Your fdisk is better ... it does the math for us ;)

> 
>             Device Boot    Start       End    Blocks   Id  System
> /mnt/qemu/myimage1   *        63   1016063    508000+  83  Linux
> /mnt/qemu/myimage2       1016064   1228751    106344   82  Linux swap

> Partition 2 has different physical/logical endings:
>      phys=(1023, 15, 63) logical=(1218, 15, 63)
> [[end of output]]

That I don't get ... but thats probably because my fdisk has no clue what the
geometry is (when I tell it, I get a ton of those errors).

> 
> Maybe it is caused by version difference in fdisk, what do you think?

Clearly so. Now we just need to figure out what to do about it... having
lomount support several different fdisk output formats is possible, but tricky.

> 
> NB: Jim, maybe we can do "tag team" again on disk resizing......how do you 
> think? I will write resizer once I have spare time ASAP...but first I will 
> follow your tips for resizing raw disk image

It took me a bit of experimentation to figure out how to do all of that. I too
was unable to find any information on this topic while searching (the closest
I can was the tool that comes with DOSMinix to resize DOSMinix images ...
DOSMinix uses raw disk images as well, so that's where I got the idea from).

Writing a disk resizer wouldn't be terribly difficult. All it needs to do
is add zeros to grow the disk image, or truncate it when we are shrinking.
The hard part is getting the geometry right. I wouldn't know how to do this
myself. (You would have to make sure that the new geometry doesn't end up
messing up the ordering of the sectors, and you also need to write out the
new geometry somewhere on the disk image).

[Be careful tho ... resizing raw disk images can be very tricky (if you're
growing its not such a big deal (who cares abou a few unusable kb at the end of
the disk) but when you are shrinking you have to be very careful). Of course,
its easier than merging 2 disk images together (I still haven't figured out
how that's done).]

> 
> regards
> 
> Mulyadi

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] Re: replies
  2004-06-27 18:26       ` Jim C. Brown
@ 2004-06-28  1:30         ` Damien Mascord
  2004-06-28  2:23           ` Jim C. Brown
  0 siblings, 1 reply; 9+ messages in thread
From: Damien Mascord @ 2004-06-28  1:30 UTC (permalink / raw)
  To: qemu-devel

Hi guys,

Excuse my ignorance, but would there be an fdisk library that you could 
just call the functions, or even duplicate the functionality that you 
need from fdisk into a binary of your own ?  Because it is possible that 
a new version of fdisk will change it's screen output and "wreck" lomount...

Damien

Jim C. Brown wrote:
> On Sun, Jun 27, 2004 at 02:12:07PM +0700, Mulyadi Santosa wrote:
> 
>>Hello Jim :-)
>>
>>
>>>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.
>>
>>:-) Oh geez, maybe I forgot to by "bypass" total sector :-)
>>BTW, here is output of fdisk -lu /mnt/qemu/myimage (my fdisk version is v2.11y 
>>on RH 9 GPL edition):
>>[[Start of Output]]
>>You must set cylinders.
>>You can do this from the extra functions menu.
>>
>>Disk /mnt/qemu/myimage: 0 MB, 0 bytes
>>16 heads, 63 sectors/track, 0 cylinders, total 0 sectors
> 
> 
> I get this:
> 
> Disk mnx2.img: 0 heads, 0 sectors, 0 cylinders
> 
> I am curious ... how does your fdisk know what the heads and sectors/track are?
> 
> 
>>Units = sectors of 1 * 512 = 512 bytes
> 
> 
> For this line, mine only shows:
> 
> Units = sectors of 1 * 512 bytes
> 
> Your fdisk is better ... it does the math for us ;)
> 
> 
>>            Device Boot    Start       End    Blocks   Id  System
>>/mnt/qemu/myimage1   *        63   1016063    508000+  83  Linux
>>/mnt/qemu/myimage2       1016064   1228751    106344   82  Linux swap
> 
> 
>>Partition 2 has different physical/logical endings:
>>     phys=(1023, 15, 63) logical=(1218, 15, 63)
>>[[end of output]]
> 
> 
> That I don't get ... but thats probably because my fdisk has no clue what the
> geometry is (when I tell it, I get a ton of those errors).
> 
> 
>>Maybe it is caused by version difference in fdisk, what do you think?
> 
> 
> Clearly so. Now we just need to figure out what to do about it... having
> lomount support several different fdisk output formats is possible, but tricky.
> 
> 
>>NB: Jim, maybe we can do "tag team" again on disk resizing......how do you 
>>think? I will write resizer once I have spare time ASAP...but first I will 
>>follow your tips for resizing raw disk image
> 
> 
> It took me a bit of experimentation to figure out how to do all of that. I too
> was unable to find any information on this topic while searching (the closest
> I can was the tool that comes with DOSMinix to resize DOSMinix images ...
> DOSMinix uses raw disk images as well, so that's where I got the idea from).
> 
> Writing a disk resizer wouldn't be terribly difficult. All it needs to do
> is add zeros to grow the disk image, or truncate it when we are shrinking.
> The hard part is getting the geometry right. I wouldn't know how to do this
> myself. (You would have to make sure that the new geometry doesn't end up
> messing up the ordering of the sectors, and you also need to write out the
> new geometry somewhere on the disk image).
> 
> [Be careful tho ... resizing raw disk images can be very tricky (if you're
> growing its not such a big deal (who cares abou a few unusable kb at the end of
> the disk) but when you are shrinking you have to be very careful). Of course,
> its easier than merging 2 disk images together (I still haven't figured out
> how that's done).]
> 
> 
>>regards
>>
>>Mulyadi
> 
> 


-- 
Damien Mascord (tusker at tusker dot org)
GPG key 2CB181BE / 93B2 EF21 0C7C F022 F467  7966 219E 92B3 2CB1 81BE

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] Re: replies
  2004-06-28  1:30         ` Damien Mascord
@ 2004-06-28  2:23           ` Jim C. Brown
  0 siblings, 0 replies; 9+ messages in thread
From: Jim C. Brown @ 2004-06-28  2:23 UTC (permalink / raw)
  To: qemu-devel

On Mon, Jun 28, 2004 at 09:30:01AM +0800, Damien Mascord wrote:
> Hi guys,
> 

> Because it is possible that 
> a new version of fdisk will change it's screen output and "wreck" 
> lomount...

That's the problem that we have here. Though it would be a trivial fix, it is
still rather inconvient to have to update lomount everytime a new vesrsion
comes out.

> Excuse my ignorance, but would there be an fdisk library that you could 
> just call the functions, or even duplicate the functionality that you 
> need from fdisk into a binary of your own ? 

Right now, lomount is basicly a wrapper. (I originally meant to write it as a
shell script in fact, but I couldn't figure out how to parse fdisk's output.
Right now that is what I'm trying to do (using awk for the actual parsing).)
The Right Thing(tm) to do would be to replace the code that parses fdisk's
output with code ripped from fdisk, qemu, or even to use libparted.so, and
use that code to read the disk image and calculate the values that we need.
(We can go futher and have lomount make the mount(2) call by itself instead
of merely calling mount(8), if we wanted to.)

This is not a trivial change. But it would certainly be worthwhile.

> 
> Damien
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2004-06-28  2:28 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-06-26 18:45 [Qemu-devel] VDE HOWTO version 0.1 Jim C. Brown
     [not found] ` <200406271007.11404.a_mulyadi@telkom.net>
2004-06-27  5:01   ` [Qemu-devel] replies Jim C. Brown
2004-06-27  5:21     ` Renzo Davoli
2004-06-27  7:04       ` Renzo Davoli
2004-06-27 17:33         ` Jim C. Brown
2004-06-27  7:12     ` [Qemu-devel] replies Mulyadi Santosa
2004-06-27 18:26       ` Jim C. Brown
2004-06-28  1:30         ` Damien Mascord
2004-06-28  2:23           ` Jim C. Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).