Yep, attaching raw drives is planned which will include booting off and iso.
We’ll need that for Windows and other non-distributable OSes.
1 Like
What’s an ETA for this release?
Is this behavior going to change? because I make heavy use of vendor-data for phone_home, I know LXD doesn’t have a merge strategy for *-data because its pretty difficult, but I guess its just as difficult for everybody to solve
Is there a plan to expose some sort “window forwarding” (for the likes of windows server or full desktop environments) ? Thinking out load I assume you have to attach some sort of virtual monitor, keyboard & mouse and forward all the inputs from the user, im wondering if this going to be written by the LXD team or by other developers?
Unknown yet. The VM bits mostly work but we need to finish porting all the storage drivers over to the new mechanism before we can tag a release.
My guess is that we’re probably looking at early to mid December at this point.
The images currently available do not have a password set, so you must use cloud-init to configure one. We don’t expect this to change as it’s how cloud instances behave in general.
What will change eventually is that we’ll get the agent started automatically which would then allow you to use lxc exec similar to containers and not necessarily need to set a password. Our own images (images:xyz) will all have the agent units in place to do that and we will be pushing the same through Ubuntu, but if using something else, you’ll be on your own.
As for GUI access, right now, it’s not something we’re doing. We will most likely introduce a raw.qemu which will allow you to pass additional configuration, including the VNC address. That should work as a stopgap measure for those who absolutely need graphical access (such as installing Windows).
The long term plan is to setup a virtio graphics card and connect it to a spice channel, forwarding that spice channel over websocket through our normal console API. Spice clients are reasonably widely available and could then attach to the VM’s graphical console, keyboard, mouse and possibly even USB.
1 Like
How about doing 3.18.1 release? I know for a fact that there is a lot of fixes between 3.18 release and current master.
That’s pretty unlikely. We have been cherry-picking fixes into the snap and are certainly open to cherry-picking more cleanly applicable changes on top of that, but making a 3.18.1 would require a few days of work which we’d rather put in making 3.19 happen faster.
Do I understand right, these VM images run each with it’s own kernel? The advantage I have over other solutions is that I can operate VM’s and Containers under the same management interface and API?
1 Like
Correct, same storage, network, config, … can be clustered, …
1 Like
I have a question.
I tested the ubuntu virtual-machine creation and confirmed that it worked.
Can centos be created as a virtual-machine?
Hi!
There is no virtual machine image yet for other distros. At some point they will be made available. A developer can give you an estimate about when they will be available.
To view the Centos images, run
lxc image list images:Centos
You need to see images of type VIRTUAL-MACHINE.
Hi Simos
Thank you very much your reply. ^^
Hey simos
Im following your tutorial, for setting up VM’s but I keep getting a i386 image ? is that the same image you get ?
I get this on both an intel & amd machine followed by
“Architecture isn’t supported for virtual machines”
@stgraber maybe ?
When i run lxc image list images: I dont see any with the type VIRTUAL-MACHINE
Only ubuntu: and ubuntu-daily: have VM images currently.
We’re actively working on adding VM building support to distrobuilder at which point we’ll start to quickly rollout VM images for all of images:.
You have to remember that VMs are a bit harder to build than containers as we need to put the right kernel and bootloader in place as well as handling things like partitioning. This isn’t quite as generic across distro as a container filesystem is and so requires quite a bit of care to get to a good solution.
1 Like
Hey
Thanks alot,
For anyone who wants a complete profile, here is one including auto setting up the lxd-agent’s
stolen from @simos I added the runcmd
config:
user.user-data: |
#cloud-config
ssh_pwauth: yes
users:
- name: ubuntu
passwd: "$6$iBF0eT1/6UPE2u$V66Rk2BMkR09pHTzW2F.4GHYp3Mb8eu81Sy9srZf5sVzHRNpHP99JhdXEVeN0nvjxXVmoA6lcVEhOOqWEd3Wm0"
lock_passwd: false
groups: lxd
shell: /bin/bash
sudo: ALL=(ALL) NOPASSWD:ALL
runcmd:
- mount -t 9p config /mnt/
- cd /mnt && ./install.sh
- reboot
description: ""
devices:
config:
source: cloud-init:config
type: disk
name: vm
1 Like
Note that we are working on having the systemd unit files for the agent pre-built into most of our images in the near future, so that step should become a thing of the past soon enough 
Awesome 
(please announce it)
Hi!
I get a matching image with the host, i.e. both are x86_64.
If you get x86 while your host is x86_64, then it should be a bug (which I cannot replicate here).
I suppose the semantics are to follow by default the architecture of the host, unless you explicitly specify otherwise (as it, for example, ubuntu:18.04/i386).
I have tried though to launch a i386 virtual machine, and I might hit a feature.
Specifically,
$ lxc image list ubuntu:bionic/i386
+---------------+--------------+--------+--------------------------------------------+--------------+-----------------+----------+------------------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
+---------------+--------------+--------+--------------------------------------------+--------------+-----------------+----------+------------------------------+
| i386 (5 more) | 6b11d9656e44 | yes | ubuntu 18.04 LTS i386 (release) (20200107) | i686 | CONTAINER | 180.09MB | Jan 7, 2020 at 12:00am (UTC) |
+---------------+--------------+--------+--------------------------------------------+--------------+-----------------+----------+------------------------------+
| i386 (5 more) | ffb876ca48fb | yes | ubuntu 18.04 LTS i386 (release) (20200107) | i686 | VIRTUAL-MACHINE | 318.13MB | Jan 7, 2020 at 12:00am (UTC) |
+---------------+--------------+--------+--------------------------------------------+--------------+-----------------+----------+------------------------------+
Ok, the name ubuntu:bionic/i386 is not a single image, but it the name for both the container image and the VM image.
Which means that the image cannot be found, while in fact I assume that lxc image info expects to result in a single image, not two of them.
$ lxc image info ubuntu:bionic/i386
Error: The requested image couldn't be found
lxc image info as a --vm option though. Still, it does not filter the two results into a single result.
$ lxc image info --vm ubuntu:bionic/i386
Error: The requested image couldn't be found
I got the profile from @stgraber’s announcement. :-).
Its an error in your tutorial unfortunetly 
its where you put ubuntu:18.04 that causes the issue