Creating a VM using only the XAPI CLI...

olivierlambert

I think it was possible because in 7.2, PV wasn't deprecated and the example provided was for a PV guest.

I don't think "install-repository" works for an HVM guest, which is now the default. But I can try to see if it's truly the code by taking a look at XAPI.

So it's possible that the simplest method isn't the one you are using

olivierlambert

Okay I had the confirmation from a XAPI dev: this parameter is only parsed by eliload, which is only used for PV guest and that will be even removed soon from XenServer/XCP-ng (see https://github.com/xapi-project/xen-api/pull/4837)

I'm not yet certain this parameter will work with Pygrub (the "non-deprecated" boot loader for PV guests) but yet, it will NOT work on HVM guests anyway.

edwintorok opened this pull request in xapi-project/xen-api

draft CP-41067: Drop eliloader bootloader: obsolete and not needed on any s… #4837

epretorious

@livierlambert Is there any way to bootstrap an HVM guest using only XAPI on the CLI?

TIA,
Eric P.
Reno, Nevada

olivierlambert

With xe only, I'm not sure, no. You'll need a better client to do that.

epretorious

@livierlambert said in Creating a VM using only the XAPI CLI...:

You'll need a better client to do that.

I don't understand. Would you please elaborate?

TIA,
Eric P.
Reno, Nevada

olivierlambert

xe is just a XAPI client. But it's relatively basic and doesn't support (for example) Cloudinit, which could be helpful to bootstrap templates with variables.

I mean, you can use xe to clone a template of a already installed CentOS, but you won't be able to change the hostname or anything beyond just cloning.

Network boot on fully automated TFTP and such can do the rest for you (after initial boot), but that's also beyond just using xe, you need something to do the rest of the work. There's many ways, but not just setting a value in the VM anymore.

epretorious

What does @jkreidl have to say about bootstrapping an HVM guest using only XAPI on the CLI?

Eric P.
Reno, Nevada

tjkreidl

@pretorious Not sure that's an option. I think you'd be better off to just clone an existing VM and use scripts to modify it to transform it into the desirable VM.

olivierlambert

It is the way it is, things changed. HVM is using emulation on boot (fake BIOS), so you can't directly talk to the VM kernel.

However, you might want to dig a bit on UEFI side, I don't know if it's possible to tinker with that (I'm not a specialist, UEFI is vast and complex).

In any case, I would sort the various approaches in 2 categories:

Fresh VM install from scratch (no previous disk): you can use a network install, Packer, a specific ISO to make the install fully automated and probably other things (not an exhaustive list)
Clone an existing template (VM with OS already installed): Cloudinit to inject the data you want (you can use XO CLI to do it), Terraform XO plugin, custom scripts like using xenstore (that's what we use for XOA deploy from the CLI) as long as your template is reading them on boot, and so on

All in all, that's why using "better" (more complete) tooling on top of XCP-ng/XenServer makes sense, like Xen Orchestra, soon XO Lite too.
Packer/Terraform is also a good combo if you want automation/infrastructure as code.

I know, it's more stuff to learn, but worth it. And finally, a side note to understand why the stack is important as a "whole": we couldn't convince VMware users to make the switch if we were only "selling" XCP-ng. What makes the difference is to get the whole thing (XCP-ng+Xen Orchestra) together

tjkreidl

@livierlambert I'd vote for Option 2. Much easier IMO to take a VM or VM template and modify it.

olivierlambert

Agreed, but the downside is to update the template from time to time. We'll probably create a new Packer plugin to work with XO API, so it will be easier to use and rely on (Packer goal is to prep' a template from scratch and up to date for you, that you can use for solution 2. then)