@michael132 First post so hopefully I don't mess up the formatting too bad.

I did the import with openTofu (AFAIK it's identical to terraform since it uses the terraform provider behind the scenes).

After import I got some fields during "plan" action that said it would need to be recreated
I followed the blogpost here:
https://xen-orchestra.com/blog/managing-existing-infrastructure-with-terraform-2/

the 2 offending fields for me was:

• template
• destroy_cloud_config_vdi_after_boot

so I added the small lifecycle part in the bottom and now "plan" is agreeing with the configured infrastructure.

I also added some math for memory and disk to make it easier to see how many GB it is easier.

resource "xenorchestra_vm" "imported" {
    template           = "template"
    auto_poweron       = true
    cpus               = 2
    exp_nested_hvm     = false
    hvm_boot_firmware  = "bios"
    memory_max         = 4*1073741824
    name_description   = "k8s-clu01-01"
    name_label         = "K8S-clu01-01"
    start_delay        = 0
    tags               = [
        "k8s-clu-01",
    ]
    cdrom {
        id = "some-cdrom-id"
    }

    disk {
        attached         = true
        name_description = "Created by XO"
        name_label       = "Debian Bookworm 12_evibo"
        size             = 50*1073741824
        sr_id            = "some-sr-id"
    }

    network {
        attached       = true
        mac_address    = "de:ad:be:ef"
        network_id     = "some-network-id"
    }
    lifecycle {
      ignore_changes = [
        template,
        destroy_cloud_config_vdi_after_boot,
      ]
    }
}

@eeldivad I think i can "help" somewhat. the "new" and probably more supported in the future way as I see it is doing stuff through xen orchestra Rest api (not everything is possible there yet however)

http://[yourXO]/rest/v0/vms

this endpoint is pretty "fire" as the kids say

as per the README of the rest-api here

you can add fields to the result, so adding "name_label" like so:

http://[yourXO]/rest/v0/vms?fields=name_label

http://[yourXO]/rest/v0/vms?fields=name_label&filter=[namelabelSearch]

we can then search this output for the VM UUID we want (if you didn't just filter the api query)
in my example i want "9a5730fa-77bc-1730-4583-c383cbc5c1f1"

I then call:

http://[yourXO]/rest/v0/vms/9a5730fa-77bc-1730-4583-c383cbc5c1f1/vdis

which again is a list of endpoints like this:

/rest/v0/vdis/cd59c164-b382-4a5c-8449-e668d31696da

the last part after "vdis" is the disk UUID, you could then call that endpoint to get the VDI size, usage etc.

Hope this was somewhat helpful

I did not see a easy way to get this from xo-cli but I figured you can probably get the UUID's from REST and then the "rest" on xo-cli

Maybe I can be of assistance, I haven't seen this issue personally on my windows vm

xo vm config

• video RAM 8MiB
• VGA on

test

today using Remmina from Linux executing this command in the VM i get:

Get-WmiObject win32_videocontroller | select caption,videomodedescription

result:

Caption                          VideoModeDescription
-------                          --------------------
Microsoft Remote Display Adapter 2508 x 1302 x 4294967296 colors
Microsoft Basic Display Adapter  1024 x 768 x 4294967296 colors

I won't say for certain but i think the virtual RDP screen is the first one and the "VGA" console is the second one.

How are you checking your resolution inside windows RDP?

@eeldivad Cool that you can call the rest api's through there!

I mess about in the web browser, seems to use the cookie that XO web ui uses (ie. logging in to web ui also makes you able to call api in web browser)

my bad for not including a example, namelabel was supposed to hint at displayname of VM

http://[yourXO]/rest/v0/vms?fields=name_label&filter=app

this returns all vm's with "app" in their name_label (displayname)

according to this documentation
filter should be compatible with the search bar in XO, so you can make your query there by selecting pools etc. in GUI and it just seems to work (tested just now )

http://[yourXO]/rest/v0/vms?fields=name_label&filter=power_state:running+tags:/^ansiblegrp_linuxbaseline$/

I created the above query in GUI and just tested "+" between and it seems to work. This returns running vms that are also tagged with "ansiblegrp_linuxbaseline" which i use for my ansible inventory (xen orchestra has a pretty nifty inventory plugin)

@eeldivad I think i can "help" somewhat. the "new" and probably more supported in the future way as I see it is doing stuff through xen orchestra Rest api (not everything is possible there yet however)

http://[yourXO]/rest/v0/vms

this endpoint is pretty "fire" as the kids say

as per the README of the rest-api here

you can add fields to the result, so adding "name_label" like so:

http://[yourXO]/rest/v0/vms?fields=name_label

http://[yourXO]/rest/v0/vms?fields=name_label&filter=[namelabelSearch]

we can then search this output for the VM UUID we want (if you didn't just filter the api query)
in my example i want "9a5730fa-77bc-1730-4583-c383cbc5c1f1"

I then call:

http://[yourXO]/rest/v0/vms/9a5730fa-77bc-1730-4583-c383cbc5c1f1/vdis

which again is a list of endpoints like this:

/rest/v0/vdis/cd59c164-b382-4a5c-8449-e668d31696da

the last part after "vdis" is the disk UUID, you could then call that endpoint to get the VDI size, usage etc.

Hope this was somewhat helpful

I did not see a easy way to get this from xo-cli but I figured you can probably get the UUID's from REST and then the "rest" on xo-cli

@Studmuffn1134 should be available in XO vm, it was atleast for me, I just used the XO installer script from github.

I did a quick search with xo cli now

xo-cli list-commands | egrep 'host.'

in case it looks weird "\." is just to escape the "." which just tells regex I am looking for an actual "."

import aiohttp
import asyncio

from jsonrpc_websocket import Server

async def routine():
    async with aiohttp.ClientSession() as client:
        server = Server('ws://[yourXO]/api/', client)

        await server.ws_connect()

        # signIn required
        result = await server.session.signIn(username='[yourXOusername]', password='[yourXOPassword]') # email attribute is working in place of username
        
        #hard shutdown VM
        #result = await server.vm.stop(id='3f32beeb-ab3f-a8ac-087d-fdc7ed061b58', force=(bool(1)))
        
        #clean Shutdown VM
        #result = await server.vm.stop(id='3f32beeb-ab3f-a8ac-087d-fdc7ed061b58', force=(bool(0)))

        #bypassbackup and bypassevacuate set off by default but include for wholeness of parameters
        result = await server.host.stop(id=[hostUUID],bypassBackupCheck=(bool(0)),bypassEvacuate=bool(0))
        
        print (result)

asyncio.get_event_loop().run_until_complete(routine())

I just built all examples into one, here in the end is the host.stop example also

@Studmuffn1134 Sorry, must have somehow read another reply about vm and mixed them. But pretty sure you should be able to utilise the steps I did for host shutdown

xo-cli to get relevant api endpoints, xo-cli to get parameters for said endpoint and then press play

Did some "kicking" around in python, I don't python that much so "readers beware"

How did i figure it out, the french blog from here was useful, but only showed listing methods. I was still very confused as to how to call the vm.stop and which parameters it took.

Enter xo-cli

xo-cli uses jsonrpc but is CLi only, but you can get very nice info from it just have to register and call "list-methods". should be available on your xo VM

xo-cli register http://[yourXO].example.com [yourusername]
#after registering/authenticating
xo-cli list-commands | egrep 'vm\.' --color=always

here you will get a nice list of all "methods" in jsonrpc related to vm and a line about vm.stop:

vm.stop id=<string> [force=<boolean>] [forceShutdownDelay=<number>] [bypassBlockedOperation=<boolean>]

which was enough information to alter the french guy's (Baron) example into this:

import aiohttp
import asyncio

from jsonrpc_websocket import Server

async def routine():
    async with aiohttp.ClientSession() as client:
        server = Server('ws://[yourXO]/api/', client)

        await server.ws_connect()

        # signIn required
        result = await server.session.signIn(username='[xoAdmin]', password='[xoAdmin]') # email attribute is working in place of username
        
        #hard shutdown
        #result = await server.vm.stop(id='3f32beeb-ab3f-a8ac-087d-fdc7ed061b58', force=(bool(1)))
        
        #clean Shutdown
        result = await server.vm.stop(id='3f32beeb-ab3f-a8ac-087d-fdc7ed061b58', force=(bool(0)))
        
        print (result)

asyncio.get_event_loop().run_until_complete(routine())

@michael132 First post so hopefully I don't mess up the formatting too bad.

I did the import with openTofu (AFAIK it's identical to terraform since it uses the terraform provider behind the scenes).

After import I got some fields during "plan" action that said it would need to be recreated
I followed the blogpost here:
https://xen-orchestra.com/blog/managing-existing-infrastructure-with-terraform-2/

the 2 offending fields for me was:

• template
• destroy_cloud_config_vdi_after_boot

so I added the small lifecycle part in the bottom and now "plan" is agreeing with the configured infrastructure.

I also added some math for memory and disk to make it easier to see how many GB it is easier.

resource "xenorchestra_vm" "imported" {
    template           = "template"
    auto_poweron       = true
    cpus               = 2
    exp_nested_hvm     = false
    hvm_boot_firmware  = "bios"
    memory_max         = 4*1073741824
    name_description   = "k8s-clu01-01"
    name_label         = "K8S-clu01-01"
    start_delay        = 0
    tags               = [
        "k8s-clu-01",
    ]
    cdrom {
        id = "some-cdrom-id"
    }

    disk {
        attached         = true
        name_description = "Created by XO"
        name_label       = "Debian Bookworm 12_evibo"
        size             = 50*1073741824
        sr_id            = "some-sr-id"
    }

    network {
        attached       = true
        mac_address    = "de:ad:be:ef"
        network_id     = "some-network-id"
    }
    lifecycle {
      ignore_changes = [
        template,
        destroy_cloud_config_vdi_after_boot,
      ]
    }
}