so i converted a .vmdk to raw and imported it with the lxd import tool but the VM doesnt boot,sometimes it just loads for a bit and then crashes and other times it drops into the windows “recovery” menu.
name: win2019server
description: ''
status: Error
status_code: 112
created_at: '2024-10-22T16:49:26.503761535Z'
last_used_at: '2024-10-23T07:53:41.59798878Z'
location: none
type: virtual-machine
project: default
architecture: x86_64
ephemeral: false
stateful: false
profiles:
- default
config:
limits.cpu: 32-32
limits.memory: 36GiB
security.csm: 'false'
security.secureboot: 'true'
volatile.cloud-init.instance-id: 1fd7afa3-b9ef-42d1-9d42-8f36b3ca000a
volatile.eth0.host_name: tap7354f1e1
volatile.eth0.hwaddr: 00:16:3e:99:3c:eb
volatile.last_state.power: RUNNING
volatile.last_state.ready: 'false'
volatile.uuid: f74f20fc-9e24-47e0-9ea1-1bce7627c5a3
volatile.uuid.generation: f74f20fc-9e24-47e0-9ea1-1bce7627c5a3
volatile.vsock_id: '2236193216'
devices:
root:
path: /
pool: defaultpool
size: 250GiB
type: disk
i already experimented with secureboot and csm but no luck so far.
i think its the same issue as here
opened 08:14PM - 16 Aug 23 UTC
closed 12:12PM - 31 Aug 23 UTC
Incomplete
# Required information
* Distribution: Ubuntu
* Distribution version: 22.0… 4
* The output of "lxc info" or if that fails:
* Kernel version: 5.15.0-78-generic
* LXC version: 5.15
* LXD version: 5.15
* Storage backend in use: dir
# Issue description
Windows VM images migrated from another hypervisor or custom built do not boot when imported into LXD. The VM either crashes (Windows spinning circles runs for a bit then freezes) or it boots into recovery mode and does not recognize any other partitions on the disk. It seems like this is an issue with the Microsoft EFI bootloader and the partition UUIDs generated by LXD, as detailed in this distrobuilder issue: [#302](https://github.com/lxc/distrobuilder/issues/302). This issue claims to be fixed, but only in cases where one is installing Windows fresh from an ISO. The fix did not cover importing existing Windows images.
# Steps to reproduce
1. Export Windows image from another hypervisor (e.g. VMWare).
2. Convert image to QCOW2 if not already (e.g. with virt-v2v or qemu-img):
```
sudo virt-v2v -i vmx ./your.vmx -o local -of qcow2 -os ./some_directory/
## OR
sudo qemu-img -p -f vmdk -O qcow2 windows.vmdk windows.qcow2
```
3. Tarball a simple metadata file:
```
$ cat metadata.yaml
architecture: x86_64
creation_date: 1692073864
properties:
description: Windows 2022
os: Windows
release: 2022
$ tar -czvf metadata.tar.gz metadata.yaml
```
4. Import the disk as an image:
```
lxc image import --alias win2k22 metadata.tar.gz windows.qcow2
```
5. Launch an instance from the image:
```
lxc launch local:win2k22 windows --vm -c limits.memory=4GiB -c limits.cpu=4 --console=vga
```
# Information to attach
- The same image boots fine with `virsh` / `virt-manager`.
so missing virtio could be the cause?
ok found the virt-2v2 mention in the official documentation…
sudo virt-v2v --block-driver virtio-scsi -o local -of raw -os ./test.raw -i vmx ./test-flat.vmdk -v -x
virt-v2v: virt-v2v 2.4.0 (x86_64)
libvirt version: 10.0.0
libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
libguestfs: trace: get_backend
libguestfs: trace: get_backend = "direct"
check_host_free_space: large_tmpdir=/var/tmp free_space=794292916224
[ 0.0] Setting up the source: -i vmx ./DETUEWIN01-flat.vmdk
libguestfs: trace: close
libguestfs: closing guestfs handle 0x62fc03a31110 (state 0)
virt-v2v: error: exception: Out of memory
rm -rf -- '/tmp/vmx.HlNavn'
rm -rf -- '/tmp/v2v.nbhtza'
so its basically eating 1gb of ram per second until it crashes and i have 48gb on this machine… is that normal? should i just set a ginormous swap file?
i also tried to use the lxd migration tool
lxd-migrate --conversion=format,virtio
but i cant run that i need to run
./bin.linux.lxd-migrate.x86_64 --conversion=format,virtio
Error: unknown flag: --conversion
and it doesnt work
ok i literally gave it 150gb of swap memory which is more than the size of the image importing but it went out of memory again
ok so for this to work i had to change the command from the documentation
virt-v2v -i disk winserver2019.vmdk --block-driver virtio-scsi -o local -os /var/tmp
doesnt eat up all the ram and the image actually boots
tomp
October 24, 2024, 1:57pm
7
Which part was the change that helped?
Could you also try to reproduce the issue with virt-v2v-in-place, which we are using in the conversion API instead of virt-v2v?