Re: PASST networking with onboard NIC
On 14/11/2024 17:44, Lytle, Ben wrote: Hello, Laurent! Hi Ben, I have a question about the proper way to use passt networking with a machine's onboard NIC (ie. without specifying a |-device|). Is there a way to connect |-netdev stream,id=net0,server=off,addr.type=unix,addr.path=/ tmp/passt_1.socket| to an onboard nic using |-nic| ? No, I don't think the -nic option is able to parse the stream backend parameters (like "addr.type", "addr.path", ...). Thanks, Laurent
PASST networking with onboard NIC
Hello, Laurent! I have a question about the proper way to use passt networking with a machine's onboard NIC (ie. without specifying a -device). Is there a way to connect -netdev stream,id=net0,server=off,addr.type=unix,addr.path=/tmp/passt_1.socket to an onboard nic using -nic ? Thanks! Ben
Re: PASST networking with onboard NIC
>> I have a question about the proper way to use passt networking with a >> machine's onboard >> NIC (ie. without specifying a |-device|). >> Is there a way to connect |-netdev >> stream,id=net0,server=off,addr.type=unix,addr.path=/ >> tmp/passt_1.socket| to an onboard nic using |-nic| ? > > No, I don't think the -nic option is able to parse the stream backend > parameters (like > "addr.type", "addr.path", ...). I figured that was the case, as I've tried many combinations for those options. I appreciate the confirmation! Ben From: Laurent Vivier Sent: Thursday, November 14, 2024 11:57 AM To: Lytle, Ben Cc: qemu-discuss@nongnu.org Subject: Re: PASST networking with onboard NIC On 14/11/2024 17:44, Lytle, Ben wrote: > Hello, Laurent! Hi Ben, > > I have a question about the proper way to use passt networking with a > machine's onboard > NIC (ie. without specifying a |-device|). > Is there a way to connect |-netdev > stream,id=net0,server=off,addr.type=unix,addr.path=/ > tmp/passt_1.socket| to an onboard nic using |-nic| ? No, I don't think the -nic option is able to parse the stream backend parameters (like "addr.type", "addr.path", ...). Thanks, Laurent
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.
Re: "relaxed" `-hda file.qcow2` equivalent ?
> 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
Re: "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. Let me give you an example of how disk controller device and disk drive devices are nested, i.e. the expanded form of the "-hda" arg. I start qemu by a script, and I use shell variables to put the long command line together. The following is a relevant excerpt of the script. See how the "-device" (controller) record maps to the "-drive" records via the id= and drive= attributes: DISK1="-drive if=none,id=ff,cache.direct=on,aio=native,discard=unmap,detect-zeroes=u nmap,file=/somepath/system.qcow2" DISK2="-drive if=none,id=fe,cache.direct=on,aio=native,discard=unmap,detect-zeroes=u nmap,file=/somepath/data.qcow2" DISK3="-drive if=none,id=fd,cache.direct=on,aio=native,discard=unmap,detect-zeroes=u nmap,file=/somepath/swap.qcow2" HDD_STUFF="$DISK1 $DISK2 $DISK3 -device virtio-scsi-pci -device scsi-hd,drive=ff -device scsi-hd,drive=fe -device scsi-hd,drive=fd" In my script, those are four long lines. Here they have wrapped... sorry :-) I run this on top of a filesystem that supports sparse files and snapshots, and can be told to avoid FS-level COW if it can (= to make it prefer in-place overwrites over COW). Now... I've found a more advanced description of image file locking in the official current documentation here: https://www.qemu.org/docs/master/system/qemu-block-drivers.html#disk-i mage-file-locking ...now try to combine this with my example above :-) Not sure what you mean by "relaxed". Do you need to map the same image file to multiple guests? For what purpose? HA failover? Both/all guests should have simultaneous write access? Similar to multipath SCSI ? Are you playing with the GFS2/OCFS2 or something? Or do you mean to use the same image by multiple guests as a shared read-only disk? I recall reading an article ages ago, on how to create "ephemeral fake writeable block devices" for individual guests, on top of a shared read-only "master image"... (as multiple COW snapshots) Frank
"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.
