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.
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.
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: 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.
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: 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)
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: 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.
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 à 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 à 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 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.
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.
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.
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]
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: Windows 11 24H2
Le mar. 29 oct. 2024 à 16:09, lacsaP Patatetom a écrit : > Le mar. 29 oct. 2024 à 15:52, lacsaP Patatetom a > écrit : > >> hi, >> >> in order to have “portable” VMs, I used to install them with Qemu's `-cpu >> qemu64` option, but it turns out that the Windows 11 24H2 installation CD >> no longer boots with this option : do you know which CPU flag to use to >> maintain the desired "portability"* ? >> >> note that Windows 11 24H2 boots without any problem if I pass it the >> `-cpu host` option, and Windows 23H2 boots without any problem with the >> `-cpu qemu64` option. >> >> (* boot the VM on both Intel and AMD without it having to reconfigure >> itself) >> >> regards, lacsaP. >> > > using older and older emulated Intel processors, Windows 24H2 installation > CD boots with the `-cpu Nehalem` option. > > `-cpu Nehalem` (2008) -> OK > `-cpu Penryn` (2007) -> KO > `-cpu Conroe` (2006) -> KO > `-cpu qemu64` -> KO > > dates are those given in Qemu documentation ( > https://qemu.readthedocs.io/en/v9.1.0/system/i386/cpu.html#preferred-cpu-models-for-intel-x86-hosts > ). > a little Googling returned the answer : " Microsoft blocks some PCs from Windows 11 24H2 - CPU must support SSE4.2 or the OS will not boot ". https://www.tomshardware.com/software/windows/microsoft-updates-windows-11-24h2-requirements-cpu-must-support-sse42-or-the-os-will-not-boot https://jensd.be/2547/windows/upgrade-to-or-install-windows-11-24h2-on-unsupported-hardware so `-cpu qemu64,+sse4.2` does the job !
Re: Windows 11 24H2
Le mar. 29 oct. 2024 à 15:52, lacsaP Patatetom a écrit : > hi, > > in order to have “portable” VMs, I used to install them with Qemu's `-cpu > qemu64` option, but it turns out that the Windows 11 24H2 installation CD > no longer boots with this option : do you know which CPU flag to use to > maintain the desired "portability"* ? > > note that Windows 11 24H2 boots without any problem if I pass it the `-cpu > host` option, and Windows 23H2 boots without any problem with the `-cpu > qemu64` option. > > (* boot the VM on both Intel and AMD without it having to reconfigure > itself) > > regards, lacsaP. > using older and older emulated Intel processors, Windows 24H2 installation CD boots with the `-cpu Nehalem` option. `-cpu Nehalem` (2008) -> OK `-cpu Penryn` (2007) -> KO `-cpu Conroe` (2006) -> KO `-cpu qemu64` -> KO dates are those given in Qemu documentation ( https://qemu.readthedocs.io/en/v9.1.0/system/i386/cpu.html#preferred-cpu-models-for-intel-x86-hosts ).
Windows 11 24H2
hi, in order to have “portable” VMs, I used to install them with Qemu's `-cpu qemu64` option, but it turns out that the Windows 11 24H2 installation CD no longer boots with this option : do you know which CPU flag to use to maintain the desired "portability"* ? note that Windows 11 24H2 boots without any problem if I pass it the `-cpu host` option, and Windows 23H2 boots without any problem with the `-cpu qemu64` option. (* boot the VM on both Intel and AMD without it having to reconfigure itself) regards, lacsaP.
bash qemu helpers
hi, here's some bash helpers around/for qemu, that I hope you'll find useful. https://github.com/patatetom/qemu-helpers regards, lacsaP.
Re: #!shebang
Le mer. 20 nov. 2024 à 10:37, lacsaP Patatetom a écrit : > hi, > > I'd like to use an executable file as a configuration file for `qemu` > using a shebang : let me explain. > > I currently store my configuration like this in `configuration.qemu` : > ``` > -argument > > - argument -option > > -etc... > ``` > > and I call `qemu` like this and it works as expected : > `$ qemu $( > which corresponds to the following command line : > `$ qemu -argument -argument -option -etc...` > > I can also add additional/temporary arguments/options on the command line > if I wish. > > I'd like to add comments to this configuration file : > ``` > # this is a configuration file for... > > -argument > > # this option... > -argument -option > > # add your own arguments/options here... > -etc... > ``` > > but passed directly in this way, these comments become arguments/options > for `qemu` : > ``` > $ qemu $( qemu-system-x86_64: # this is a configuration file for...: Could not open > '# this is a configuration file for...': No such file or directory > ``` > > I can eliminate them using `grep` like this : > `$ qemu $(grep -v '^#' configuration.qemu)` > > but it seems to me complicated and time-consuming to enter. > > so I wanted to use `grep` as shebang : > ``` > #!/usr/bin/grep -v '^#' > # this is a configuration file for... > > -argument > > # this option... > -argument -option > > # add your own arguments/options here... > -etc... > ``` > > but it doesn't work as I'd hoped : > ``` > $ qemu $(./configuration.qemu) > /usr/bin/grep: invalid option -- ' ' > Usage: grep [OPTION]... PATTERNS [FILE]... > Try 'grep --help' for more information. > ``` > > does anyone have an explanation or another way to get a commented > configuration file ? > > regards, lacsaP. > `#!/usr/bin/env -S grep -v '^#'` as shebang works like a charm :-) (with env (GNU coreutils) 9.5) regards, lascaP.
#!shebang
hi, I'd like to use an executable file as a configuration file for `qemu` using a shebang : let me explain. I currently store my configuration like this in `configuration.qemu` : ``` -argument - argument -option -etc... ``` and I call `qemu` like this and it works as expected : `$ qemu $(
Re: "relaxed" `-hda file.qcow2` equivalent ?
Le ven. 15 nov. 2024 à 15:21, Frantisek Rysanek a écrit : > > And, I have an idea: rather than refer to driver=qcow2 and > > file.filename, how about referring to the loopback device (NBD) that > > you already have, courtesy of qemu-nbd ? Would that perhaps circumvent > > the file lock? ;-) > > > > -blockdev node-name=xy,driver=raw,file.driver=host_device,\ > > file.filename=/dev/loop0,file.locking=off > > > > -device virtio-scsi-pci -device scsi-hd,drive=xy > > > > I mean: the QEMU device emulation would not run on top of the QCOW > file directly (and the underlying filesystem, and its locking > feature), but would instead share a block device with your host-side > mount. Thus, it would also plug directly into any block-level > buffering going on, on the host side. > > On the guest, I'm wondering if you should mount the partition with > -o direct. This should prevent any write-back buffering in the guest, > which however you will not be doing, as you say. > On the other hand, if you make changes to the FS on the host side, > while the QEMU guest instance is already running, the guest probably > will not get to know about any changes, probably unless you umount > and remount, that with "-o direct" (to avoid local read caching in > the guest). > > Even if this crazy stuff works in the end, I'm wondering if it's all > worth the implied pitfalls :-) > Apparently you still need to keep stuff in sync in some way... > > Frank > > after reading page 17 @ https://vmsplice.net/~stefan/qemu-block-layer-features-and-concepts.pdf, I'm almost there with : qemu -snapshot \ -blockdev driver=file,node-name=file-driver,filename=file.qcow2,locking=off \ -blockdev driver=qcow2,node-name=qcow-driver,file=file-driver \ -device ide-hd,drive=qcow-driver \ -hdb file2.qcow2 the difference lies in the fact that it's not `hda` but `hdc` : on the guest side, the disk appears second after the one passed by `hdb`
Re: "relaxed" `-hda file.qcow2` equivalent ?
Le ven. 15 nov. 2024 à 16:11, lacsaP Patatetom a écrit : > Le ven. 15 nov. 2024 à 15:21, Frantisek Rysanek > a écrit : > >> > And, I have an idea: rather than refer to driver=qcow2 and >> > file.filename, how about referring to the loopback device (NBD) that >> > you already have, courtesy of qemu-nbd ? Would that perhaps circumvent >> > the file lock? ;-) >> > >> > -blockdev node-name=xy,driver=raw,file.driver=host_device,\ >> > file.filename=/dev/loop0,file.locking=off >> > >> > -device virtio-scsi-pci -device scsi-hd,drive=xy >> > >> >> I mean: the QEMU device emulation would not run on top of the QCOW >> file directly (and the underlying filesystem, and its locking >> feature), but would instead share a block device with your host-side >> mount. Thus, it would also plug directly into any block-level >> buffering going on, on the host side. >> >> On the guest, I'm wondering if you should mount the partition with >> -o direct. This should prevent any write-back buffering in the guest, >> which however you will not be doing, as you say. >> On the other hand, if you make changes to the FS on the host side, >> while the QEMU guest instance is already running, the guest probably >> will not get to know about any changes, probably unless you umount >> and remount, that with "-o direct" (to avoid local read caching in >> the guest). >> >> Even if this crazy stuff works in the end, I'm wondering if it's all >> worth the implied pitfalls :-) >> Apparently you still need to keep stuff in sync in some way... >> >> Frank >> >> > after reading page 17 @ > https://vmsplice.net/~stefan/qemu-block-layer-features-and-concepts.pdf, > I'm almost there with : > > qemu -snapshot \ > -blockdev > driver=file,node-name=file-driver,filename=file.qcow2,locking=off \ > -blockdev driver=qcow2,node-name=qcow-driver,file=file-driver \ > -device ide-hd,drive=qcow-driver \ > -hdb file2.qcow2 > > the difference lies in the fact that it's not `hda` but `hdc` : on the > guest side, the disk appears second after the one passed by `hdb` > adding `,bus=ide.0,unit=0` to `-device ide-hd,drive=qcow-driver` do the job :-) "relaxed" `-hda file.qcow2` is (seems to be) `-blockdev driver=file,node-name=file-driver,filename=file.qcow2,locking=off -blockdev driver=qcow2,node-name=qcow-driver,file=file-driver -device ide-hd,drive=qcow-driver,bus=ide.0,unit=0` ;-)
Re: "relaxed" `-hda file.qcow2` equivalent ?
Le ven. 15 nov. 2024 à 13:35, Frantisek Rysanek a écrit : > > # qemu-nbd -c /dev/nbd0 file.qcow2 > > # mount /dev/nbd0p1 /mnt -o uid=me > > $ # do some changes in /mnt/... > > > Are you sure the changes have made it to the underlying file? > If you do an umount here, a sync() is guaranteed. > If you do not umount, at this point you may have some dirty > writeback. > So that the following QEMU instance may find the filesystem in a > "factually out of date" state. I dare not say "inconsistent state", > because this should theoretically be taken care of... maybe... > > I manually flush the system caches to make sure my `file.qcow2` file is up to date . > $ qemu-system-x86_64 -snapshot -hda file.qcow2 # with locking=off > > Read-only access is one thing. Maybe the QEMU instance will cope with > that. > > Do you want the QEMU instance to *write* to the filesystem, by any > chance? > no, I don't need it. `-snapshot` is there to prevent corruption of the assembly left in place. > If you manage to force-mount the filesystem for writing, and you > write some changes to it, how does your "outer host-side instance of > the mounted FS" get to know? > This is a recipe for filesystem breakage :-) > > You know, these are exactly the sort of problems, that get avoided by > the locking :-) > > They also get avoided by "shared access filesystems" such as GFS2 or > OCFS2, or network filesystems such as NFS or CIFS=SMBFS. Maybe CEPH > is also remotely in this vein, although this is more of a distributed > clustered FS, and an overkill for your scenario. > > Frank > > in any case, to avoid this kind of problem and make sure I have the right data, I manually clear the system caches with `sudo bash -c “sync && sysctl -q vm.drop_caches=3”` before calling qemu. `-snapshot` is there to prevent corruption of the assembly left in place. regards, lacsaP.
Re: "relaxed" `-hda file.qcow2` equivalent ?
Le jeu. 14 nov. 2024 à 17:00, Frantisek Rysanek a écrit : > > my image `fie.qcow2` is mounted elsewhere (nbd) and running > > `qemu-system-x86_64 -snapshot -hda file.qcow2` fails with the error > > "qemu-system-x86_64: -hda usb1.disk: Failed to get shared “write” > > lock / Is another process using the image [usb1.disk] ?". > > Oh... > > So you want concurrent access to the block device. > 1) have it mounted on the host=HV using qemu-nbd > 2) while at the same time, you want to give it to a guest VM? > > Unless you use a filesystem such as GFS2 or OCFS2 inside the > partitions that exist inside that QCOW2 black box, or mount it > read-only at both ends, you are asking for trouble :-) > That is, if QEMU permits unlocked access by a VM, parallel to the > qemu-nbd loop-mount. > > Note that this is just a tangential pointer on my part. Just a start > of a further journey. Further reading and study. > > If you really want concurrent access to a directory tree, consider > using something like Samba or NFS as the simpler options. > > Then again, concurrent access is definitely fun to play with and grow > :-) > > Frank > > my problem is exactly this, the link between `device`, `drive` and `blockdev` : while `device` and `drive` link quite easily, I can't link `blockdev` to the other two... setting aside the fact that the image is used elsewhere, my aim is to mimic `-hda file.qcow2` but without taking the lock into account (`locking=off`). I currently do this: ``` # qemu-nbd -c /dev/nbd0 file.qcow2 # mount /dev/nbd0p1 /mnt -o uid=me $ # do some changes in /mnt/... # umount /mnt # qemu-nbd -d /dev/nbd0 $ qemu-system-x86_64 -snapshot -hda file.qcow2 # qemu-nbd -c /dev/nbd0 file.qcow2 # mount /dev/nbd0p1 /mnt -o uid=me $ # do some changes in /mnt/... # umount /mnt # qemu-nbd -d /dev/nbd0 $ qemu-system-x86_64 -snapshot -hda file.qcow2 # qemu-nbd -c /dev/nbd0 file.qcow2 # mount /dev/nbd0p1 /mnt -o uid=me $ # do some changes in /mnt/... etc... ``` and I'd like to be able to do this : ``` # qemu-nbd -c /dev/nbd0 file.qcow2 # mount /dev/nbd0p1 /mnt -o uid=me $ # do some changes in /mnt/... $ qemu-system-x86_64 -snapshot -hda file.qcow2 # with locking=off $ # do some changes in /mnt/... $ qemu-system-x86_64 -snapshot -hda file.qcow2 # with locking=off $ # do some changes in /mnt/... etc... ```
Re: "relaxed" `-hda file.qcow2` equivalent ?
Le ven. 15 nov. 2024 à 14:00, lacsaP Patatetom a écrit : > Le ven. 15 nov. 2024 à 13:35, Frantisek Rysanek > a écrit : > >> > # qemu-nbd -c /dev/nbd0 file.qcow2 >> > # mount /dev/nbd0p1 /mnt -o uid=me >> > $ # do some changes in /mnt/... >> > >> Are you sure the changes have made it to the underlying file? >> If you do an umount here, a sync() is guaranteed. >> If you do not umount, at this point you may have some dirty >> writeback. >> So that the following QEMU instance may find the filesystem in a >> "factually out of date" state. I dare not say "inconsistent state", >> because this should theoretically be taken care of... maybe... >> >> > I manually flush the system caches to make sure my `file.qcow2` file is up > to date . > > > $ qemu-system-x86_64 -snapshot -hda file.qcow2 # with locking=off >> >> Read-only access is one thing. Maybe the QEMU instance will cope with >> that. >> >> Do you want the QEMU instance to *write* to the filesystem, by any >> chance? >> > > no, I don't need it. > `-snapshot` is there to prevent corruption of the assembly left in place. > > >> If you manage to force-mount the filesystem for writing, and you >> write some changes to it, how does your "outer host-side instance of >> the mounted FS" get to know? >> This is a recipe for filesystem breakage :-) >> >> You know, these are exactly the sort of problems, that get avoided by >> the locking :-) >> >> They also get avoided by "shared access filesystems" such as GFS2 or >> OCFS2, or network filesystems such as NFS or CIFS=SMBFS. Maybe CEPH >> is also remotely in this vein, although this is more of a distributed >> clustered FS, and an overkill for your scenario. >> >> Frank >> >> in any case, to avoid this kind of problem and make sure I have the right > data, I manually clear the system caches with `sudo bash -c “sync && sysctl > -q vm.drop_caches=3”` before calling qemu. > `-snapshot` is there to prevent corruption of the assembly left in place. > > regards, lacsaP. > after rereading the documentation (introduction @ https://qemu-project.gitlab.io/qemu/system/qemu-block-drivers.html#disk-image-file-locking), I've just had a look at “Linux OFD” to try to remove the lock on my `file.qcow2` file, but I haven't found anything there : if someone has a clue, I'm interested...
Re: "relaxed" `-hda file.qcow2` equivalent ?
Le jeu. 14 nov. 2024 à 15:11, lacsaP Patatetom a écrit : > hi, > what is the "relaxed" equivalent of the `-hda file.qcow2` command line > argument to control file locking (`locking=off`) ? > the documentation says that `-hda a` can be replaced by `-drive file=a` > and that locking can be controlled with the `locking` option of the > `blockdev` argument : how to link `drive` and `blockdev` to obtain > "relaxed" `-hda file.qcow2` ? > regards, lacsaP. > a few (corrected) details to clarify my request... `-hda` is a (very) old way of specifying the disk to be used, but is extremely practical when there's nothing special to define, and is still supported by qemu. my image `file.qcow2` is mounted elsewhere (nbd) and running `qemu-system-x86_64 -snapshot -hda file.qcow2` fails with the error "qemu-system-x86_64: -hda file.qcow2: Failed to get shared “write” lock / Is another process using the image [file.qcow2] ?". I'm doing some tests and I don't want to unmount my mounts, so I'm trying to force qemu to start without taking into account the fact that the image is not free and keeping the disk order (I'm also using `-hdb file2.qcow2` but this image doesn't cause any problems, is not mounted and is totally free). what should I use to replace `-hda file.qcow2` (drive/device/blockdev) to force qemu to boot from this first disk ? regards, lacsaP.
Re: "relaxed" `-hda file.qcow2` equivalent ?
Le jeu. 14 nov. 2024 à 16:15, lacsaP Patatetom a écrit : > Le jeu. 14 nov. 2024 à 15:11, lacsaP Patatetom a > écrit : > >> hi, >> what is the "relaxed" equivalent of the `-hda file.qcow2` command line >> argument to control file locking (`locking=off`) ? >> the documentation says that `-hda a` can be replaced by `-drive file=a` >> and that locking can be controlled with the `locking` option of the >> `blockdev` argument : how to link `drive` and `blockdev` to obtain >> "relaxed" `-hda file.qcow2` ? >> regards, lacsaP. >> > > a few (corrected) details to clarify my request... > > `-hda` is a (very) old way of specifying the disk to be used, but is > extremely practical when there's nothing special to define, and is still > supported by qemu. > > my image `file.qcow2` is mounted elsewhere (nbd) and running > `qemu-system-x86_64 -snapshot -hda file.qcow2` fails with the error > "qemu-system-x86_64: -hda file.qcow2: Failed to get shared “write” lock / > Is another process using the image [file.qcow2] ?". > > I'm doing some tests and I don't want to unmount my mounts, so I'm trying > to force qemu to start without taking into account the fact that the image > is not free and keeping the disk order (I'm also using `-hdb file2.qcow2` > but this image doesn't cause any problems, is not mounted and is totally > free). > > what should I use to replace `-hda file.qcow2` (drive/device/blockdev) to > force qemu to boot from this first disk ? > > regards, lacsaP. > > `qemu-system-x86_64 -global file.locking=off -snapshot -hda file.qcow2 -hdb file2.qcow2` and `qemu-system-x86_64 -global driver=file,property=locking,value=off -snapshot -hda file.qcow2 -hdb file2.qcow2` do not force qemu to start up...
Re: "relaxed" `-hda file.qcow2` equivalent ?
Le jeu. 14 nov. 2024 à 15:11, lacsaP Patatetom a écrit : > hi, > what is the "relaxed" equivalent of the `-hda file.qcow2` command line > argument to control file locking (`locking=off`) ? > the documentation says that `-hda a` can be replaced by `-drive file=a` > and that locking can be controlled with the `locking` option of the > `blockdev` argument : how to link `drive` and `blockdev` to obtain > "relaxed" `-hda file.qcow2` ? > regards, lacsaP. > a few details to clarify my request... `-hda` is a (very) old way of specifying the disk to be used, but is extremely practical when there's nothing special to define, and is still supported by qemu. my image `fie.qcow2` is mounted elsewhere (nbd) and running `qemu-system-x86_64 -snapshot -hda file.qcow2` fails with the error "qemu-system-x86_64: -hda usb1.disk: Failed to get shared “write” lock / Is another process using the image [usb1.disk] ?". I'm doing some tests and I don't want to unmount my mounts, so I'm trying to force qemu to start without taking into account the fact that the image is not free and keeping the disk order (I'm also using `-hdb file2.qcow2` but this image doesn't cause any problems, is not mounted and is totally free). what should I use to replace `-hda file.qcow2` (drive/device/blockdev) to force qemu to boot from this first disk ? regards, lacsaP.
"relaxed" `-hda file.qcow2` equivalent ?
hi, what is the "relaxed" equivalent of the `-hda file.qcow2` command line argument to control file locking (`locking=off`) ? the documentation says that `-hda a` can be replaced by `-drive file=a` and that locking can be controlled with the `locking` option of the `blockdev` argument : how to link `drive` and `blockdev` to obtain "relaxed" `-hda file.qcow2` ? regards, lacsaP.
capture VM network traffic
hi, what network configuration (HM/VM side) would you set up to capture/follow a virtual machine's network traffic, forcing it to pass through tools such as tshark/wireshark, dnsmasq or mitmproxy ? the host machine (HM) is an ArchLinux. regards.
