Re: base format
Le jeu. 25 avr. 2024 à 15:13, Jakob Bohm via a écrit : > On 2024-04-25 14:51, lacsaP Patatetom wrote: > > Le jeu. 25 avr. 2024 à 11:30, Peter Maydell > <mailto:peter.mayd...@linaro.org>> a écrit : > > > > On Thu, 25 Apr 2024 at 09:55, lacsaP Patatetom > > mailto:patate...@gmail.com>> wrote: > > > > > > hi, > > > > > > when using `qemu-img create`, why do I have to specify the > > format of the base image ? > > > can't `qemu-img` detect it itself ? > > > > Image format detection isn't 100% reliable. Notably, a 'raw' > > format image could in theory look like any of the other > > image types if it happens to start with the right kind of data. > > > > thanks > > -- PMM > > > > > > OK for the raw format, which can be anything, but not for the qcow2 > > format, which is standardized (header). > > in the absence of details, `qemu-img` could use the qcow2 format by > > default ? > > > > qemu-img create [-b base [-F (qcow2*|raw)]] [-f (qcow2*|raw)] image > [size] > But it cannot safely tell if the base file (usually a raw image or raw > physical > disk partition) is qcow2 or araw file that just happens to begin with > the magic > bytes that represent qcow2. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > I understand the problem of the wrong format and that `qemu-img` therefore requires the image format to be specified. however, for the base image, it's the underlying layer that shouldn't be and won't be altered by the use of the newly created image, given that the latter is based on it. should it therefore be possible to specify the format of the base image as an option ? regards, lacsaP.
Re: base format
Le jeu. 25 avr. 2024 à 11:30, Peter Maydell a écrit : > On Thu, 25 Apr 2024 at 09:55, lacsaP Patatetom > wrote: > > > > hi, > > > > when using `qemu-img create`, why do I have to specify the format of the > base image ? > > can't `qemu-img` detect it itself ? > > Image format detection isn't 100% reliable. Notably, a 'raw' > format image could in theory look like any of the other > image types if it happens to start with the right kind of data. > > thanks > -- PMM > OK for the raw format, which can be anything, but not for the qcow2 format, which is standardized (header). in the absence of details, `qemu-img` could use the qcow2 format by default ? qemu-img create [-b base [-F (qcow2*|raw)]] [-f (qcow2*|raw)] image [size]
base format
hi, when using `qemu-img create`, why do I have to specify the format of the base image ? can't `qemu-img` detect it itself ? I understand that I have to specify the format of the created image, but I don't understand for the base image. `qemu-img create -b base.img -f qcow2 new.img` rather than `qemu-img create -b base.img -F qcow2 -f qcow2 new.img` regards, lacsaP.
qemu device_add helper
hi,
when I want to offer a smartphone to my virtual machine, I have to attach
it as "device_add usb-host,hostbus=X,hostport=Y,id=Z" otherwise, I lose the
attachment on the virtual machine side when I switch the smartphone mode (MTP,
USB connection sharing, etc...).
to avoid having to manually build the command line, I use this little bash
function that bypasses the "Command "info usbhost " is not available."
first warning and lets me quickly copy/paste :
usb-host() {
# qemu device_add helper
for usb in /sys/bus/usb/devices/[1-9]-[1-9]/
do
cat $usb/product
busport=$( basename $usb )
echo $(
sed -e 's/-/,hostport=/' \
-e 's/^/device_add usb-host,hostbus=/' \
-e 's/$/,id=id-'$busport/ <<< $busport
)
read vendor < $usb/idVendor
read product < $usb/idProduct
echo device_add
usb-host,vendorid=0x$vendor,productid=0x$product,id=id-$vendor-$product
echo
done
}
unfortunately, this function doesn't report all USB device information
("Integrated
Camera" and not "Chicony Electronics Co., Ltd Integrated Camera" for
example).
I hope you'll find it useful, regards, lacsaP.
Re: Directory does not fit in FAT16 (capacity 516.06 MB)
Le ven. 15 déc. 2023 à 11:39, Alberto Garcia a écrit : > On Fri, Dec 15, 2023 at 09:15:22AM +0100, lacsaP Patatetom wrote: > > here's a little script following the exchanges above. > > perhaps it will be useful to others... > > If you want a full disk image with its partition table I don't know if > you are aware that those tools can work with offsets, e.g.: > > $ truncate -s 500M disk.img > $ echo -e 'label:gpt\n2048,,U' | sfdisk disk.img > $ mkfs.fat --offset 2048 disk.img > $ mcopy -i disk.img@@1M -s /path/to/files :: > > where 2048 is the offset of the first partition (2048 sectors = 1MB) > > Berto > > it will be much more flexible this way :-) I was having trouble with mkfs.fat which, according to my man page, is supposed to accept the --offset option, but refuses it on the pretext that it's unknown... thank you.
Re: Directory does not fit in FAT16 (capacity 516.06 MB)
Le mer. 13 déc. 2023 à 17:32, Alberto Garcia a écrit :
> On Wed, Dec 13, 2023 at 04:33:00PM +0100, lacsaP Patatetom wrote:
> > having said that, and if you respect the constraints ("what you
> > should never do..."), vvfat is a really nice way of performing and
> > repeating quick tests without having to go through the process of
> > building/creating/updating disk images.
>
> While I agree with what you say here and I also think that it would be
> nice if that driver was maintained and had more features... really,
> creating a temporary FAT image of a few hundred MBs with some files
> inside takes less than a second in a modern computer, you can boot
> QEMU like this and you won't probably even notice the difference:
>
>$QEMU -drive if=ide,file=$(create-image.sh),driver=raw
>
> Berto
>
>
here's a little script following the exchanges above.
perhaps it will be useful to others...
don't hesitate to send your comments and feedback.
regards, lacsaP
```
#!/usr/bin/bash
# this script generates a 64MB GPT disk with a single 60MB EFI System
# partition formatted in FAT32
# the disk produced is "invalid", as it lacks the backup/spare GPT
# (qemu doesn't seem to work with disks smaller than 64MB)
prefix=/tmp/.$$
trap "rm -f $prefix.{gpt,fat,disk}" EXIT HUP INT TERM
# * GPT *
#
# $ gdisk -l tmpdisk
# …
# Found valid GPT with protective MBR; using GPT.
# Disk disk: 131072 sectors, 64.0 MiB
# Sector size (logical): 512 bytes
# Disk identifier (GUID): BEE772C8-89D8-49FC-8F5C-D4964108B9C5
# Partition table holds up to 128 entries
# Total free space is 8125 sectors (4.0 MiB)
# Number Start (sector)End (sector) Size Code Name
#12048 124927 60.0 MiBEF00 EFI system
partition
#
# # size = (sector_size * start_sector )
#
# $ head -c $((512 * 2048)) tmpdisk | zstd | base64
#
KLUv/QRYpAUAlAgAAAIA7iggCAEAAAD//wEAVapFRkkgUEFSVQBclJu5YgAi3shy
#
577YifxJj1zUlkEIucUCgHgdyq4ocyrBH/jSEbpLAKDJPsk7gV161JMdDUK+yxC+tnwJhQAI/+cB
#
RQBGAEkAIABzAHkAcwB0AGUAbQAgAHAAYQByAHQAaW8Abg8AkvsgB1bxeNc6OEOaa3g5UAEQE2mX
# b8ibhnyQOQtifQIxBiK1qwIsAgAQAAIAEAACABAAAgAQAAIAEAACABAAAwAQAMDAzBw=
#
( base64 -d | zstd -d > $prefix.gpt ) \
<<~~~
KLUv/aQAABAApAUAlAgAAAIA7iggCAEAAAD//wEAVapFRkkgUEFSVQBclJu5YgAi
3shy577YifxJj1zUlkEIucUCgHgdyq4ocyrBH/jSEbpLAKDJPsk7gV161JMdDUK+yxC+tnwJhQAI
/+cBRQBGAEkAIABzAHkAcwB0AGUAbQAgAHAAYQByAHQAaW8Abg8AkvsgB1bxeNc6OEOaa3g5UAEQ
E2mXb8ibhnyQOQtifQIxBiK1qwIsAgAQAAIAEAACABAAAgAQAAIAEAACABAAAwAQAMDAzBw=
~~~
# * FAT *
#
# # size = (end_sector - start_sector + 1) / 2 (KB)
#
rm -f $prefix.fat
mkfs.fat -C -F 32 -n 'ESP' -m '' -i $prefix.fat $(((124927 - 2048
+ 1) / 2))
mcopy -i $prefix.fat -Do -s ./esp/EFI ::
mdir -i $prefix.fat -/ -b ::
# * DISK
#
cat $prefix.{gpt,fat} > $prefix.disk
rm -f $prefix.{gpt,fat}
sync
# * QEMU
#
qemu-system-x86_64 \
-accel kvm \
-machine q35 \
-m 512 \
-bios /usr/share/ovmf/x64/OVMF.fd \
-drive file=$prefix.disk,format=raw
```
Re: Directory does not fit in FAT16 (capacity 516.06 MB)
Le mer. 13 déc. 2023 à 14:57, Thomas Huth a écrit :
> On 13/12/2023 13.51, Alberto Garcia wrote:
> > On Wed, Dec 13, 2023 at 01:27:49PM +0100, Narcis Garcia wrote:
> >> A FAT16 partition (0x06) can be as large as 2 GiB
> >
> > That's why I say that there's probably a limitation in the QEMU vvfat
> > driver.
>
> Yes, it's hard-coded somewhere here:
>
> https://gitlab.com/qemu-project/qemu/-/blob/v8.1.0/block/vvfat.c#L1195
>
> Anyway, it's not recommended to use vvfat anymore since it's very old and
> unmaintained code. If possible, use something like usb-mtp or virtio-fs
> instead.
>
> Thomas
>
>
>
not as old as FAT :-)
its non-maintenance can indeed be a source of problems.
however, it's still available in qemu and present in the documentation
without any contraindication.
having said that, and if you respect the constraints ("what you should
never do..."), vvfat is a really nice way of performing and repeating quick
tests without having to go through the process of
building/creating/updating disk images.
in my case, the efi application needs access to the tree structure present
in the ./esp/ folder, and I'm not sure that usb-mtp and virtio-fs are
suitable... I'll take a closer look at these two ideas, thanks.
Re: Directory does not fit in FAT16 (capacity 516.06 MB)
Le mer. 13 déc. 2023 à 13:29, Narcis Garcia a écrit : > A FAT16 partition (0x06) can be as large as 2 GiB > > > El 13/12/23 a les 12:23, Alberto Garcia ha escrit: > > On Wed, Dec 13, 2023 at 11:46:51AM +0100, lacsaP Patatetom wrote: > >> to quickly test my efi application `./esp/EFI/BOOT/BOOTX64.EFI`, I use > the > >> following command `qemu-system-x86_64 -accel kvm -machine q35 -m 1024 > -bios > >> /usr/share/edk2/x64/OVMF.fd -hda fat:./esp/ -snapshot` but it has > recently > >> failed with the error message given in subject. > > > > I'm not familiar with the QEMU vvfat driver, but FAT16 does allow > > larger filesystems, I suspect there's a limitation there? > > > >> for various reasons, i can't purge/reinitailize/empty the folder : > >> what other options do I have with qemu or do I have to start from a > >> lighter folder ? > > > > You can create a FAT image, put your files there using e.g mtools and > > boot from that image: > > > > $ fallocate -l 1G esp.img > > $ mformat -i esp.img > > $ mcopy -i esp.img -s /path/to/files :: > > > > Berto > > > > -- > Narcis Garcia > > 4Gb also seems possible : maximum size depends on cluster size. qemu probably uses 8Kb clusters, which limits the size to 512Mb.
Re: Directory does not fit in FAT16 (capacity 516.06 MB)
Le mer. 13 déc. 2023 à 12:24, Alberto Garcia a écrit : > On Wed, Dec 13, 2023 at 11:46:51AM +0100, lacsaP Patatetom wrote: > > to quickly test my efi application `./esp/EFI/BOOT/BOOTX64.EFI`, I use > the > > following command `qemu-system-x86_64 -accel kvm -machine q35 -m 1024 > -bios > > /usr/share/edk2/x64/OVMF.fd -hda fat:./esp/ -snapshot` but it has > recently > > failed with the error message given in subject. > > I'm not familiar with the QEMU vvfat driver, but FAT16 does allow > larger filesystems, I suspect there's a limitation there? > > > for various reasons, i can't purge/reinitailize/empty the folder : > > what other options do I have with qemu or do I have to start from a > > lighter folder ? > > You can create a FAT image, put your files there using e.g mtools and > boot from that image: > > $ fallocate -l 1G esp.img > $ mformat -i esp.img > $ mcopy -i esp.img -s /path/to/files :: > > Berto > > if possible, I'd like to avoid creating an image. I've just seen that the `qemu-system-x86_64 -accel kvm -machine q35 -m 1024 -bios /usr/share/edk2/x64/OVMF.fd -kernel ./esp/EFI/BOOT/BOOTX64.EFI` command works but abandons the tree structure.
Directory does not fit in FAT16 (capacity 516.06 MB)
hi, to quickly test my efi application `./esp/EFI/BOOT/BOOTX64.EFI`, I use the following command `qemu-system-x86_64 -accel kvm -machine q35 -m 1024 -bios /usr/share/edk2/x64/OVMF.fd -hda fat:./esp/ -snapshot` but it has recently failed with the error message given in subject. for various reasons, i can't purge/reinitailize/empty the folder : what other options do I have with qemu or do I have to start from a lighter folder ? regards, lacsaP.
Re: Building without network devices
Le mar. 5 déc. 2023 à 13:50, lacsaP Patatetom a écrit : > `-nic none` (see here > https://qemu.readthedocs.io/system/invocation.html#hxtool-5) > > Le mar. 5 déc. 2023 à 13:33, Talha Khan a écrit : > >> Hello all, >> I want to build an instance of qemu(x86-64) without any network devices >> in the emulator (no nic,no netdev or anything). Im new to all these, any >> help and leads would be usefull. >> >> Yours Talha >> > `-nic none` (see here https://qemu.readthedocs.io/en/v8.1.0/system/invocation.html#hxtool-5)
Re: Building without network devices
`-nic none` (see here https://qemu.readthedocs.io/system/invocation.html#hxtool-5) Le mar. 5 déc. 2023 à 13:33, Talha Khan a écrit : > Hello all, > I want to build an instance of qemu(x86-64) without any network devices in > the emulator (no nic,no netdev or anything). Im new to all these, any help > and leads would be usefull. > > Yours Talha >
Re: Question about FIDO key passthrough for testing in QEMU
Le ven. 26 mai 2023 à 03:01, skylarmylar via a écrit : > Hi! I am looking for instruction about using command line QEMU-KVM to > create VMs for testing Yubikey authentication of system initialization > stages, logins, and processes. If anyone can tell me where to find the > information I need to accomplish this, please let me know. I am exploring > the question in a forum here: > > https://discussion.fedoraproject.org/t/fido-and-fedora-yubikey-c-bio/82462/31 > Thanks! > > There is something more I need to do to make this command work. Do you > know what is needed? > > *sudo qemu-kvm -m 1024 -hda fedora.qcow -cdrom Fedora.iso -usb -device > u2f-passthru -boot d* > hi, find bus/port (or vid/pid) of your usb yubikey device with lsub (for example) and exec qemu with `-device usb-host,hostbus=X,hostport=Y` (or `-device usb-host,vendorid=0x,productid=0x`). regards.
qemu-img-tree
hi Qemu command line users,
`qemu-img` does not allow to have a light and tree-like view of a derived
image.
as I didn't find another solution on the Internet, I wrote this little bash
script which may be useful to some of you and which allows to obtain this :
$ qemu-img-tree /opt/virtual/test11.disk
/opt/virtual/test11.disk (QCOW2 - 995M / 64G)
└─ /opt/virtual/src/11+++ (QCOW2 - 813M / 64G)
└─ /opt/virtual/src/11++ (QCOW2 - 929M / 64G)
└─ /opt/virtual/src/11+ (QCOW2 - 1,3G / 64G)
└─ /opt/virtual/src/11 (QCOW2 - 8,8G / 64G)
this small script is based on `jq` and `numfmt` and displays the writeable
child images in red :
#!/usr/bin/bash
# helper
_exit(){ [ "$2" ] && echo $2 > /dev/stderr; exit $1; }
# check dependencies
type -a jq &> /dev/null || _exit 1 "jq (command-line JSON processor) is
missing"
type -a numfmt &> /dev/null || _exit 1 "numfmt (convert numbers from/to
human-readable) is missing"
# check image parameter
[ "$1" ] || _exit 1 "image file is missing (eg. $( basename "$0" )
image_file)"
# get image informations
image_info=$( qemu-img info --output=json "$1" )
if [ "$image_info" ]
then
# extract data
IFS=$'\n' read -srd '' virtual_size disk_size file_format backing_file < <(
jq -r '."virtual-size",."actual-size",."format",."full-backing-filename"'
<<< $image_info
)
# convert sizes
IFS=$'\n' read -srd '' virtual_size disk_size < <(
numfmt --to=iec $virtual_size $disk_size
)
# check backing file for write (red)
[ "$2" ] && [ -w "$1" ] && tput setaf 3
# print image informations (aligned/colored)
echo "$2$1 (${file_format^^} - $disk_size / $virtual_size)" && tput sgr0
# call script on backing file (if any)
[ "$backing_file" != "null" ] && "$0" "$backing_file" " ${2:-└─ }"
fi
hope this help, regards, lacsaP.
qemu-img-tree
Description: Binary data
Re: hubport connectivity problems
Le mar. 28 mars 2023 à 19:53, Eric Nichols (DirWiz) a écrit : > > Many thanks to both for the info and the helpful advice. On linux both > solutions worked amazingly well. > > I have a few pieces of feedback on the windows version fwiw. > > Thomas's solution of using socket worked on windows except the window's > firewall wanted to build in some exceptions. The quick fix was to use: > listen=127.0.0.1:1234 > > lacsaP the mcast stuff on windows errored: > can't bind ip=239.192.168.1 to socket unknown error > > I did a bit of googling and found a possible issue with windows and > mcast: > https://serverfault.com/questions/1002977/cannot-create-qemu-socket-networking-in-windows-host-using-multicast-fails-with > > It would be wonderful to re-imagine hubport as a virtual switch across > multiple running VM's and handle all this socket/mcast complexity > internally and away from the OS. Bonus points if you could merge this > new idea for hubport with SLIRP! > > Many thanks again! > Eric > > > On 3/28/23 6:05 AM, lacsaP Patatetom wrote: > > Le mar. 28 mars 2023 à 09:36, Thomas Huth a écrit : > >> > >> On 27/03/2023 21.52, Eric Nichols (DirWiz) via wrote: > >>> Long time user, first time poster... > >>> > >>> My setup is simple. Debian host running qemu 7.2.0 and 2 guest (Windows > >>> 2010 workstation & 2022 server). My goal is to setup a private guest only > >>> network (no connection to host) with hubport. > >>> > >>> Based on the docs I've tried: > >>> -netdev hubport,hubid=0,id=hub0 -device virtio-net-pci,netdev=hub0 > >>> > >>> There is also the second option of: > >>> -nic hubport,hubid=0,model=virtio-net-pci > >>> > >>> And also small mention that a hubport 0 will be setup if you just use a > >>> virtual adapter and don't connect it to anything: > >>> -net nic,model=virtio-net-pci,macaddr=52:54:00:00:00:03 > >>> > >>> I did static IPs on both of the guests but can't ping or connect over TCP. > >>> Any ideas? > >> > >> hubport basically emulates a hub *within* one instance of QEMU. Hubport > >> alone does not connect to any other QEMU (i.e. guest) instance. It's mostly > >> a legacy concept from the early days of QEMU - and unless you want to > >> connect multiple NICs of one guest together, you likely don't need it. (see > >> also https://www.qemu.org/2018/05/31/nic-parameter/ for some more > >> information). > >> > >> If you want to connect two local guests via a local network, you could have > >> a look at the "-netdev socket" option. For example, start one QEMU with > >> "-nic socket,model=virtio-net-pci,id=net0,listen=:1234" and the other QEMU > >> with "-nic socket,model=virtio-net-pci,id=net1,connect=:1234" and you > >> should > >> be able to see the network traffic of one guest on the interface of the > >> other and vice versa. > >> > >>HTH, > >> Thomas > >> > >> > >> > > hi, if you need more than 2 guests, you can start virtual machines > > connected on the same virtual network bus : > > > > qemu \ > >-drive file=hd1.img,media=disk \ > >-nic socket,mac=52:54:00:11:11:11,mcast=239.192.168.1:1101 > > qemu \ > >-drive file=hd2.img,media=disk \ > >-nic socket,mac=52:54:00:22:22:22,mcast=239.192.168.1:1101 > > qemu \ > >-drive file=hd3.img,media=disk \ > >-nic socket,mac=52:54:00:33:33:33,mcast=239.192.168.1:1101 > > > > regards, lacsaP. thanks for W$ feedback. on Linux, I also use VDE switch (which corresponds somewhat to the desired hubport) to connect my VMs (https://github.com/virtualsquare/vde-2) vde_switch -d qemu \ -drive file=hd1.img,media=disk \ -nic vde,mac=52:54:00:11:11:11 qemu \ -drive file=hd2.img,media=disk \ -nic vde,mac=52:54:00:22:22:22 I used to add slirpvde for dhcp but it has been abandoned : I now use dnsmasq@tap0 (https://github.com/virtualsquare/vde-2/issues/39) regards, lacsaP.
Re: hubport connectivity problems
Le mar. 28 mars 2023 à 09:36, Thomas Huth a écrit : > > On 27/03/2023 21.52, Eric Nichols (DirWiz) via wrote: > > Long time user, first time poster... > > > > My setup is simple. Debian host running qemu 7.2.0 and 2 guest (Windows > > 2010 workstation & 2022 server). My goal is to setup a private guest only > > network (no connection to host) with hubport. > > > > Based on the docs I've tried: > > -netdev hubport,hubid=0,id=hub0 -device virtio-net-pci,netdev=hub0 > > > > There is also the second option of: > > -nic hubport,hubid=0,model=virtio-net-pci > > > > And also small mention that a hubport 0 will be setup if you just use a > > virtual adapter and don't connect it to anything: > > -net nic,model=virtio-net-pci,macaddr=52:54:00:00:00:03 > > > > I did static IPs on both of the guests but can't ping or connect over TCP. > > Any ideas? > > hubport basically emulates a hub *within* one instance of QEMU. Hubport > alone does not connect to any other QEMU (i.e. guest) instance. It's mostly > a legacy concept from the early days of QEMU - and unless you want to > connect multiple NICs of one guest together, you likely don't need it. (see > also https://www.qemu.org/2018/05/31/nic-parameter/ for some more > information). > > If you want to connect two local guests via a local network, you could have > a look at the "-netdev socket" option. For example, start one QEMU with > "-nic socket,model=virtio-net-pci,id=net0,listen=:1234" and the other QEMU > with "-nic socket,model=virtio-net-pci,id=net1,connect=:1234" and you should > be able to see the network traffic of one guest on the interface of the > other and vice versa. > > HTH, >Thomas > > > hi, if you need more than 2 guests, you can start virtual machines connected on the same virtual network bus : qemu \ -drive file=hd1.img,media=disk \ -nic socket,mac=52:54:00:11:11:11,mcast=239.192.168.1:1101 qemu \ -drive file=hd2.img,media=disk \ -nic socket,mac=52:54:00:22:22:22,mcast=239.192.168.1:1101 qemu \ -drive file=hd3.img,media=disk \ -nic socket,mac=52:54:00:33:33:33,mcast=239.192.168.1:1101 regards, lacsaP.
