As part of my infrastructure I have many Virtual Machines running different Linux distros, under Proxmox using OpenVz. My problem is that I need to export into a personalized installable ISOs some of the VMs I have, (installable snapshots of the current state of the VMs), some of them are running Ubuntu, some of them CentOS, so my question is:
1- Is there a way I can do this aware of the OS the VM is running?,
2- Exporting VMs to ISOs the way I just explained is the way to go or is there any other approach?
I'm open to any advice from those how has experience with this subject even if I have to setup different Virt. Technology to host the VMs.
Your question is pretty vague on your requirements. I'll try to give you some ideas:
What do you mean by "Current state"? If you really want all the running processes, then you should something like VirtualBox and take a snapshot. You can easily boot that up on another computer and continue running where you left off, and it's independent of the OS.
If you really mean just the filesystem, then just copying the filesystem and burning it on a CD is unlikely to give you good results. For instance, there are many areas that are expected to be writable (/var, /tmp. even /etc for /etc/resolv.conf)
One simple idea is to just 'tar' up the filesystem, and untar it on another OpenVz distro. (I'm sure someone has made a bootable OpenVz distro..)
If you want a real bootable ISO, there are a LOT of different options. For example, you could have the kernel mount the ISO as root. Or you could boot to a RAMDisk as root, and unpack the filesystem you need. Or you could mount the ISO as root with an AUFS overlay filesystem. Or you could mount some directories as a SquashFS filesystem onto a RAM root.
But if you really want simplicity in "moving VMs around", look into Docker. It has a simple way to push a filesystem up to a public or private server, then download it on the other side, but save bandwidth on common elements like the OS and Apache installs. (If you do it right.)
Related
I have a qcow2 file that contains windows 10. The operating system is RHEL8.2. The virtualization stack is kvm, qemu, virt-viewer. And the command line used to manipulate the virtual machine is 'virsh'.
I need to update the windows drivers and kernel, change some registry, uninstall some applications, add things to the task scheduler and more.
My question, is what is the best process to acheive this? Is the result should be a new qcow2 file? Are there changes required for the xml configuration file of the virtual machine?
There are 2 modes of editing the virtual machine, online and offline. The difference is if the virtual machine is running during the edit or not. What mode is best to perform the task described above?
As I understand, snapshots are stored inside the qcow2 file, and then the user needs to pick between them. The users, on the system I am working on, are not aware they run on virtual machines, so I can not use this path, unless I am missing something.
Also there is the 'managedsave' and 'save' commands for virsh, but they don't create a new qcow2 file, and I don't think that the commands are meant for it.
Finally I found that the qcow2 file can be mounted as a device, perform changes in it, and unmount it. But then how can I uninstall applications and more in this way?
Thank you!
All the changes you described (update the windows drivers and kernel, change some registry, uninstall some applications, add things to the task scheduler and more) affect only the guest disk - qcow2 file, and guest memory.
You can run the guests, do these changes and power off. All changes will be saved to the guest disk. When instead of poweroff you will suspend the guests, some of the changes can be saved in guest memory.
There are no changes needed for the xml configuration file of the virtual machine, no new qcow2 files will be created.
Yes, snapshots are stored inside the qcow2 file, but since you have a copy, you dont need to create snapshots. Also no need for 'managedsave' and 'save' commands.
I'm developing for a Linux-based embedded system, where I have a build process from hell, at least to generate a full flashable binary -- tons of dependencies, proprietary compiler, etc. To make development setup easier for new developers, and uniform across our development team, I've adopted Vagrant. But, there's a snag...
So Vagrant spins up a VM and provisions it with our dependencies and tools. Then it mounts the source tree on the host within /vagrant on the VM. However, we cannot build within this directory -- mounts between the host and the VM do not support mmap (at least not in Virtualbox), which the build relies upon. With our developers that run OS X, things are even worse as their host OS is HFS+, case-insensitive out of the box -- the build requires a case-sensitive FS. So developers are forced to work within the VM, which is constraining if you're used to particular development tools in OS X say, and simply want to use the terminal for compilation.
Seems what's needed is a real-time (e.g. inotify based?) bi-directional sync mechanism that would keep /vagrant in sync with say /home/vagrant, which is not a mount point but simply part of the VM's ext4 fs, so produced/edited files and symlinks are synced. Is there such a mechanism? Closest thing I've found is aufs, but I'm not sure that does what we want.
I ended up using NFS (included within Vagrant and OS X) and it's been working well for a couple months now.
Can anyone tell how I might best mirror selected files and folders to a NAS, (Network Addrssable Storage) box from a Linux workstation in real-time?
These are very large files, (> 50GB) and are being continually modified, so I would only like to change those portions of the files that have been changed, added or deleted.
FYI: These files are actually Virtual Box virtual hard disk (VDI) files.
I discovered that my Synology DS211J NAS can run an RSync service. So I enabled that and used lsyncd for the live mirror... the VirtualBox VMs... all works very well.
Rsync only synchronises the parts of files that have change and so is very efficient at synchronising large files.
Of the solutions that #awm mentioned, only drbd provides block-level, realtime synchronization. The other tools will meet your goal of only propagating deltas, but they operate asynchronously. In fact, rsync will work just as well in this case, since you're not trying to provide bi-directional synchronization.
For drbd to provide block-level replication, you need need to install the drbd kernel modules and userspace tools on both the workstation on the NAS...which means this solution is only appropriate if your NAS is actually a fairly generic Linux box over which you have a great deal of control.
Before hand I just want to suggest that you don't do this. You can easily bottlenet your network and NAS and cause all sorts of problem on your host.
That being said, these claim they can do it:
Unison can be found at: http://www.cis.upenn.edu/~bcpierce/unison/
PeerSoft can do it too: http://www.peersoftware.com/products/peersync/peersyncserver/overview.aspx
Maybe - http://www.drbd.org/
I'm studying for a CS degree, and I need to install Ubuntu for a computer systems class. We are going to do low level Assembly optimizations and stuff like that, so they don't want us to install it in a VMware.
Now, I don't want to do a regular dual-boot install, because I've already done it on my previous computer a couple of years ago, and wrecked my hard-disc with the partitioning. Wikipedia says you can use Wubi to boot Ubuntu from ISO, or install it to a flash drive and boot it from there, and then thus remove the need for partitioning.
Now, my question is - how different it is to program for Ubuntu booted from a regular hard-disc partition, from a Wubi ISO, and from an SD card? I guess the programs will work the same on all options, but we're going to do play with low level Assembly optimizations - can I expect to face any difference in that department?
I'm not sure I'd go this route if it were me personally.
You should be fine in terms of whatever bare metal type stuff you want to do -- you're working with memory, the cache, the chip, etc, so your disk drive shouldn't matter (unless you're doing stuff to the filesystem or something).
Where I think you might get annoyed is the logistics of setting up your development environment. Everytime you boot from your USB stick, you're going to need to sudo apt-get GCC, scite, et. al, load your files on into directories that you want, and then get started. That's a hassle. You could optimize this somewhat by creating a custom ISO of your environment using some kind of tool (you might be able to do it with Clonezilla), but still.. yuck.
I would suggest (speaking of Clonezilla) that you snapshot your hard drive, go ahead and install dual booting with Ubuntu, and then you have a backup if anything goes wrong. Or, I'd think you could get by using the school's machines. Don't they have any Linux boxes that you can ssh into, if not use in labs?
Anyway, good luck. :)
i Just got the book Linux Kernel Development by Robert Love . It has lots of places where you are required to modify and build the kernel . So how should i go with it . Is it better to use a VM , or should i somehow get a proper test machine for it , since i dont want to goof up on my system and data.
A VM has the advantage of offering snapshots. These allow you to save the state of the machine - if the kernel build doesn't work you simply restore the snapshot, and you are able to take as many snapshots as you have disk space to store them. You are also able to clone and re-deploy the VM image, so you have many identical systems to test on.
The same experiment on a physical machine would require far greater effort (ghosting/cloning the disk, re-installing the OS etc).
VirtualBox is free, cross-platform virtualisation software.
There are a lot of tutorials on the web about this topic, e.g. here:
http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html
http://www.kernel.org/pub/linux/kernel/people/gregkh/lkn/lkn_pdf/ch04.pdf
You could do either or both. An alternative somewhere in between is to setup a dual boot. This is a little riskier than a VM, but not too much.
coLinux
or run linux iso image using QEMU on windows