[Qemu-discuss] connect virtual machines to each other
hi, I come back to this subject about using VDE to connect VM. this is what I use: $ vde_switch $ slirpvde -L :10.0.2.101:22 $ qemu -enable-kvm -m 512 -nic vde,mac=52:54:00:12:34:56 samba.disk # 10.0.2.101/24 $ qemu -enable-kvm -m 512 -nic vde,mac=52:54:00:12:34:57 linux.disk # 10.0.2.102/24 $ qemu -enable-kvm -m 1024 -nic vde,mac=52:54:00:12:34:58 windows.disk # 10.0.2.103/24 but I have many network problems with it that I can't identify and explain to access in ssh (ssh -p root@localhost) to the targeted machine : one time it works, the other time it doesn't, the other time the connection freezes (and eventually resumes after a few moments) or is simply cut off ( slirpvde returns without any explanation). of course I suspect slirpvde to be the problem, especially since the VM communicate with each other without problems. do any of you have an explanation, a beginning of a solution or a path to follow ? is VDE still maintained ? I like using it because it does not require any privileges. regards, lacsaP. -- Forwarded message - De : Pascal Date: lun. 23 sept. 2019 à 10:33 Subject: Re: connect virtual machines to each other To: qemu-discuss hi, for information : the disabling of my firewall fixed the problem :-) regards, lacsaP. Le mer. 18 sept. 2019 à 11:57, Pascal a écrit : > hi, > > I have two Linux VM that communicate without any problem when I use VDE > but their communication stops when I try to connect them with a multicast > bus : does anyone have an idea ? > > vde_switch > qemu -nic vde,mac=52:54:00:11:11:11 vm1.disk > qemu -nic vde,mac=52:54:00:22:22:22 vm2.disk > > and all is ok (ping && cetera) :-) > > qemu -nic socket,mac=52:54:00:11:11:11,mcast=230.0.0.1:1234 vm1.disk > qemu -nic socket,mac=52:54:00:22:22:22,mcast=230.0.0.1:1234 vm2.disk > > and all is ko :-( > > regards, lacsaP. >
Re: [RFC PATCH] configure: deprecate 32 bit build hosts
Hi, > That leaves armv7 as the only 32-bit arch in Fedora that is somewhat > active & maintained. I don't have any real insight on whether any > armv7 (Fedora) users are making much use of QEMU/KVM though, either > system or user emulation. Played with system emulation a while back. I doubt this is used much in practice. It's very slow for various reasons (no gic, no armv8 arch updates to support kvm virt better, slow sdcard/usb I/O). TCG on a beefy x86 box is roughly the same speed. Also 1G of memory isn't that much even without considering virtual machines. The rpi4 with 4G (disclaimer: don't have one) probably works better. But note they are finally working on a 64bit kernel for raspbian, which I expect is only a first step for better 64bit support. cheers, Gerd
qemu smb access problem host: linux, guest: win10
Hello! I have problems, accessing a shared folder from Windows 10 guest on my OpenSuse host machine. I can access the shared folder in my virtual machine with \\192.168.0.4\qemu. However, If I open it with explorer I get a Could not access \\192.168.0.4\qemu error. In the Windows command line I"m getting a file not found message. net use \\192.168.0.4\qemu works without any problems. The permission of the shared folder (/opt/virtMachines/share-win10) and all files in it is rwxrwxrwx. The smbd version is 4.7.11-git.153.b36ceaf2235lp150.3.14.1-SUSE-oS15.0-x86_64. The qemu version is 2.11.2. I start the qemu with the following options: qemu-kvm -smp 8,sockets=2,cores=4,threads=1 -cpu host,kvm=on -m size=1024 -k de \ -balloon none \ -monitor unix:qemu-monitor-socket,server,nowait -daemonize \ -cdrom /opt/virtMachines/dvds/empty.iso \ -hda /opt/virtMachines/images/win10.qcow2 \ -drive file=/opt/virtMachines/images/vs-and-tools.qcow2 \ -drive file=/opt/virtMachines/images/src-and-build.qcow2 \ -display sdl \ -vga vmware \ -netdev "user,id=mynet0,restrict=y,net=192.168.0/24,dhcpstart=192.168.0.130,hostfwd=tcp::2228-:22,hostfwd=tcp::2238-:3389,smb=/opt/virtMachines/share-win10" \ -device rtl8139,netdev=mynet0 \ -boot order=dc,menu=on -no-quit How can I access my shared folder? Thank you! Have a nice day Thomas Strasser
Re: [RFC PATCH] configure: deprecate 32 bit build hosts
On 26/09/2019 00:30, Alex Bennée wrote: > The 32 bit hosts are already a second class citizen especially with > support for running 64 bit guests under TCG. We are also limited by > testing as actual working 32 bit machines are getting quite rare in > developers personal menageries. For TCG supporting newer types like > Int128 is a lot harder with 32 bit calling conventions compared to > their larger bit sized cousins. Fundamentally address space is the > most useful thing for the translator to have even for a 32 bit guest a > 32 bit host is quite constrained. > > As far as I'm aware 32 bit KVM users are even less numerous. Even > ILP32 doesn't make much sense given the address space QEMU needs to > manage. > > Lets mark these machines as deprecated so we can have the wailing and > gnashing of teeth now and look to actually dropping the support in a > couple of cycles. > > Signed-off-by: Alex Bennée > Cc: Richard Henderson > --- > configure | 24 +--- > 1 file changed, 13 insertions(+), 11 deletions(-) > > diff --git a/configure b/configure > index 542f6aea3f..776fd460b5 100755 > --- a/configure > +++ b/configure > @@ -728,7 +728,7 @@ ARCH= > # Normalise host CPU name and set ARCH. > # Note that this case should only have supported host CPUs, not guests. > case "$cpu" in > - ppc|ppc64|s390|s390x|sparc64|x32|riscv32|riscv64) > + ppc64|s390|s390x|sparc64|riscv64) > supported_cpu="yes" >;; >ppc64le) > @@ -737,7 +737,6 @@ case "$cpu" in >;; >i386|i486|i586|i686|i86pc|BePC) > cpu="i386" > -supported_cpu="yes" >;; >x86_64|amd64) > cpu="x86_64" > @@ -745,19 +744,22 @@ case "$cpu" in >;; >armv*b|armv*l|arm) > cpu="arm" > -supported_cpu="yes" >;; >aarch64) > cpu="aarch64" > supported_cpu="yes" >;; > - mips*) > + mips64*) > cpu="mips" > supported_cpu="yes" >;; > + mips*) > +cpu="mips" > + ;; >sparc|sun4[cdmuv]) > cpu="sparc" > -supported_cpu="yes" > + ;; > + x32|riscv32) >;; >*) > # This will result in either an error or falling back to TCI later > @@ -6438,12 +6440,12 @@ if test "$supported_cpu" = "no"; then > echo "WARNING: SUPPORT FOR THIS HOST CPU WILL GO AWAY IN FUTURE > RELEASES!" > echo > echo "CPU host architecture $cpu support is not currently maintained." > -echo "The QEMU project intends to remove support for this host CPU in" > -echo "a future release if nobody volunteers to maintain it and to" > -echo "provide a build host for our continuous integration setup." > -echo "configure has succeeded and you can continue to build, but" > -echo "if you care about QEMU on this platform you should contact" > -echo "us upstream at qemu-de...@nongnu.org." > +echo "The QEMU project intends to remove support for all 32 bit host" > +echo "CPUs in a future release. 64 bit hosts will need a volunteer" > +echo "to maintain it and to provide a build host for our continuous" > +echo "integration setup. configure has succeeded and you can continue" > +echo "to build, but if you care about QEMU on this platform you" > +echo "should contact us upstream at qemu-de...@nongnu.org." > fi > > if test "$supported_os" = "no"; then FWIW I still use my Mac Mini G4 (with KVM) to help debug bits of TCG for qemu-system-ppc and so I would certainly miss this for bits of my Mac work. Is it possible to reach a compromise based on host/target i.e. allow 32-bit hosts to only run targets up to 32-bits? I'd only ever want to use qemu-system-ppc on the Mac Mini for testing: for qemu-system-ppc64 it is clearly much quicker just to use the nearest x86 box. ATB, Mark.
qemu smb access problem host: linux, guest: win10
Hello!
I have problems, accessing a shared folder from Windows 10 guest on my OpenSuse
host machine.
I can access the shared folder in my virtual machine with
""\\192.168.0.4\qemu"".
However, If I open it with explorer I get a ""Could not access
\\192.168.0.4\qemu"" error.
In the Windows command line I"m getting a ""file not found"" message.
""net use \\192.168.0.4\qemu"" works without any problems.
The permission of the shared folder (""/opt/virtMachines/share-win10"") and all
files in it is rwxrwxrwx.
The smbd version is 4.7.11-git.153.b36ceaf2235lp150.3.14.1-SUSE-oS15.0-x86_64.
The qemu version is 2.11.2.
I start the qemu with the following options:
qemu-kvm -smp 8,sockets=2,cores=4,threads=1 -cpu host,kvm=on -m size=1024 -k
de \
-balloon none \
-monitor unix:qemu-monitor-socket,server,nowait -daemonize \
-cdrom /opt/virtMachines/dvds/empty.iso \
-hda /opt/virtMachines/images/win10.qcow2 \
-drive file=/opt/virtMachines/images/vs-and-tools.qcow2 \
-drive file=/opt/virtMachines/images/src-and-build.qcow2 \
-display sdl \
-vga vmware \
-netdev
"user,id=mynet0,restrict=y,net=192.168.0/24,dhcpstart=192.168.0.130,hostfwd=tcp::2228-:22,hostfwd=tcp::2238-:3389,smb=/opt/virtMachines/share-win10"
\
-device rtl8139,netdev=mynet0 \
-boot order=dc,menu=on -no-quit
How can I access my shared folder?
Thank you!
Have a nice day
Thomas Strasser
Stopping gdb stub at exception
Hi all, I'm running littlekernel aarch64-elf in qemu. I've got the gdb stub running and I've connected to it from gdb. I'm able to set breakpoints, run, step and inspect variables. Unfortunately, when the kernel panics, the callstack I get isn't very useful. 1 uart_pgetcuart.c 158 0x00011dd0 2 platform_pgetcdebug.c48 0x00011970 3 __panic_stdio_readdebug.c54 0x000401e0 4 __panic_stdio_readdebug.c50 0x000401e0 5 getc stdio.c66 0x00044ad0 6 read_line_panic console.c 866 0x00040030 7 panic_shell_start console.c 866 0x00040030 8 platform_halt power.c32 0x000396fc 9 _panicdebug.c35 0x000402c0 10 arm64_sync_exception exceptions_c.c 101 0x000121fc 11 arm64_sync_exc_current_el_SPx exceptions.S 145 0x0001125c 12 arm64_sync_exc_current_el_SPx exceptions.S 145 0x0001125c 13 arm64_sync_exc_current_el_SPx exceptions.S 145 0x0001125c 14 arm64_sync_exc_current_el_SPx exceptions.S 145 0x0001125c 15 arm64_sync_exc_current_el_SPx exceptions.S 145 0x0001125c 16 arm64_sync_exc_current_el_SPx exceptions.S 145 0x0001125c 17 arm64_sync_exc_current_el_SPx exceptions.S 145 0x0001125c 18 arm64_sync_exc_current_el_SPx exceptions.S 145 0x0001125c 19 arm64_sync_exc_current_el_SPx exceptions.S 145 0x0001125c 20 arm64_sync_exc_current_el_SPx exceptions.S 145 0x0001125c ... /* exceptions from current EL, using SPx */ .org 0x200 LOCAL_FUNCTION(arm64_sync_exc_current_el_SPx) regsave_long mov x0, sp bl arm64_sync_exception b arm64_exc_shared_restore_long https://github.com/littlekernel/lk How do I get the gdb stub to stop in the debugger at the exception point, rather than in the exception handler? Thanks! -- Vince Harron | Software Engineer | vhar...@google.com | 858-442-0868
