virt-install is looking for iso image, when I want to use a qcow2 image - virtual-machine

I'm absolutely new to stackoverflow, so I'm extremely sorry if my question has formatting issues.
I created a VM using virt-install:
virt-install \
--name guest \
--memory 2048 \
--vcpus 2 \
--disk size=8 \
--location /var/lib/libvirt/images/centos.iso \
--os-variant centos7.0 \
--check disk_size=off \
--graphics none \
--extra-args console=ttyS0
The above command works fine, but when I want to use a specific image which is a qcow2 image, Virt-install throws the error:
ERROR Command '['isoinfo', '-J', '-i', '/var/lib/libvirt/images/centos.qcow2', '-f']' returned non-zero exit status 1
Looks like virt-install is looking for an isofile since its running the isoinfo command to verify an iso image, eventhough I have a qcow2 image.
I might be able to pass a qcow2 using the --disk parameter instead of --location, but --extra-args only works with --location.
Kindly help me out, thank you in advance!

You seem to be mixing up two different concepts here. The --location flag is intended to provide the installation media, which will be an ISO image or a URL to a installable tree. The --disk flag would be to provide the storage to back the virtual disk of the VM being provisioned, which will typically be a qcow2 file or a raw file, or a block device.
I'm assuming the centos.iso image would be your installation media, and the centos.qcow2 image would be an empty volume for the virtual disk into which you'll install the CentOS guest.

Related

what is a no nonsense way to create a ubuntu virtual machine using virt-manager on command line

I tried various methods explained on internet, but none seems to be working. using local iso image give one issue and location gives another issue.
Can we setup IP using this command?
currently using this command
sudo virt-install \ --name worker-2 \ --ram=4096 \ --disk size=100 \ --disk path=/opt/sciserver/vm/worker-2.qcow2,size=30,format=qcow2 \ --vcpus 2 \ --os-type linux \ --os-variant ubuntu20.04 \ --graphics none \ --location 'http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/' \ --extra-args "console=tty0 console=ttyS0,115200n8"
and error says..
"ERROR Error validating install location: Could not find an installable distribution at 'http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/'
The location must be the root directory of an install tree.
See virt-install man page for various distro examples."
Your help will be much appreciated

Invalid argument --model_config_file_poll_wait_seconds

I'm trying to start tensorflow-serving with the following two options like on the documentation
docker run -t --rm -p 8501:8501 \
-v "$(pwd)/models/:/models/" tensorflow/serving \
--model_config_file=/models/models.config \
--model_config_file_poll_wait_seconds=60
The container does not start because it does not recognize the argument --model_config_file_poll_wait_seconds.
unknown argument: --model_config_file_poll_wait_seconds=60
usage: tensorflow_model_server
I'm on the latest docker image, 1.14.0 and the line is taken straight from the documentation
https://www.tensorflow.org/tfx/serving/serving_config
Does this argument even work?
Many thanks.
It seems https://www.tensorflow.org/tfx/serving/serving_config is talking about code that has not been released as a new version yet, which is odd. I will ask about that.
That package is generated from this source:
https://github.com/tensorflow/serving/blob/master/tensorflow_serving/g3doc/serving_config.md, it mentions the --model_config_file_poll_wait_seconds flag.
However, the same document for 1.14.0 has no mention of the flag:
https://github.com/tensorflow/serving/blob/1.14.0/tensorflow_serving/g3doc/serving_config.md
Try using the nightly tensorflow serving image and see if it works.
docker run -t --rm -p 8501:8501 \
-v "$(pwd)/models/:/models/" tensorflow/serving:nightly \
--model_config_file=/models/models.config \
--model_config_file_poll_wait_seconds=60
Just tried. Tensorflow Serving 2.1.0 supports it while 1.14.0 doesn't.

'tflite_convert' is not recognized as an internal or external command (in windows)

im trying to convert my saved_model.pb(from object detection API) file to .tflite for mlkit but when i execute the command on cmd:
tflite_convert \
--output_file=/saved_model/maonani.tflite \
--saved_model_dir=/saved_model/saved_model
i get a response saying
C:\Users\LENOVO-PC\tensorflow> tflite_convert \ --output_file=/saved_model/maonani.tflite \ --saved_model_dir=/saved_model/saved_model
'tflite_convert' is not recognized as an internal or external command,
operable program or batch file.
what should i do to make this work?
Below is answer for Linux system, hope it gives you ideas for Windows.
locate tflite_convert
if output is
/tflite_convert
where TFLITE_CONVERT_PATH depends on your TF installation, execute (2)
/tflite_convert \
--output_file=/saved_model/maonani.tflite \ --saved_model_dir=/saved_model/saved_model
if output is not found, reinstall tf, in my case it is tf v1.9
if (2) works, you might add PATH=$PATH:/bin in ~/.bashrc
if "locate" command not recognized, install it by
sudo apt-get install locate

drums_rnn_generate:command not found

when I tried to use magenta models——"Drums RNN" to generate my drum tracks, I got this info:
drums_rnn_generate: command not found
and here is my .sh file
BUNDLE_PATH='/root/magenta/model/drum_kit_rnn.mag'
CONFIG='drum_kit'
drums_rnn_generate \
--config=${CONFIG} \
--bundle_file=${BUNDLE_PATH} \
--output_dir=/root/magenta/drums_rnn/generated \
--num_outputs=10 \
--num_steps=128 \
--primer_drums="[(36,)]"
I have installed magenta environment successfully,and activated magenta. it's strange that I can use command melody_rnn_generate which is from "melody_rnn" without any problem.
Does someone get the same problem like mine?I want to know where the problem is and how to sovle it.Thanks anyway.

Convert qcow2 to vmdk and make it ESXi 6.0 Compatible

I am currently working on VMWare virtualization; I am trying to make a converted image from qcow2 to vmdk work with ESXi Server 6.0.
I have myImage.qcow2 with a disk which is thin provisioned for 300GB.
I used the image converter tool qemu with the following command
qemu-img convert -f qcow2 myImage.qcow2 -O vmdk myNewImage.vmdk
This command gives me a vmdk image which is only VMWare Workstation compatible. Therefore, in order to make it ESXi compatible I have to use the vmkfstools with the following command.
vmkfstools -i myImage.vmdk outputName.vmdk -d thin
The vmkfstools command gives me two files, an metadata.vmdk and the actual data.vmdk.
As mentioned above my disk is thin provisioned for 300GB and when I apply vmkfstools it expands the disk and gives me a size of 300GB.
Deploying the image through the vSphere Client works without any problem; however, for the purpose of this project I want to use the ovftool and doing so with such a large image is not feasible.
Is there a way for me to make my .vmdk ESXi compatible without vmkfstools expanding my image to 300GB?
Or Is there any other method for me to deploy those 300GB using the ovftool while the disk image is on the datastore, so that it doesn't have to be downloaded/uploaded through the deployment process?
I have been stuck on this for weeks and any help will be highly appreciated.
FYI: This support has been added in Qemu 2.1 and above as per changelogs
qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,compat6 SC-1.qcow2 SC-1.vmdk
This worked for me with VMware 6.7
The TL;DR is
qemu-img convert -f qcow2 -O vmdk -o subformat=streamOptimized source_qcow_image_path destination_path_to_vmdk
For example:
qemu-img convert -f qcow2 -O vmdk -o subformat=streamOptimized \
CentOS-7-x86_64-GenericCloud-1503.qcow2 \
CentOS-7-x86_64-GenericCloud-1503.vmdk
Update the vmdk version setting embedded in the converted image using this script:
* This is what actually worked for me *
printf '\x03' | dd conv=notrunc of=<vmdk file name> bs=1 seek=$((0x4))
For example:
printf '\x03' | dd conv=notrunc of=CentOS-7-x86_64-GenericCloud-1503.vmdk bs=1 seek=$((0x4))
source: https://kb.vmware.com/s/article/2144687