Re: [opensuse] Xen: Is it Ready?
Hans Witvliet wrote:
On Fri, 2008-04-11 at 06:25 -0600, Donald D Henson wrote:
I have a situation where I need Windows & Linus running at the same time. I currently have Linux (server & workstation) running on my server hardware and Windows (workstation) running on a network connected laptop, a satisfactory workaround but hardly a long term solution. I'm thinking of using XEN to run both Linux & Windows on my server hardware. My problem is that no one I trust has actually used XEN in the above configuration. However, I've found that this list gives consistently good info if you ignore the obvious newbies and the occasional flame war. so...
Has anyone used Xen running Linux & Windows on the same hardware? If so, is it ready for a production environment? Did you notice any performance degradation? Are there any gotchas that can be avoided? I'd sincerely appreciate answers to my questions and any comments you may have.
Don Henson
Hi Don,
(Excuse me for long reply) Instead of second, third hand or worse, at work we use xen rather intensively. For some purposes it's nearly it-heaven, but not alwaays, depends on what you want to do with it.
Firstly, you are aware that for doing windows as a dom-u (xen-client) you need special hardware emulation CPU's like the intel-vt. xen-source is working on PV-drivers (see their lists), but they are still in beta-stage. As said, you need to run windows in hardware-virtualisation mode. I have M$-XP running on a HP-DL385 dual xuad-core xeon. Just plain xp installed, worked normally, as fast or as sluggish as on my work-desktop. I did *not* try any special programs that were touching hardware directly. I just installed it to show to our managers that it was possible.
On the same box, i had many, many para-virtualized xen-servers running. Most of them are LAMP-machines, ldap-servers, KDE3/4-desktops and so on. Clients are either 10.1/10.3 or Ubuntu-gutsy.
Did not succeed in getting any *BSD client running stable.
On that kind of machine, 24GB mem, obviously the DOM-0 runs in 64-bit mode. As all of the clients run with 512MB-2048MB i really did try to have all of the clients to run as 32-bit-pae machines, but i quite as they are not stable, at least with xen-3.1. All of my clienst are back to native 64-bit.
Be carefull during maintenance. If you kill the network (or more) on the DOM-0 all of the children will feel the concequence...
I can do live migration over my network, as all the DOM-0 machines share the images on the same SAN.
If you want easy scaling or doing frequently projects/tests, xen works great, if mind the traps mentioned above. Beside SAN, i should strongly recommend the use of LVM, for being able to resize the images. Start small, and let them grow if needed.
Hans
Thanks to all who responded to my initial inquiry. A special thanks to Hans for sharing his experiences. Hans, don't worry about the long response. It was just fine. As I tell my students when they ask how long a paper should be: Your paper should be like a woman's skirt, short enough to be interesting but long enough to cover the subject. Don Henson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
2008/4/12, Donald D Henson
Hans Witvliet wrote:
Hi Don,
(Excuse me for long reply) Instead of second, third hand or worse, at work we use xen rather intensively. For some purposes it's nearly it-heaven, but not alwaays, depends on what you want to do with it.
Firstly, you are aware that for doing windows as a dom-u (xen-client) you need special hardware emulation CPU's like the intel-vt. xen-source is working on PV-drivers (see their lists), but they are still in beta-stage. As said, you need to run windows in hardware-virtualisation mode. I have M$-XP running on a HP-DL385 dual xuad-core xeon. Just plain xp installed, worked normally, as fast or as sluggish as on my work-desktop. I did *not* try any special programs that were touching hardware directly. I just installed it to show to our managers that it was possible.
On the same box, i had many, many para-virtualized xen-servers running. Most of them are LAMP-machines, ldap-servers, KDE3/4-desktops and so on. Clients are either 10.1/10.3 or Ubuntu-gutsy.
Did not succeed in getting any *BSD client running stable.
On that kind of machine, 24GB mem, obviously the DOM-0 runs in 64-bit mode. As all of the clients run with 512MB-2048MB i really did try to have all of the clients to run as 32-bit-pae machines, but i quite as they are not stable, at least with xen-3.1. All of my clienst are back to native 64-bit.
Be carefull during maintenance. If you kill the network (or more) on the DOM-0 all of the children will feel the concequence...
I can do live migration over my network, as all the DOM-0 machines share the images on the same SAN.
If you want easy scaling or doing frequently projects/tests, xen works great, if mind the traps mentioned above. Beside SAN, i should strongly recommend the use of LVM, for being able to resize the images. Start small, and let them grow if needed.
Hans
Now that you mention it, how do you use LVM on a LUN with more that one dom0 accessing the VG? Ciro -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2008-04-12 at 07:59 -0400, Ciro Iriarte wrote:
I can do live migration over my network, as all the DOM-0 machines share the images on the same SAN.
If you want easy scaling or doing frequently projects/tests, xen works great, if mind the traps mentioned above. Beside SAN, i should strongly recommend the use of LVM, for being able to resize the images. Start small, and let them grow if needed.
Hans
Now that you mention it, how do you use LVM on a LUN with more that one dom0 accessing the VG?
Yes, i have to confess, it's a bit tricky. All the dom-0's have with their fibrechannel cards full access to the same part of the san. Normally, when you try to launch the same dom-u twice from a single dom-0, xen will protect you from this mistake. In our case, there is no protection at all two dom-0 can launch the same dom-u, which leads to complete disk-image corruption is seconds. So i took following steps: a) a lamp-site with a bundle of scripts looking at all the dom-u and dom'0. reporting what runs where b) all our (Suse) dom-u are build entirely from an xml-description - universal disk-layout - fixed thread / packet selection - predefined sysconfig settings - length post-install scripts c) good backup/restore with rsnapshot ! Does that answer your Q? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
2008/4/12, Hans Witvliet
On Sat, 2008-04-12 at 07:59 -0400, Ciro Iriarte wrote:
I can do live migration over my network, as all the DOM-0 machines share the images on the same SAN.
If you want easy scaling or doing frequently projects/tests, xen works great, if mind the traps mentioned above. Beside SAN, i should strongly recommend the use of LVM, for being able to resize the images. Start small, and let them grow if needed.
Hans
Now that you mention it, how do you use LVM on a LUN with more that one dom0 accessing the VG?
Yes, i have to confess, it's a bit tricky. All the dom-0's have with their fibrechannel cards full access to the same part of the san.
Normally, when you try to launch the same dom-u twice from a single dom-0, xen will protect you from this mistake.
In our case, there is no protection at all two dom-0 can launch the same dom-u, which leads to complete disk-image corruption is seconds. So i took following steps: a) a lamp-site with a bundle of scripts looking at all the dom-u and dom'0. reporting what runs where
b) all our (Suse) dom-u are build entirely from an xml-description - universal disk-layout - fixed thread / packet selection - predefined sysconfig settings - length post-install scripts
c) good backup/restore with rsnapshot !
Does that answer your Q?
So, basically, all your hosts see the same VG and LVs and mount the needed LV leaving you as the sole barrier to havoc? What about LV resizing? Ciro -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (3)
-
Ciro Iriarte -
Donald D Henson -
Hans Witvliet