Guys,
i have some expereince with Virtualbox and i thought i should experiment with Xen.
Via yast, i installed Xen. To create guest machines, yast tells me that i have to reboot with the xen kernel and create virtual machines from there.
But when i reboot and pickup the Xen entry to bootup, it boots up into a blank screen…no command prompt , no X …just a blank screen…
Any advise?
Regards,
Marco.
To use Xen, there are several steps to perform.
http://xen.org/images/globals/xen_logo.gif
Check out their Web Site here: Welcome to xen.org, home of the Xen
Read Through their Documentation Here: Documentation Support
If you are ready to continue and install Xen into openSUSE 12.1 64 bit then do the following:
At present, openSUSE 12.1 only supports 64 bit Xen. The management of Xen is totally from a terminal prompt. Refer back to the Xen Documentation for all other questions.
Thank You,
Thanx a lot, i think i bungled step 3 and step 5.
Step 5 must be used on each startup, so if you missed it once, you can use it later. Networking can be fixed later as well, but apparently its never as easy as when first done from YaST. In any event good luck with using Xen.
Thank You,
Did not know that too…was re-reading your earlier post…looks like i have bitten off more than i can chew…
What I was hoping to accomplish was the ability to have a few distros running at the same time upon bootup…example;
Is Xen a good fit for this ? Or KVM ? or VMWare?
Currently i use VirtualBox and start each one as needed. But i just noticed that in 12.1 you can autostart the virtual machines automatically - though i am not sure if the machine needs runlevel 5 for that to happen. I am looking for a runlevel 3 type scenario…
What has been your experience so far in this context?
I would use kvm, because kvm is easier and doesn’t require a special kernel.
Install libvirt-client and read virsh manpage
man virsh
The virsh shell allow you administrate domains, connect to hypervisors, start, shutdown and modify virtual machines, and many other things. Of course, you can put commands in a script and run it in after.local in both system V and systemd. It might be a little more tricky in systemd, but search in the forum on how to get after.local working in systemd.
I use virsh within scripts to create (and of course start) kvm virtual machines on the comman line. See this thread: http://forums.opensuse.org/english/other-forums/development/programming-scripting/453962-vm-create-create-kvm-virtual-machines.html.
I have another script to create/delete bridge on the fly: http://forums.opensuse.org/english/other-forums/development/programming-scripting/453961-vm-bridge-convert-virtual-machines-nat-bridge-bridge-nat.html. It can also convert kvm virtual machines from bridge to nat and vice-versa.
If you like to have a look or try these scripts, they are also available (with some other tools) in a single package called vmscripts. You can install it from my repo: https://build.opensuse.org/package/show?package=vmscripts&project=home%3Aplease_try_again
I’m too busy to provide support for these scripts at the moment. They might need some minor updates. However I used cutting edge libvirt versions on ArchLinux, Fedora and from the openSUSE virtualization repo to write them. I would assume that they work fine with the libvirt version from the standard repo.
virsh (the libvirt shell) and virt-manager (the libvirt GUI) can manage kvm and xen virtual machines. Actually I read that they could also manage vitualbox machines, but I don’t know how. vm-create could (but probably won’t) work with xen, because it has never been tested. It is able to identify xen specific MAC addresses (they all start with 00:16:3e) and connect to a Xen hypervisor (I guess). If you have the choice, use kvm.
You are a goldmine !!!
Guys, got this article from Data Center Management information, news and tips - searchDataCenter.in, very very informative. I understand the issues better now…
A. Six reasons to choose Xen vs. KVM
By Andi Mann, Contributor
When comparing Xen to KVM for open source virtualization, Xen wins out for six compelling reasons: Better resources, platform support, manageability, implementation, live migration and performance benchmarks.
Resources: Xen has been in the public domain for four years longer than KVM (2003 vs. 2007). With implementations from Citrix, Novell, Oracle, Sun, Red Hat and Virtual Iron, it is easier to find IT professionals with Xen skills, easier for those professionals to get Xen training, easier to locate Xen consultants and obtain Xen certification. These are critical issues for 60% of enterprises who say they lack essential virtualization resources and skills, according to research from a 2008 report on virtualization and management trends by Enterprise Management Associates (EMA).
Platform Support: Xen currently supports more host and guest environments, including paravirtualized, hardware assisted and both modified and unmodified guests; UNIX, Linux and explicit support from Microsoft for Windows; multiple chipsets including x86, IA64, and ARM from AMD, Fujitsu, IBM, Sun and embedded support from x86/64 CPU vendor, Intel.
Manageability: For 83% of all enterprises, says 2009 research on virtual systems management from EMA, management is a critical or important factor in choosing virtualization technology. In the comparing Xen vs. KVM comparison, Xen has a much broader third-party ecosystem for provisioning, backup, storage management, P2V, capacity planning, performance monitoring, process automation, security and other management disciplines from Citrix, IBM, CA, Novell/Platespin, Enomaly, Microsoft, HP, Quest/Vizioncore, Sun, Oracle, Symantec – and even VMware (via Hyperic). Even Red Hat has no sophisticated tools available for KVM today, and its promised KVM management will lag for the foreseeable future.
Implementation: Whether KVM is ‘type 1’ or ‘type 2’ is mostly semantic. Xen is run and managed at a lower level (ring 0), even for new virtual machine creation, and guests do not share memory blocks, CPU instructions or any of the underlying (albeit occasionally de-privileged) Linux operating system like KVM does. This means KVM suffers performance, latency, security, scalability, isolation and other issues that do not affect a true bare-metal hypervisor like Xen.
No live migration with KVM: Most of the arguments used in the past to show VMware ESX superiority over Microsoft Hyper-V, also apply to Xen in comparison to KVM today. But this is the big one. Unlike KVM, Xen supports uninterrupted live migration to allow dynamic workload balancing and routine maintenance with near-zero downtime. KVM comes with an inherent downtime penalty.
Performance: Most Xen vs. KVM performance benchmarks show Xen has better (near-native) processing performance, and only marginally underperforms KVM in disk I/O. Moreover, independent tests have shown that KVM performance suffers as more workloads are added, and it consistently crashed trying to support any more than four guests. Xen supported a linear increase to over 30 concurrent workloads.
A more comprehensive Xen-KVM comparison would also show that Xen outperforms KVM with virtual network support, virtual storage support, enhanced security, high availability, fault tolerance, power management, HPC/real-time support, virtual CPU scalability, cross-vendor compatibility, VM portability, virtual appliance marketplace and an established cloud services ecosystem. So while KVM is technologically impressive and has some excellent use cases, it is still far-inferior to Xen as an enterprise-class server virtualization technology.
B. KVM over Xen for better Linux integration
By Sander van Vugt, Contributor
Even without performing an extensive Xen vs. KVM performance benchmark study, there are very solid reasons to follow Linux leaders like Red Hat and Ubuntu to KVM. The most obvious and important factor is that KVM is a part of the Linux kernel, while Xen is a product that is installed beneath a Linux kernel.
Why is this important? It’s important because, in the past, patches to the Xen environment have proven to be incompatible to the Linux kernel. By implementing KVM, this problem is easily solved. Another reason to select KVM is because KVM is implemented in the Linux kernel itself. Consequently it is easier to control virtualization processes.
Xen advocates argue that KVM is not as mature as Xen and lacks key features such as live migration and paravirtualization. It’s true that paravirtualization in a Xen environment makes machines operate more efficiently since they can address hardware directly. However, to use paravirtualization, you need a modified operating system. A default Windows installation just doesn’t work in a paravirtualization environment. About Live Migration, that does work. You just need the right KVM version to do that. Yes, there was a problem with live migration in the past, but that is fixed now.
KVM, on the other hand, is more flexible. Since the operating systems are communicating to a hypervisor that is integrated in the Linux kernel, they can address hardware directly in all cases, without the need to modify the virtualized operating system. This is significant because it makes KVM a faster solution for your virtual machines. The fact that KVM needs the Pacifica (AMD) or Vanderbilt (Intel) virtualization CPU is hardly a limitation because the majority of server CPU’s currently have these processors.
The one credible argument not to choose KVM virtualization is that Xen has been around longer and is a more mature product. Long term, however, Xen will become more and more a burden for your Linux kernel, because it lacks good integration – and never will – despite the fact that Xen developers are actively working on the integration problem.
The bottom line is that KVM is a part of Linux and Xen can, at best, only be integrated with Linux. Over time, Red Hat, the number one player in the Linux enterprise market (which currently owns KVM technology) will make sure that up-and-comer KVM is as fully-featured as Xen. The future belongs to KVM.
James, please, can you give me more details about the step: “5) Press F5 and select System V (Do not use systemd with Xen at this Time)”? I am using xen installed via yast in Opensuse for a year with repeated problems. And your note about step 5) with F5 is the first one I found and it seems it could explain my problems. Please can you give me a link for deeper description or advice me: more exactly when to press F5? During boot of machine or boot of Linux? Booting of HW is pretty long with disk controllers phase and BIOS phase, etc. What exactly is activated by F5?
Many thanks in advance,
Hynek
Using F5 and switching to SystemV was only for openSUSE 12.1 users, as it says in the title and not for use with an earlier version of openSUSE. I suggest you start a new message thread of your own and describe the exact problem you are having. You are in the right forum section, but this message thread does not relate to the problem you are having.
Thank You,
James,
thank you very much for your answer. In fact I would like to install XEN in openSUSE 12.1 as well. Thank you in advance for any simple link to some document, whre the details are given.
Thank you,
Hynek
http://xen.org/images/globals/xen_logo.gif
[size=4]Welcome to xen.org, home of the Xen[/size]
Xen Documentation Support](Documentation - Xen Project)
If you are ready to continue and install Xen into openSUSE 12.1 64 bit then do the following:
At present, openSUSE 12.1 only supports 64 bit Xen. The management of Xen is totally from a terminal prompt. Refer back to the Xen Documentation for all other questions.
Thank You,
James,
thank you for your details as well as your patience. 12.1 has lots of news and in fact I missed very basic page:** Product highlights - openSUSE** with details of the System boot process. In fact I could find this page when used info from your recommendations for google search.
Many thanks,
Hynek
Ok but I install OpenSuse with No X Support, then when I go into yast The Virtualization option doesnt exist unless I install DomU-tools, then I can see Virtualization available at yast.
Then if i select install Hypervisor & Tools it creates some dependency problems.
How come Virtualization is not enabled by default at Yast when I install the OS at first time???
This is so annoying, it is driving me crazy.
After I am finished with this I will write this Documentation which doesnt exist and will rock the whole thing for once and for all.
