> I don't know how the virtio-net-pci device works, but for other
> network devices I guess you should also set different MAC addresses
> for them. If you use an DHCP server it might give the same IP address
> to both devices.
>
...I actually suspect that QEMU (or the Linux kernel?) invents unique
Dear YangFeng,
thanks for the question :-)
Timekeeping is a complex topic.
Could you perhaps add more detail on what you are trying to achieve?
Linux offers various API functions for timing, in the kernel and in
the user space - though oops, you haven't mentioned what guest VM you
are consideri
I've checked the posting at serverfault.com.
It seems that yours is a bit of a noob question, and you got some
harsh love in return... :-)
I'm not sure how to read your question at serverfault.com.
There's a sequence of "ip ... " commands.
The last one is the addition of a default route, pointing
> 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,driv
> 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.
Hmm. By now I'm thinking aloud.
According to the manpage (see below), "-blockdev" is the most "down
to earth", true and modern way to specify the emulated disk -
possibly needs to be combined with a "-device" to specify the
guest-side emulated interface? Curiously, I cannot find a complete
exa
> # 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 t
>
> 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
> 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 t
> To clarify,
>
> In the real world, this would be two physical machines with different
> NICs plugged into different ports on a managed switch, with said
> switch set to mirror traffic onto the second machine (see the
> WireShark website for hints on how to do so for various brands of real
> swit
I see, I'm probably at my wits' end right there :-)
It would be perhaps interesting to know, what HAL your XP in the
existing VM reports. It's in the device manager, the "computer" node.
http://vernalex.com/guides/sysprep/hal.shtml
Frank
From: Tony Graham
To:
Hmm... I second that note about forcing a particuar HAL using F5
during XP installer, just before F6 for the driver floppy.
Note that you probably do not need to disable ACPI in QEMU (the
hypervisor). By selecting a non-ACPI HAL during XP installation, you
should end up not using ACPI in the gu
My two cents worth at this stage:
The fact that you get as far as the BSOD means to me, that your VM
successfully goes through the early stages of legacy BIOS boot: the
BIOS hands over to the NT bootloader in the MBR, not sure if the next
stage in the NFTS boot sector is used, definitely the nt
Hello Steve,
I have a faint recollection that, when I compiled QEMU from source,
there was a choice of the BIOS / UEFI ROM image to load, as a runtime
option... somehow I was supposed to provide a path to the images, if
I wanted to change the default, which is SeaBIOS (legacy BIOS
services).
Dear fellow QEMU users,
once again I'm getting ready to taste some new QEMU.
It's been a few months (or maybe years already) since my last try.
This time, my goal is to try PCI passthrough via VT-d from host to
guest.
I've made a modest collection of dumps of "iommu group listings" for
severa
I've taken a look at the qemu source code (7.2.0 happens to be
unpacked on my hard drive).
I have noticed that there probably two separate implementations of
virtual disk devices supporting unmap/discard.
My scrapbook notes on this chapter:
1) hw/scsi/scsi-disk.c:
// The following reflects
On 9 Jan 2024 at 0:20, d tbsky wrote:
>
> Since I am using RedHat family, I focus at q35 machine type
> (pc-i440fx is no longer supported) and virtio-blk/virtio-scsi
> device.
>
...
>
> trim is useful for ssd and sparse image file and I am using it. but
> for hard disk I don't want extra layers
On 19 Apr 2023 at 23:40, Freitas GDH wrote:
> [ 1.579213] VFS: Cannot open root device "vda" or
> unknown-block(0,0): error -6
> [ 1.579566] Please append a correct "root=" boot option; here are
> the available partitions:
> [ 1.580137] Kernel panic - not syncing: VFS: Unable to mount roo
Dear everyone,
I've managed to move a little further and am kind of satisfied with
the limited success.
This is my current set of options for the VNC-only video output,
protected by a simple password (not even a login):
-vga std
-object secret,id=secvnc1,file=/etc/qemu/my-vnc-passwd.txt
-vnc :1
Dear fellow QEMU users,
I'm playing for the first time with the VNC output of QEMU.
I'm running qemu-system-x86_64 by hand from the command line, i.e. no
virtmanager. No problems there, I know enough of QEMU's cmdline args
to find my way about.
I'm compiling QEMU 7.2.0 from source.
The first ti
Dear fellow tinkerers,
as an academic exercise (will need to tackle licensing if this turns
out technically feasible) I'm teasing an image of SCO OpenServer
5.0.6 in a QEMU+KVM VM (QEMU 5.2 on Debian 11).
The disk image is effectively a backup copy of an old SCO-based PC
box that is starting t
Hello Sukreet,
you're telling the VM guest's kernel to look for an MMC device. E.g.
an SD card accessible via an SD/MMC controller chip, or an eMMC SSD.
And the kernel is telling you that there's no such device, but that
it has found an "MTD block" device.
MTDblock normally sounds like kernel's o
A couple more points:
How many CPU's (sockets) does your motherboard have?
Multi-socket machines are more or less in the NUMA territory.
Suboptimal process scheduling / memory allocation "decisions" (on
part of the CPU/process scheduler) can have "interesting effects".
Think of processes migrati
...I forgot to mention CPU temperatures and frequencies.
When overheating, modern CPU's try to limit power consumption by
throttling the clock rate.
The temperatures can be read at the cmdline from /sys/class/hwmon,
provided that you have the right drivers loaded (for Intel CPU's I'd
say "modpr
of technology much, so it is very helpful to get an idea of
> what I might or should look at.
>
> I know we use the same architecture so we can eliminate that as an
> issue.
>
> Thanks for the feedback, I'll see if I can discover anything
> interesting given the ideas you
Hello Nada,
perhaps you should be more specific about your mission :-)
Accessing storage controllers is something stock operating systems do
for a living. To do that, they have drivers. If you're interested
what a storage controller driver can look like, I suggest that you
study the source code o
On 5 Oct 2021 at 18:58, Parnell Springmeyer wrote:
>
> Hi, we use QEMU VMs for running our integration testing
> infrastructure and have run into a very difficult to debug problem:
> occasionally we will see a severe performance degradation in some of
> our QEMU VMs.
>
If memory serves, QEMU
On 18 Jan 2021 at 16:45, Rukayat A Erinfolami wrote:
>
> How do I go about altering the control flow of a program running in
> Qemu's user mode emulation.
> For instance, at the callsite of function A::f(), I want A::f() and
> all the definitions of f() by the derived classes of A to be
> executed.
On 28 Jun 2020 at 17:02, gal...@nycap.rr.com wrote:
>
> Yes, I understand Narcis. They're NTFS, but I'm referring to each one
> as Win98 or WinXP, because I'm getting different results from each
> partition.
>
Windows98 do not know NTFS. They only know FAT12/16/32, with support
for long filenam
On 28 Jun 2020 at 10:30, DC wrote:
>
> Partition Magic is still around? I remember the Dos versions, but
> thought they had closed shop years ago.
>
I believe it's as dead as ever - I mean since 2009, if Wikipedia is
to be believed:
https://en.wikipedia.org/wiki/PartitionMagic
Same thing with the
> 2) Add files into that container. If possible, be able to resize
> the
> file holding the container, as well as resize the partitions defined
> inside.
>
Mount the image in a VM, where you have some tool (partition magic?
PQ magic?) that can shrink Windows filesystems (FAT16/FAT32/NTFS).
Booted
Dear Dan,
I do not have an answer on "how to do all this in Windows".
Not an easy one anyway.
*Are we* talking Windows btw?
Some of the things that you're asking for, might be worked around by
booting Windows (or DOS!) and Ghost or Partition Magic in a VM,
providing the disk images to the VM, a
On 27 Jun 2020 at 23:04, Dan Campbell wrote:
>
> Hi,
>
> I'm using a virtual disc created in Qemu Manager. It contains a
> Windows XP partition.
>
> I'm not able to add files or change anything with PowerISO. If I
> open the c.img file with PowerISO and try to add a few files,
> PowerISO return
Dear everybody,
I'm itching to top-post, but as this is a no-no, scroll all the way
down if you're interested to see my outcome ;-)
On 27 Dec 2019 at 18:33, qemu-discuss@nongnu.org, free wrote:
> Dear everybody,
>
> this is a superficial early question,
> just in case this is a known problem,
>
> On 18/04/2020 17:25, Randy Wheaton wrote:
> > Good Morning,
> >
> > We have 5 servers running Centos7 QEMU and we are relocating them to a
> > new Data Center and we're getting error disabled on the Cisco Fex
> > ports when we turn up the port. Is there any support you could provide
> > on what o
> On Sat, Jan 25, 2020 at 4:49 AM Aurelien Jarno
> wrote:
> [...]
> Probably a bit of both ;-) The poweroff implementation has changed in
> kernel 4.19 (commit dd129c6374) and requires that the kernel is built
> with CONFIG_POWER_RESET_PIIX4_POWEROFF=y to work.
uh oh, jus
Dear everybody,
this is a superficial early question,
just in case this is a known problem,
or to get your feedback ("upgrade the distro
and stick to the distro kernel", etc).
I'm playing with Debian 9 64bit (so far I haven't been motivated to
upgrade) which happens to contain the following QEMU
Just a couple notes...
The e1000 is a whole family of Intel Gb Ethernet chips with a pretty
long tradition, especially if you include the preceding 100Mb line by
Intel. The 1Gb family enjoys a great deal of software compatibility
across the family - yet there has been some development over the
Dear fellow QEMU users,
I'm posting this mostly "for the record" - for people trying the same
thing later on.
As it's becoming ever more difficult to get hardware, on which XP is
willing to run natively and be any use (see the timestamp in the
header of this message), and as we have customers
39 matches
Mail list logo
