I am new to kvm, so maybe a lot of you will take it silly, but I would like to describe the problem I had.
When I was typing
kvm
in qemu the error of 'no bootable device' with code 0003 occurs.
This is because your command line is (implicitly) asking to create a virtual machine with no disk. The guest BIOS then looks for disks or CDROMs that it can boot from, and finds none. This is exactly the same behaviour as if you had a real hardware PC, and powered it up with no disks in it.
In general, the QEMU command line can be long and complicated, especially if you want best performance from the virtual machine. For most users it's often best to use a "management layer" program like libvirt, which takes care of these details for you, rather than trying to run QEMU directly.
The easiest fix, which let me open the virtual machine through terminal was just to find it:
sudo find /var/lib/libvirt/images/
Choose the correct one and copy/paste the path to the code:
sudo kvm /var/lib/libvirt/images/Centos.qcow2
And thats it..
I couldn't find it in manual to qemu or kvm, but it is that easy, the hours of config changes and bus types were not necessary.
Related
I am trying to run some simple SPARC tests on bare metal QEMU. I am using qemu-sparc64 -g 1234 simple_example and seems to be working fine (I can connect gdb to localhost:1234, step through, etc) but was wondering what does qemu-system-sparc64 do ? I tried running it with the same cmd line switches but got some errors. Any help is appreciated, thank you.
For any QEMU architecture target, the qemu-system-foo binary runs a complete system emulation of the CPU and all other devices that make up a machine using that CPU type. It typically is used to run a guest OS kernel, like Linux; it can run other bare-metal guest code too.
The qemu-foo binary (sometimes also named qemu-foo-static if it has been statically linked) is QEMU's "user-mode" or "linux-user" emulation. This expects to run a single Linux userspace binary, and it translates all the system calls that process makes into direct host system calls.
If you're running qemu-sparc64 then you are not running your program in a bare-metal environment -- it's a proper Linux userspace process, even if you're not necessarily using all of the facilities that allows. If you want bare-metal then you need qemu-system-sparc64, but your program needs to actually be compiled to run correctly on the specific machine type that you tell QEMU to emulate (eg the Sun4u hardware, which is the default). Also, by default qemu-system-sparc64 will run the OpenBIOS firmware, so your bare-metal guest code needs to either run under that OpenBIOS environment, or else you need to tell QEMU not to run the BIOS (and then you get to deal with all the hardware setup that the BIOS would do for you).
I'm having a hard time finding a solution to access my Linux guest system running on QEMU from my macOS Big Sur host.
The only solution I've found that works is port forwarding (using e.g. -net user,hostfwd=tcp::2200-:22 for SSH). This works, but is not convenient since I need to forward all the ports I need to use, and I would like to be able to use scripts, applications, etc. without having to tweak the ports everywhere.
So having an IP to connect from the host to the guest would be best, but surprisingly I couldn't find an easy to do so.
I was trying to achieve a similar setup and the approved answer was a big help.
By using QEMU 7.1+ you can make use of Apple’s VMNET framework for networking with VMs without port forwarding.
QEMU makes use of this with -netdev vmnet-shared / vmnet-bridged / vmnet-host
More detail can be found on the man page man qemu-system-aarch64
I have a short summary here: https://gist.github.com/max-i-mil/f44e8e6f2416d88055fc2d0f36c6173b
The only articles I found online related to this seem to be valid only for older versions of macOS.
Looks like newer versions of macOS have a new mechanism for this, called vmnet.
And a patch for QEMU was implemented recently: https://gitlab.com/qemu-project/qemu/-/issues/465
With this patch, using -nic vmnet-host makes the guest accessible from the host (on an interface called bridge100).
At the moment, the latest stable release of QEMU (7.0.0) doesn't include this patch, but it's possible with brew to build the latest HEAD from git, which includes this change (but can't be considered stable!), using brew install qemu --HEAD.
Afterwards, make sure to use the correct qemu binary, by updating your PATH env variable or executing the binary with full path directly. Should be something like this: /usr/local/Cellar/qemu/HEAD-7077fcb/bin/
socket_vmnet might solve your problem
https://github.com/lima-vm/socket_vmnet
As Lima claims
The guest IP is assigned by the DHCP server provided by macOS. The guest is accessible to the internet, and the guest IP is accessible from the host.
I'm using qemu to replace bochs (since it doesn't update anymore)
In bochs, I can save the running settings into files and reload it. Furthermore, there will be a listed table of running options while boot up.
I'm wondering if I can do the same with qemu, save running settings such as cpu model, and other stuffs into some files and reload it next time I run emulation.
And if there exists a full listed running option table like thing for me to have a complete view on which options I can set.
Thanks a lot!
For this sort of UI and management of VMs you should look at a "management layer" program that sits on top of QEMU. libvirt's "virt-manager" is one common choice here. A management-layer will generally allow you to define options for a VM and save them so you can start and stop that VM without having to specify all the command line options every time. It will also configure QEMU in a more secure and performant way than you get by default, which often requires rather long QEMU command lines.
QEMU itself doesn't provide this kind of facility because its philosophy is to just be the low-level tool which runs a VM, and leave the UI and persistent-VM-management to other software which can do a better job of it.
I have read about the advantages of using a BitNami stack for LAMP development, now I am wondering if there are any drawbacks to using BitNami vs manually installing PHP, MySQL, and Apache separately. I use Mac OS but I would be interested on how it applies to both Mac and Windows. Any thoughts?
I am one of the developers of BitNami. Whether to use a native stack or a BitNami stack depends on what you are trying to do. Installing the individual items separately should be exactly the same as running our installer, and the whole purpose why we put the installers together is so you would not have to :) In the case of Mac, one of the advantages of BitNami is that you can have more up-to-date components and multiple installations. A disadvantage / difference is that the applications and path will be different than the typical ones so if you are using third-party tutorials or documentation, it may not work right away
There are 3 common drawbacks to Bitnami vs. a native LEMP/LAMP stack:
File paths. Because Bitnami is a container approach to web stacks, it installs everything in Ubuntu (or whatever Linux distro) under the /opt/bitnami directory. So, many developers who are used to customizing their stack using nano or vim editors (via the Bash shell) quickly discover that you first have to figure out where all the different configuration files of your stack modules reside, etc. Even after you figure those out, most of the online tutorials and documentations you might find will not apply to your stack.
Lockdown. This could be seen as either an advantage or a disadvantage, depending on your perspective (and situation). The entire point of using a containerized approach is to have more control of the stack environment, which can improve compatibility, predictability, security, and otherwise. However as #team-life mentioned, this can quickly become frustrating when you are trying to use "standard" Bash shell commands or even the MySQL CLI, e.g. when trying to analyze or replicate your stack, etc. To put it simply, logging into shell on a server where Bitnami is installed is not in fact logging into the actual shell :)
Upgrades. At the end of the day, Bitnami (and other containers, like Docker) are adding another "layer" to your stack, and thus, more bloat. For some users this "bloat" is justifiable, and preferable (for example, very large companies who require across-the-board uniformity). But what many developers discover with Bitnami and containers is upgrading your stack can be rather janky. For all the alleged advantages in terms of environment "stability", it turns out that upgrading your stack can actually introduce quite a bit of instability and unpredictability, often to the extent of canceling out the benefits. As #domi mentioned, all upgrades run through Bitnami (and not Ubuntu mirrors, etc) meaning you are bound to their versions and release schedules; you are also often required to completely re-install the stack again...
Ultimately, containers are a recent trend that have become very popular among so-called "enterprise" and "corporate" in-house teams, but it is one of those things that might not be the best features for smaller agencies or independent developers to embrace.
That is why native LEMP stacks like SlickStack (my project) are gaining momentum.
This Reddit thread has a few other AWS-specific comments as well.
BitNami uses paths that will be very different from the industry standard ones so if you are trying to login to a server to do some task, it will take you a lot of time to understand their custom-made-folder-structure. And that's a big drawback. When you login to a unix server, you know where the files and paths are, maybe you have one or two options, that are standard. BitNami uses a completely different one. Chaos ensues.
I'm a happy bitnami stack user. It's a great stack. I can describe many advantages.
The draw back of using bitnami stack is the update cycle. For example on Debian/Ubuntu based system, you can not use the standard apt-get update/upgrade.
That means some security updates might not get to your system as fast as your standard cron (automated periodic) update mechanism.
To upgrade the system you will need to create backup, install a new stack, then import the backup to the new stack. Which might not be an ideal procedure.
Some people categorize that as non-production-environment.
Bitnami - ease of use, validated components - known working good configuration.
Disadvantage - Patches and updates. you cannot update packages for security like you can for native install. Any bulletins must be addressed by the bitnami team, who may/will roll out an update to address issues. The bitnami updates are full stack upgrades, meaning you can't just upgrade a single component (php for example) - you need to upgrade the whole bitnami stack, and the often recommended method is to backup your application database, install a parallel bitnami stack that has the latest updates, then restore or migrate to the new installation.
Some will tell you that you can shoehorn patches into bitnami stacks, but it's not at all recommended, will lead you off the stack and most likely cause you down stream issues.
Bitnami evidently is unable to use certain commands from their mysql command line. I'm finding this very frustrating. Here is some stuff I found out.
It puts you into its own bash shell bash-4.2#
mysql>SHOW MASTER STATUS returns -> (nothing) doesn't seem to work
rcmysql start or stop doesn't work from mysql> you have to shell out of where your at and run the ctlscript.sh which is a pain.
Just to get to command line you have to run ./use_lampstack
I'm guessing that they are giving us a very paired down mysql group of commands because there will be less for them to support and less for people to jack up.
So this came up for me because I was trying setup replication. I was following directions from someone who had a "regular" install. It was difficult to follow because most of the commands he was suggesting didn't work from the bitnami mysql> command line. So while I really like the uniformity of Bitnami and the modular nature of it I have run into a snag trying to setup replication.
I want to know if it's possible and I'm looking for tutorials to set it up.
APE website says that knowledge of JavaScript programming is sufficent to follow the tutorial however I haven't been able to puzzle even the first 2 lines of the tutorial.
I'm using Ubuntu. After downloading APE I have no idea what to do. I already set up SSH to access the server.
What should be my following steps or where can I find an easier to tutorial to use comet be it through APE or something else?
Assuming your GoDaddy server is running some flavor of Linux, I don't see any reason it would not be possible. I was just looking over the documentation and I am not clear on what part you are having trouble with. What Linux distribution are you using? Do you have SSH access?
If you have ssh access and a root account you should be able to just follow the instructions to get APE running on the default port.
If you are running a Debian dist (Ubuntu and others) it looks like you should download the source from Git and compile it. There are instructions for the compilation there. You can learn about what you need to do wth Git by search for "clone git".
If you can be more specific about what you are having trouble with, we can probably be more helpful. But ultimately you should be able to install this on any dedicated server without issue.