I would like to know the relation between Physical address, virtual address and system memory address in
Virtual environment with PCIe device.
It is best to give an example about these three addresses.
Brief explanation about Physical address, virtual address and system memory address, and have a simple example
Related
I have an embedded application running on a Xilinx ZynqMp SoC. The application running on the PS (processor) memory maps the PL (FPGA) of the SoC over an AXI bus via /dev/mem at some base physical address.
I would like to run this application in a KVM/QEMU VM running on the PS. This means I will need to somehow expose that memory window available via /dev/mem on the host to the guest VM.
Through some research I thought that virtio-mmio would be the method to do this. I made some attempts using virtio-mmio but hit a wall, so I asked a question: Memory map address space on host from KVM/QEMU guest using virtio-mmio
The response seems to indicate that virtio-mmio is not the method I should be using for this.
If that is the case, what is the method used for exposing a memory space available on the host to a guest VM? I do not need any sort of device driver/layer on top of this. I just need raw memory access.
I ran into some trouble when I tried to ping my Ubuntu virtual guest from my Windows 10 host, but this solution did the trick.
I'm wondering what exactly is a "host-only-adapter" and why cant the I ping the virtual machine by default? How exactly does the virtual machine access the internet when I cant ping it?
As the name suggests, host-only is intended to create a new interface that is virtual and visible to the host and not in anyway connected to the physical interface that actually connects to the internet.
Itcan be thought of as a hybrid between the bridged and internal networking modes: as with bridged networking, the virtual machines can talk to each other and the host as if they were connected through a physical Ethernet switch. Similarly, as with internal networking however, a physical networking interface need not be present, and the virtual machines cannot talk to the world outside the host since they are not connected to a physical networking interface.
You might be wondering what the use-case for this would be.Think for example: one virtual machine may contain a web server and a second one a database, and since they are intended to talk to each other, the appliance can instruct VirtualBox to set up a host-only network for the two. A second (bridged) network would then connect the web server to the outside world to serve data to, but the outside world cannot connect to the database.
How it works
when host-only networking is used, VirtualBox creates a new software interface on the host which then appears next to your existing network interfaces. In other words, whereas with bridged networking an existing physical interface is used to attach virtual machines to, with host-only networking a new "loopback" interface is created on the host. And whereas with internal networking, the traffic between the virtual machines cannot be seen, the traffic on the "loopback" interface on the host can be intercepted.
The great thing about host-only networks is that the host itself sits on this network and so, upon proper config as in you link above, you can reach all the VMs.
Hope my explanation helps!
I currently have two Ubuntu 14.04 virtual machines running on a windows 7 host. The virtual machines are configured to use a bridged network adapter.
When the host machine is hardlined to the internet, the virtual machines are able to ping the outside world as well as be ping by the outside world.
When the host machine is on a wireless network, the virtual machines cannot ping the outside world, and the outside world is not able to ping the virtual machines.
When connected to a wireless network, I receive the 'Destination host unreachable' error when pinging either from the virtual machines to outside, or from outside to the virtual machines.
It may be worth noting that these virtual machines are being run inside VirtualBox. Also something which may be applicable here, section 6.5 of the virtualbox manual states:
Bridging to a wireless interface is done differently from bridging to
a wired interface, because most wireless adapters do not support
promiscuous mode. All traffic has to use the MAC address of the host's
wireless adapter, and therefore VirtualBox needs to replace the source
MAC address in the Ethernet header of an outgoing packet to make sure
the reply will be sent to the host interface. When VirtualBox sees an
incoming packet with a destination IP address that belongs to one of
the virtual machine adapters it replaces the destination MAC address
in the Ethernet header with the VM adapter's MAC address and passes it
on. VirtualBox examines ARP and DHCP packets in order to learn the IP
addresses of virtual machines.
I'm not sure what may be causing this issue. Accessing these virtual machines from the outside world when switching between networks is necessary in my situation. Any ideas as to what may be going on?
Thanks in advance for any help!
Just to provide some value to those who may stumble upon this issue in the future:
The source of this problem stems from a setting within virtualbox. Open virtualbox, and under the Settings > Network > Adapter page, there is a name field.
If attempting to connect to the virtual machines over a wired connection, select your host machines Ethernet adapter.
If attempting to connect to the virtual machines over a wireless connection, select your host machine's wireless adapter.
Hope this helps someone out there!
If you are running a Virtual Machine on VMWare or Virtualbox, whose MAC Address is visible to Internet;.i.e. of the Host OS or of the Virtual OS and why?
In the case of IPv4 the MAC address is not visible to the internet at large since it is only part of the local physical transport. I.e. only up to the next router. Although it may be visible to neighboring nodes (colocated servers or neighbors on some cable networks) and the service provider itself if there is no intermediate router separating the networks at the data link layer level.
In the case of IPv6 it depends on how the machine gets its address, some forms of autoconfiguration may include the MAC address as the lower 64bits in the address, others don't. And the v6 privacy extensions complicate this further.
But if the MAC is embedded in the v6 address then it is globally visible and could be easily tracked as the lower 64bits would remain the same even if the prefix changes.
Edit: As andrew-medico mentioned, the question should be asked at SuperUser.
According to an answer by harrymc on SuperUser, the MAC address visible to the Ethernet will be the one of the virtual OS, if you are running it in bridged network mode.
the virtual driver just injects packages with its own virtual MAC address and responds to packages that are destined to that MAC address, even though physically no such adapter exists.
Please note the difference between Ethernet and internet. The internet will only know your IP, not your MAC address.
we are currently considering whether ns3 satisfying our requirements, we're looking for a convenient tool to run in distributed devices in the real network (every kind of possible connections) and capture the network performance data (like a sniffer). I realize that the primary purpose of ns3 is to simulate network topology in a single machine, but its emu module sounds promising and the flow monitor can save our effort on data capture.
In the following link
http://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world
it is declared that NS-3 EMU can be applied to inject simulated nodes interacting with real live network, and 3 kinds of testbed are given. However the first solution, virtual machine vmware testbed is still woking within LAN -- in promiscuous mode the virtual machines network card are listening to all LAN broadcasts so that the emu-udp-echo server and client can find each other.
My question is, is it possible that the emu-udp-echo server/client running in different, physical systems from different positions in wide network?
e.g. in different cities or from different network providers, given ip address of the hardware where the other ns-3 node is running? if it is possible, how can i specify the "real" ip address and port for the node, instead of assign a virtual ipv4 address?
Thanks a lot.
Yes, while the documentation describes how to perform this using virtual machines, this can be done in general on real hardware. Since that HOWTO was written, there has been additional work on providing helpers for running this type of experiment, including running on PlanetLab testbed machines. This documentation describes the generalized file descriptor NetDevice, added to the ns-3.17 release: http://www.nsnam.org/docs/release/3.19/models/html/fd-net-device.html. A similar example to the one described in that HOWTO is found in the file fd-emu-udp-echo.cc.
When using emulation mode on real networks, configuration of the MAC addresses and IP addresses must be done carefully. First, the device must be able to be put into promiscuous mode. Second, the MAC address needs to be different than the hardware address of the NIC. If you intend to be riding on top of an active NIC with existing IP address (in use for other Internet traffic), you'll need to have another IP address for ns-3 that is within the right link subnet. If instead you want to dedicate the NIC to ns-3 use, then do not assign the IP address to the host NIC and just assign it to the ns-3 configuration.
The PlanetLab example also shows another configuration that uses Tap devices to send data to/from PlanetLab testbed nodes. Some of this configuration is specific to how PlanetLab works, but the use of Tap device bridged to an ns-3 device may also facilitate emulation.