XCP-ng LiveCD Available?
-
@LonnieTC Cool idea! Would be also helpfull for quick hardware compatibility checks.
But as you already said, there is no (known) effort yet. This also may bring us closer to XCP-ng completely in RAM. See also here: https://github.com/xcp-ng/xcp/wiki/FAQ#can-i-use-xcp-ng-on-a-usb-stick-like-esxi
-
@borzel Thanks for the response and link regarding running XCP-ng on USB. I am going to dig a lot deeper into this idea and see what might be able to be done since it could bring some value to the XCP-ng project as well as to get other interested in trying it before installing it along with hardware compatibility checks like you mention too.
On another message thread, I am trying to get a feel for how to build the complete distro from the ground up towards this whole approach and sent this message to see if there was anything previously done, but looks like it has not.
If you are interested in helping then perhaps we can stay in touch on it.
-
@LonnieTC said in XCP-ng LiveCD Available?:
I am trying to get a feel for how to build the complete distro from the ground up towards this whole approach
@stormi is the release manager and
masterguru of the build system, he may has some pointers -
@borzel said in XCP-ng LiveCD Available?:
@LonnieTC said in XCP-ng LiveCD Available?:
I am trying to get a feel for how to build the complete distro from the ground up towards this whole approach
@stormi is the release manager and
masterguru of the build system, he may has some pointersI'd start with https://github.com/xcp-ng/xcp/wiki/Development-process-tour
-
Thanks again @stormi, and I am reading over everything now since I think that it would be very useful to have an XCP-ng LiveCD that can be booted complete in RAM for hardware comparability checks and new user testing. It could be a challenge to make happen, but I think well worth the effort and I am looking into seeing how this might be accomplished.
-
Hello All,
Just an update on this.
I have found a lot of great information and may have a good way to make a type of RAM-Based XCP-ng that can be loaded from and ISO, USB, or local partition.
There are actually a number of options for making this work to include using ramdisk (ramfs) or tmpfs along with squashfs, perhaps.
Still researching this, but making progress none the less.
-
@LonnieTC Maybe at a later stage there should be an option to save the xapi-DB to some sort of memory device, to load it later again. I thought knoppix did something like this (also with autodetection of that saved state if you boot later again).
-
@borzel Yes, exactly what I was thinking. In the SmartOS community, they do something similar in that they can save the "live" configuration to a local drive or USB, for example and the state is saved for the next boot. The main reason that SmartOS (Solaris --> OpenSolaris --> Illumos based ) runs from RAM is that it helps with speed, plus it allows for a simple mechanism for upgrades in that the "data" and "VM's" are separated so a new version of the OS/hypervisor is just to boot it up. I think that this is a very nice approach and is something that would be useful for the LiveCD version that I am working on.
-
@LonnieTC Can I suggest the project name
XCP-ng Livefor that?
Or is
XCP-ng Hype Visorbetter
-
@borzel I think that the "XCP-ng Live" could be nice and simple as well. Let's see if it can get working well before we give it a name, though.
-
Hi All,
I am working on the XCP-ng LiveCD and wanted to ask about the topology of XCP-ng.
Would it be correct in that the XCP-ng core and kernel are within Dom0, or are they located outside and Dom0 is truly an independent VM?
Any information on the layout and functionality of XCP-ng would be helpful as I would like to get a full picture of how things are setup so that I can proceed with what I have in mind.
Thanks
-
-
@borzel Thanks for sharing the graphic. It looks very good, by the way.
If I interpret the design correctly then Dom0 if the critical section for which everything else is connected. Does this also suggest that if Dom0 is compromised by an attacker then the hypervisor could be halted or attacks to other VM's.
In this respect, and please forgive the analogy but doesn't the design of the core Xen hypervisor make it really seem like a Type-2 hypervisor with Dom0 providing the OS layer since everything seems to be controlled from Dom0?
Perhaps I have the interpretation wrong, though.
For a Type-1 hypervisor, my understanding is that if all of the VM's were to be stopped, or removed then the hypervisor itself would still be running securely.
I'm just trying to get some clarification on the topology.
Thanks -
Xen is doing all the CPU and memory sharing, so Xen is a type 1. Network and storage are delegate to the privileged domain (dom0).
