You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by GitBox <gi...@apache.org> on 2020/10/01 06:39:33 UTC
[GitHub] [cloudstack] RomeyRome206 opened a new issue #4368: Raw root volumes being identified as qcow2 & fail to start
RomeyRome206 opened a new issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368
<!--
Verify first that your issue/request is not already reported on GitHub.
Also test if the latest release and master branch are affected too.
Always add information AFTER of these HTML comments, but no need to delete the comments.
-->
##### ISSUE TYPE
<!-- Pick one below and delete the rest -->
* Other
##### COMPONENT NAME
KVM
~~~
~~~
##### CLOUDSTACK VERSION
4.14
~~~
~~~
##### CONFIGURATION
##### OS / ENVIRONMENT
18.04
##### SUMMARY
Upgraded for 4.9
Have various instances with raw root images that fail to start
Restarting these instances, CS passes the `format=qcow2` to qemu, when it should be `format=raw`.
qemu returns: `Image is not in qcow2 format`
If I manually edit the DB and change the path field to `imange-id.raw` and rename the image to match, then it starts up as expected and passes `format=raw`
None of my images currently have extensions.
Are the qemu options being generated the agent or the manager?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cloudstack] andrijapanicsb commented on issue #4368: Raw root volumes being identified as qcow2 & fail to start
Posted by GitBox <gi...@apache.org>.
andrijapanicsb commented on issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368#issuecomment-704236118
there was a lot of mess in 4.5-->4.8 when it comes to the type/extension as in the DB
CloudStack always creates QCOW2 (AFAIK) on NFS/filesystem storage, so TBH I'm not sure how you ended up with RAW images on your storage? Can you advise please?
Anyway, whatever is your format on storage, that should be reflected in the DB (volumes table) - but keep in mind that having RAW (instead of the QCOW2) might (most probably will) cause various issues working with those volumes
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cloudstack] DaanHoogland commented on issue #4368: Raw root volumes being identified as qcow2 & fail to start
Posted by GitBox <gi...@apache.org>.
DaanHoogland commented on issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368#issuecomment-704233826
@RomanGz have you had this working with older versions?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cloudstack] andrijapanicsb commented on issue #4368: Raw root volumes being identified as qcow2 & fail to start
Posted by GitBox <gi...@apache.org>.
andrijapanicsb commented on issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368#issuecomment-704534638
Once the volume is created, there is no more changes to it. The type will, however, be used in some code to determine how to do some actions (say, snapshot or similar volume-managing-actions).
My advice would be to se if you are having any issues with the current state - if not, great.
If you do have issues with RAW, then, you can test converting RAW to QCOW2 - both inside DB and the actual volume itself (qemu-img convert...) - make sure the converted volume has the same name as before - and needles to say, test on some test VMs/volumes, and ensure VMs are stopped, i.e. the volume is not in use.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cloudstack] RomanGz edited a comment on issue #4368: Raw root volumes being identified as qcow2 & fail to start
Posted by GitBox <gi...@apache.org>.
RomanGz edited a comment on issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368#issuecomment-704425635
So looks like everything created under 4.4 and earlier is raw. DB format says it's QCOW2, but as I mentioned, changing that field has no effect on actually running the instance - it still launches it with format=qcow2.
Should the volumes.format field not determine how the VM is launched?
If I can get this working with only a manager/db side fix, that would be ideal.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cloudstack] RomanGz commented on issue #4368: Raw root volumes being identified as qcow2 & fail to start
Posted by GitBox <gi...@apache.org>.
RomanGz commented on issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368#issuecomment-704597260
The first thing I tried was converting it to qcow as a test, and that of course works - But I would have to convert over 200 instances.
The only issue with RAW is that CS configures it with format=qcow2 when generating the instance config. I'm guessing it assumes KVM=qcow2. We don't care about the loss of features with raw as we don't utilize any of them.
Is the final qemu config/arguments generated on the manager, or agent side?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cloudstack] RomanGz commented on issue #4368: Raw root volumes being identified as qcow2 & fail to start
Posted by GitBox <gi...@apache.org>.
RomanGz commented on issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368#issuecomment-704378987
Yes. It worked before through versions 4.2, 4.4, 4.9.
We only use local storage pools.
I’m not entirely sure how we ended up with raw images, but I’m sure some of them have been running as far back as 4.2, or even older perhaps.
We have another 4.9 install running. I’m going to go through it to see if I can make sense of the raw situation.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cloudstack] andrijapanicsb closed issue #4368: Raw root volumes being identified as qcow2 & fail to start
Posted by GitBox <gi...@apache.org>.
andrijapanicsb closed issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cloudstack] RomanGz commented on issue #4368: Raw root volumes being identified as qcow2 & fail to start
Posted by GitBox <gi...@apache.org>.
RomanGz commented on issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368#issuecomment-704425635
So looks like everything created under 4.4 and earlier is raw. DB format says it's QCOW2, but as I mentioned, changing that field has no effect on actually running the instance - it still launches it with format=qcow2. Should the volumes.format field not determine how the VM is launched?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cloudstack] RomanGz commented on issue #4368: Raw root volumes being identified as qcow2 & fail to start
Posted by GitBox <gi...@apache.org>.
RomanGz commented on issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368#issuecomment-706092020
Mystery solved. Apparently, we had a custom build floating around that forced the build to raw format, as well as change the format in LibvirtVMDef.java to raw if the image format was raw.
Still seems like that's something CS could manage to check on its own. Not a fan of running custom builds - because of this exact situation.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cloudstack] RomanGz commented on issue #4368: Raw root volumes being identified as qcow2 & fail to start
Posted by GitBox <gi...@apache.org>.
RomanGz commented on issue #4368:
URL: https://github.com/apache/cloudstack/issues/4368#issuecomment-706092020
Mystery solved. Apparently, we had a custom build floating around that forced the build to raw format, as well as change the format in LibvirtVMDef.java to raw if the image format was raw.
Still seems like that's something CS could manage to check on its own. Not a fan of running custom builds - because of this exact situation.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org