Dario Faggioli <raistlin at linux.it> writes: > On gio, 2014-06-12 at 07:17 +0200, lee wrote: >> Lars Kurth <lars.kurth at xen.org> writes: > >> Let me wear the hat of the user. The major hurdles were network setup, >> installing something in a vm, and the chaotic state the documentation is >> in. >> > Wow... "chaotic state" :-O > > Don't get me wrong. I know everything can always be improved, and > documentation is --for free software in general, which well includes > Xen-- often in a position of needing _a_lot_ of improvement. > > All that being said, it would be helpful if you could be a bit more > specific and help us actually improve it. It's really difficult to be any specific because I have to piece together information from whatever sources are available through search engines and by trial and error. Perhaps take practical questions and try to answer them from the documentation you can find, for example: I have an installer for distribution X. How do I install the distribution in a VM? How do I make sure that a particular network interface I have in dom0 will always show up as a particular network interface in domU? What is an xvda device, what are the impacts of using one instead of, for example, /dev/sda, and how are the devices named when I have several of them because after installing a VM, I want to give it access to another logical volume: xvda1, xvda2, etc., or xvdb, xvdc, or something else? Why does it say "I need more memory ..." when trying to create a guest with xm? Can't I do memory overcommittment? My dom0 has plenty of swap space. What are the effects of overcommitting CPUs? Should I rather limit the VMs tightly or give them CPUs so that they can be used as needed instead of being left idle? Do I need to load a particular module in a VM to be able to give it more memory with xm? What happens when I give a VM more memory and then take it away after a while? How do I make it so that memory is assigned to VMs dynamically up to their maximum allowed amounts, depending on how much memory a VM currently happens to need? Why gives "xenpm get-cpufreq-states" no output? Why do I get an entry "(XEN) physdev.c:168: dom0: wrong map_pirq type 3" in xm dmesg, and what is it supposed to tell me? When you assume you're new to using xen and try to answer questions like this from whatever documentation you can find, you'll probably see what I mean :) > I think you've said, in another thread, that you requested editor > access to the wiki, but don't know what status such request is in > (provided I'm not mistaking you with someone else, in which case, > sorry! :-P). Can you double check, so that we can see how to move > forward and allow you to act instead of only complaining. :-D I think the request has been successful. I'm still working on getting everything set up and didn't get to look into editing the wiki yet. >> As a user, I'm used to get an ISO of an installer or of a life system, >> put that into a DVD drive or write it to an USB stick and to boot from >> that to do the installation. Why can't I do that with xen? >> > Wait, what? Who said you can't do it? Of course you can! In fact, if you > tried and it failed, please, report the bug within the appropriate > channel, because a bug is what that is, nothing less! :-O Well, how do you do that? IIRC, I followed http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer, and it installs squeeze instead of wheezy. Apparently you require a special kernel and initrd.img to install something in a VM --- so how do you install something else? > However, I think we're talking about something different here... > >> > == #1 virt-install == >> > == #2 xen-tools == >> > == #3 virt-builder (http://libguestfs.org/virt-builder.1.html) == >> > == #4 Cloud Image from Cloud Image SIG == >> >> I wouldn't want #4. I want to be able to just use the installer of >> whatever distribution I'm installing in a VM and a simple way of saying >> "run this in a VM and let me install". Or perhaps I merely want to run >> a life system in a VM to try it out, with network access. What easy way >> is there to do that? >> > I'm not sure I got what you mean with 'I merely want to run > a life system in a VM to try it out'. If you mean trying out Xen in a > VM, then of course you need a nested-virt capable platform. No, I was assuming that I have a dom0 running and decide, for example, that I want to try out the live DVD of some Fedora spin in another VM. > If you have one, here's the instructions of how to create a Xen > liveCD. I'm afraid both the instructions and the liveCD are Fedora > based, but it should not be a big deal to bias them toward CentOS: > > http://lists.xen.org/archives/html/xen-users/2014-06/msg00065.html Oh I've seen this page --- it wasn't was I was looking for, though. > I also don't know much of #3, but at least #1 and #2, are both meant > at doing exactly what you're saying: "install this in a VM", they only > happen not to require install DVDs. I understand that DVDs are your > preferred method, but that doesn't make it the one _everyone_ prefer! An installer is merely what I find or have when I want to install a distribution. Suppose I'd want to try out Mint. I'd look at their website and download one of the versions. I'd burn a DVD or CD or write it to an USB stick and boot from that. With xen, what do I do instead? It seems I need a special version to get a VM running with it. Where do I get this special version? > AFAIUI, when talking about this kind of provisioning, what we're > interested is something a lot more automated and, as a consequence, a > lot less interactive than an installer. Wouldn't that depend a lot on what you're trying to do? Some people suggest to do a basic install and then to copy that. >> I always admire the documentation exim has ... As to your original >> question: >> >> > I was wondering whether we need to look at a standard way in which we >> > recommend how to provision images for VMs. >> >> I'd suggest to start with splitting the documentation into different >> versions, one version of documentation for each version of xen. Some >> way to get a VM running may then be discovered and improved upon. >> > Personally, I don't think that would be the optimal split, or something > we need to do right now (which does not mean we should not improve docs > in other ways). The documentation would be much easier to read without having to filter it for the version of xen that is being used. Why not just copy the current documentation when the next version is released and remove the cruft? Then you can simply say "it goes like this" instead of having to say "it might go like this but only if you're using that version, and perhaps this way will be removed, but you might be using something that could be deprecated in the next version, so don't use this but there are five other ways to do it ...". For things removed just say 'removed, see feature X', and for new things, mark them as 'new in the current version'. This helps users of previous versions to catch up and saves new users from filtering the cruft. > However, I think you're way off the 'original question' > which, again, was about provisioning. Hm, yes, I didn't understand at first that this a different question, sorry. -- Knowledge is volatile and fluid. Software is power.