[ovirt-users] GlusterFS 4.1
All, Now that GlusterFS 4.1 LTS has been released, and is the "default" version of GlusterFS in CentOS (you get this from "centos-release-gluster" now), what's the status with regards to oVirt? How badly is oVirt 4.2.4 likely to break if one were to upgrade the gluster* packages to 4.1? Thanks, Chris -- Chris Boot bo...@boo.tc ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ECTRCG7EOZBTXQJNB4RKN6JYVHVOWV4S/
[ovirt-users] Re: Trying to update a host. (ovirt4.1)
On 19/06/18 19:25, Joop wrote: > On 19-6-2018 17:26, Jacob Green wrote: >> >> I just did not know where to look for the errors, I now see that it is >> telling me it is failing on this package "collectd" >> >> So when I go to my host and I run *yum list collectd *I see that >> collectd is available to install via EPEL repos. _/Note: I did not >> setup this cluster not sure if epel is normal./ >> >> >> >> >> So looks like my problem here has to do with the epel package being >> available and being newer? >> > There is a warning on the ovirt site about enabling epel :-) > > Disable the epel repo and just use yum install whatever > --enablerepo=epel just in case you need it. In my opinion this is bad advice, as keeping the repo disabled (but still obtaining packages from it occasionally) will mean you never automatically receive updates to packages you've installed from it. Instead, I recommend that you edit /etc/yum.repos.d/epel.repo and add the line "exclude=collectd*" under the "[epel]" heading. I've only ever seen issues with the collectd packages from EPEL and no others. If you want to be a bit stricter you can instead only "include=" the packages that you are specifically interested in. In my case that's too many packages to be practical. Cheers, Chris -- Chris Boot bo...@boo.tc ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/23QRJJP3MB3ZQYR6DEG6YQ3ZBI56FA4N/
[ovirt-users] Re: Trying to update a host. (ovirt4.1)
[re-send from my lists address] On 19/06/18 19:25, Joop wrote: > On 19-6-2018 17:26, Jacob Green wrote: >> >> I just did not know where to look for the errors, I now see that it is >> telling me it is failing on this package "collectd" >> >> So when I go to my host and I run *yum list collectd *I see that >> collectd is available to install via EPEL repos. _/Note: I did not >> setup this cluster not sure if epel is normal./ >> >> >> >> >> So looks like my problem here has to do with the epel package being >> available and being newer? >> > There is a warning on the ovirt site about enabling epel :-) > > Disable the epel repo and just use yum install whatever > --enablerepo=epel just in case you need it. In my opinion this is bad advice, as keeping the repo disabled (but still obtaining packages from it occasionally) will mean you never automatically receive updates to packages you've installed from it. Instead, I recommend that you edit /etc/yum.repos.d/epel.repo and add the line "exclude=collectd*" under the "[epel]" heading. I've only ever seen issues with the collectd packages from EPEL and no others. If you want to be a bit stricter you can instead only "include=" the packages that you are specifically interested in. In my case that's too many packages to be practical. Cheers, Chris -- Chris Boot bo...@boo.tc ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/6TVOQ3PRPOLICDMF7644GHXDBHIWUBHD/
Re: [ovirt-users] Change management network
On 2018-02-28 11:58, Petr Horacek wrote: > What I seem to be stuck on is changing the cluster on the HostedEngine. > I actually have it running on a host in the new cluster, but it still > appears in the old cluster on the web interface with no way to > change this. > > Martin, is such thing possible in HostedEngine? In the end I enabled global maintenance mode, stopped hosted-engine on my HE VM, then changed the cluster and CPU profile (I think?) from within the database, and started it back up again. That then permitted me to remove the old cluster using the UI. I did several tests stopping and starting the engine and the VM comes up fine, so I believe that was enough to make the change, it's just rather nasty. HTH, Chris -- Chris Boot bo...@boo.tc ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Change management network
On 22/02/18 17:15, Chris Boot wrote: > Hi all, > > I have an oVirt cluster on which I need to change which VLAN is the > management network. > > The new management network is an existing VM network. I've configured IP > addresses for all the hosts on this network, and I've even moved the > HostedEngine VM onto this network. So far so good. > > What I cannot seem to be able to do is actually change the "management > network" toggle in the cluster to this network: the oVirt Engine > complains saying: > > "Error while executing action: Cannot edit Network. Changing management > network in a non-empty cluster is not allowed." > > How can I get around this? I clearly cannot empty the cluster, as the > cluster contains all my existing VMs, hosts and HostedEngine. It seems I have to create a new cluster, migrate a host over, migrate a few VMs, and so on until everything is moved over. This really isn't ideal as the VMs have to be shut down and reconfigured, but doable. What I seem to be stuck on is changing the cluster on the HostedEngine. I actually have it running on a host in the new cluster, but it still appears in the old cluster on the web interface with no way to change this. Any hints, please? This is on oVirt 4.1.9. Upgrading to 4.2.1 is not out of the question if it's likely to help. Thanks, Chris -- Chris Boot bo...@boo.tc ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Change management network
Hi all, I have an oVirt cluster on which I need to change which VLAN is the management network. The new management network is an existing VM network. I've configured IP addresses for all the hosts on this network, and I've even moved the HostedEngine VM onto this network. So far so good. What I cannot seem to be able to do is actually change the "management network" toggle in the cluster to this network: the oVirt Engine complains saying: "Error while executing action: Cannot edit Network. Changing management network in a non-empty cluster is not allowed." How can I get around this? I clearly cannot empty the cluster, as the cluster contains all my existing VMs, hosts and HostedEngine. Best regards, Chris -- Chris Boot bo...@boo.tc ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] VM is down with error: Bad volume specification
Hi folks,
Sorry it's taken me a while to get back to this! I've just updated to
4.2.1 and am still seeing the issue. I've collected the vdsm.log and
supervdsm.log from my SPM host after trying to start my broken VM: they
are available from:
https://www.dropbox.com/sh/z3i3guveutusdv9/AABDN6ubTQN6JhNOrVZhrA1Qa?dl=0
Thanks,
Chris
On 23/01/18 11:55, Chris Boot wrote:
> Hi all,
>
> I'm running oVirt 4.2.0 and have been using oVirtBackup with it. So far
> it has been working fine, until this morning. Once of my VMs seems to
> have had a snapshot created that I can't delete.
>
> I noticed when the VM failed to migrate to my other hosts, so I just
> shut it down to allow the host to go into maintenance. Now I can't start
> the VM with the snapshot nor can I delete the snapshot.
>
> Please let me know what further information you need to help me diagnose
> the issue and recover the VM.
>
> Best regards,
> Chris
>
> Forwarded Message
> Subject: alertMessage (ovirt.boo.tc), [VM morse is down with error. Exit
> message: Bad volume specification {'address': {'bus': '0', 'controller':
> '0', 'type': 'drive', 'target': '0', 'unit': '0'}, 'serial':
> 'ec083085-52c1-4da5-88cf-4af02e42a212', 'index': 0, 'iface': 'scsi',
> 'apparentsize': '12386304', 'cache': 'none', 'imageID':
> 'ec083085-52c1-4da5-88cf-4af02e42a212', 'truesize': '12386304', 'type':
> 'file', 'domainID': '23372fb9-51a5-409f-ae21-2521012a83fd', 'reqsize':
> '0', 'format': 'cow', 'poolID': '0001-0001-0001-0001-0311',
> 'device': 'disk', 'path':
> '/rhev/data-center/0001-0001-0001-0001-0311/23372fb9-51a5-409f-ae21-2521012a83fd/images/ec083085-52c1-4da5-88cf-4af02e42a212/aa10d05b-f2f0-483e-ab43-7c03a86cd6ab',
> 'propagateErrors': 'off', 'name': 'sda', 'bootOrder': '1', 'volumeID':
> 'aa10d05b-f2f0-483e-ab43-7c03a86cd6ab', 'diskType': 'file',
> 'specParams': {}, 'discard': True}.]
> Date: Tue, 23 Jan 2018 11:32:21 + (GMT)
> From: eng...@ovirt.boo.tc
> To: bo...@bootc.net
>
> Time:2018-01-23 11:30:39.677
> Message:VM morse is down with error. Exit message: Bad volume
> specification {'address': {'bus': '0', 'controller': '0', 'type':
> 'drive', 'target': '0', 'unit': '0'}, 'serial':
> 'ec083085-52c1-4da5-88cf-4af02e42a212', 'index': 0, 'iface': 'scsi',
> 'apparentsize': '12386304', 'cache': 'none', 'imageID':
> 'ec083085-52c1-4da5-88cf-4af02e42a212', 'truesize': '12386304', 'type':
> 'file', 'domainID': '23372fb9-51a5-409f-ae21-2521012a83fd', 'reqsize':
> '0', 'format': 'cow', 'poolID': '0001-0001-0001-0001-0311',
> 'device': 'disk', 'path':
> '/rhev/data-center/0001-0001-0001-0001-0311/23372fb9-51a5-409f-ae21-2521012a83fd/images/ec083085-52c1-4da5-88cf-4af02e42a212/aa10d05b-f2f0-483e-ab43-7c03a86cd6ab',
> 'propagateErrors': 'off', 'name': 'sda', 'bootOrder': '1', 'volumeID':
> 'aa10d05b-f2f0-483e-ab43-7c03a86cd6ab', 'diskType': 'file',
> 'specParams': {}, 'discard': True}.
> Severity:ERROR
> VM Name: morse
> Host Name: ovirt2.boo.tc
> Template Name: Blank
>
--
Chris Boot
bo...@boo.tc
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] VM is down with error: Bad volume specification
Hi all,
I'm running oVirt 4.2.0 and have been using oVirtBackup with it. So far
it has been working fine, until this morning. Once of my VMs seems to
have had a snapshot created that I can't delete.
I noticed when the VM failed to migrate to my other hosts, so I just
shut it down to allow the host to go into maintenance. Now I can't start
the VM with the snapshot nor can I delete the snapshot.
Please let me know what further information you need to help me diagnose
the issue and recover the VM.
Best regards,
Chris
Forwarded Message
Subject: alertMessage (ovirt.boo.tc), [VM morse is down with error. Exit
message: Bad volume specification {'address': {'bus': '0', 'controller':
'0', 'type': 'drive', 'target': '0', 'unit': '0'}, 'serial':
'ec083085-52c1-4da5-88cf-4af02e42a212', 'index': 0, 'iface': 'scsi',
'apparentsize': '12386304', 'cache': 'none', 'imageID':
'ec083085-52c1-4da5-88cf-4af02e42a212', 'truesize': '12386304', 'type':
'file', 'domainID': '23372fb9-51a5-409f-ae21-2521012a83fd', 'reqsize':
'0', 'format': 'cow', 'poolID': '0001-0001-0001-0001-0311',
'device': 'disk', 'path':
'/rhev/data-center/0001-0001-0001-0001-0311/23372fb9-51a5-409f-ae21-2521012a83fd/images/ec083085-52c1-4da5-88cf-4af02e42a212/aa10d05b-f2f0-483e-ab43-7c03a86cd6ab',
'propagateErrors': 'off', 'name': 'sda', 'bootOrder': '1', 'volumeID':
'aa10d05b-f2f0-483e-ab43-7c03a86cd6ab', 'diskType': 'file',
'specParams': {}, 'discard': True}.]
Date: Tue, 23 Jan 2018 11:32:21 + (GMT)
From: eng...@ovirt.boo.tc
To: bo...@bootc.net
Time:2018-01-23 11:30:39.677
Message:VM morse is down with error. Exit message: Bad volume
specification {'address': {'bus': '0', 'controller': '0', 'type':
'drive', 'target': '0', 'unit': '0'}, 'serial':
'ec083085-52c1-4da5-88cf-4af02e42a212', 'index': 0, 'iface': 'scsi',
'apparentsize': '12386304', 'cache': 'none', 'imageID':
'ec083085-52c1-4da5-88cf-4af02e42a212', 'truesize': '12386304', 'type':
'file', 'domainID': '23372fb9-51a5-409f-ae21-2521012a83fd', 'reqsize':
'0', 'format': 'cow', 'poolID': '0001-0001-0001-0001-0311',
'device': 'disk', 'path':
'/rhev/data-center/0001-0001-0001-0001-0311/23372fb9-51a5-409f-ae21-2521012a83fd/images/ec083085-52c1-4da5-88cf-4af02e42a212/aa10d05b-f2f0-483e-ab43-7c03a86cd6ab',
'propagateErrors': 'off', 'name': 'sda', 'bootOrder': '1', 'volumeID':
'aa10d05b-f2f0-483e-ab43-7c03a86cd6ab', 'diskType': 'file',
'specParams': {}, 'discard': True}.
Severity:ERROR
VM Name: morse
Host Name: ovirt2.boo.tc
Template Name: Blank
--
Chris Boot
bo...@boo.tc
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] [ANN] oVirt 4.1.5 General Availability Release is now available
On 22/08/17 15:45, Lev Veyde wrote: > Starting 4.1.5 oVirt supports libgfapi [5]. Using libgfapi provides a > real performance boost for ovirt when using GlusterFS . > Due to a known issue [6], using this will break live storage > migration. This is expected to be fixed soon. If you do not use live > storage migration you can give it a try. Use [7] for more details on > how to enable it. Hi all, I've tried to enable this, but can't get it working. Has anyone managed to do this and have pointers? The instructions on the linked page seem to be a mixture of truly ancient (from 2013) and modern, and it's difficult to figure out what one actually needs to do. I've set "option rpc-auth-allow-insecure on" in my glusterd.vol and "server.allow-insecure" on the relevant volume, then restarted all my Gluster daemons. I did a rolling restart as I can't currently shut everything down and bring it all back up, but I can use 'qemu-img info gluster:///[...]' successfully. I've enabled LibgfApiSupported and restarted the engine. Starting VMs now fails: it tries to start the VM on each host and fails with the same message from libvirt: libvirtd[2822]: failed to initialize gluster connection (src=0x7f748801ff50 priv=0x7f74880367b0): Success Unfortunately I can't see anything of much use in vdsm.log, /var/log/messages, or the Gluster logs. I'm using oVirt 4.1.5 and GlusterFS 3.10.5 on CentOS 7.3. Thanks, Chris -- Chris Boot bo...@bootc.net ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] [Gluster-users] Very poor GlusterFS performance
On 21/06/17 11:18, Chris Boot wrote: > Thanks for your input. I have yet to run any benchmarks, but I'll do > that once I have a bit more time to work on this. Is there a particular benchmark test that I should run to gather some stats for this? Would certain tests be more useful than others? Thanks, Chris -- Chris Boot bo...@bootc.net ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] when creating VMs, I don't want hosted_storage to be an option
On 19/06/17 15:30, Mike Farnam wrote: > Hi All - Is that a way to mark hosted_storage somehow so that it’s not > available to add new VMs to? Right now it’s the default storage domain when > adding a VM. At the least, I’d like to make another storage domain the > default. > Is there a way to do this? This would be a nice thing to have. AIUI, however, the oVirt folks are working towards not needing a dedicated storage domain for the hosted engine, which may alleviate this particular gripe. That being said, it would otherwise be nice to mark a storage domain as not usable for new volumes (a bit like the allocatable option for LVM physical volumes). Cheers, Chris -- Chris Boot bo...@bootc.net ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] [Gluster-users] Very poor GlusterFS performance
[replying to lists this time] On 20/06/17 11:23, Krutika Dhananjay wrote: > Couple of things: > > 1. Like Darrell suggested, you should enable stat-prefetch and increase > client and server event threads to 4. > # gluster volume set performance.stat-prefetch on > # gluster volume set client.event-threads 4 > # gluster volume set server.event-threads 4 > > 2. Also glusterfs-3.10.1 and above has a shard performance bug fix - > https://review.gluster.org/#/c/16966/ > > With these two changes, we saw great improvement in performance in our > internal testing. Hi Krutika, Thanks for your input. I have yet to run any benchmarks, but I'll do that once I have a bit more time to work on this. I've tweaked the options as you suggest, but that doesn't seem to have made an appreciable difference. I admit that without benchmarks it's a bit like sticking your finger in the air, though. Do I need to restart my bricks and/or remount the volumes for these to take effect? I'm actually running GlusterFS 3.10.2-1. This is all coming from the CentOS Storage SIG's centos-release-gluster310 repository. Thanks again. Chris -- Chris Boot bo...@bootc.net ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Very poor GlusterFS performance
Hi folks, I have 3x servers in a "hyper-converged" oVirt 4.1.2 + GlusterFS 3.10 configuration. My VMs run off a replica 3 arbiter 1 volume comprised of 6 bricks, which themselves live on two SSDs in each of the servers (one brick per SSD). The bricks are XFS on LVM thin volumes straight onto the SSDs. Connectivity is 10G Ethernet. Performance within the VMs is pretty terrible. I experience very low throughput and random IO is really bad: it feels like a latency issue. On my oVirt nodes the SSDs are not generally very busy. The 10G network seems to run without errors (iperf3 gives bandwidth measurements of >= 9.20 Gbits/sec between the three servers). To put this into perspective: I was getting better behaviour from NFS4 on a gigabit connection than I am with GlusterFS on 10G: that doesn't feel right at all. My volume configuration looks like this: Volume Name: vmssd Type: Distributed-Replicate Volume ID: d5a5ddd1-a140-4e0d-b514-701cfe464853 Status: Started Snapshot Count: 0 Number of Bricks: 2 x (2 + 1) = 6 Transport-type: tcp Bricks: Brick1: ovirt3:/gluster/ssd0_vmssd/brick Brick2: ovirt1:/gluster/ssd0_vmssd/brick Brick3: ovirt2:/gluster/ssd0_vmssd/brick (arbiter) Brick4: ovirt3:/gluster/ssd1_vmssd/brick Brick5: ovirt1:/gluster/ssd1_vmssd/brick Brick6: ovirt2:/gluster/ssd1_vmssd/brick (arbiter) Options Reconfigured: nfs.disable: on transport.address-family: inet6 performance.quick-read: off performance.read-ahead: off performance.io-cache: off performance.stat-prefetch: off performance.low-prio-threads: 32 network.remote-dio: off cluster.eager-lock: enable cluster.quorum-type: auto cluster.server-quorum-type: server cluster.data-self-heal-algorithm: full cluster.locking-scheme: granular cluster.shd-max-threads: 8 cluster.shd-wait-qlength: 1 features.shard: on user.cifs: off storage.owner-uid: 36 storage.owner-gid: 36 features.shard-block-size: 128MB performance.strict-o-direct: on network.ping-timeout: 30 cluster.granular-entry-heal: enable I would really appreciate some guidance on this to try to improve things because at this rate I will need to reconsider using GlusterFS altogether. Cheers, Chris -- Chris Boot bo...@bootc.net ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Power failure recovery
Hi Anton, Thanks for the suggestions; our engine has the same default values as you posted. However it seems our engine tried to start each VM exactly 3 times: once on each host in the cluster, all within about 15 seconds, and never tried again. The engine logs don't appear to shed any useful light on this in my opinion, but I could send them to you (offlist?) if that's any use. Best regards, Chris On 07/06/17 14:56, Artyom Lukianov wrote: > Under the engine-config, I can see two variables that connected to the > restart of HA VM's > MaxNumOfTriesToRunFailedAutoStartVm: "Number of attempts to restart > highlyavailable VM that went down unexpectedly" (Value Type: Integer) > RetryToRunAutoStartVmIntervalInSeconds: "How often to try to restart > highly available VM that went down unexpectedly (in seconds)" (Value > Type: Integer) > And their default parameters are: > # engine-config -g MaxNumOfTriesToRunFailedAutoStartVm > MaxNumOfTriesToRunFailedAutoStartVm: 10 version: general > # engine-config -g RetryToRunAutoStartVmIntervalInSeconds > RetryToRunAutoStartVmIntervalInSeconds: 30 version: general > > So check theengine.logif you do not see that the engine restarts the HA > VM's ten times, it is definitely a bug otherwise, you can just to play > with this parameters to adapt it to your case. > Best Regards > > On Wed, Jun 7, 2017 at 12:52 PM, Chris Boot <bo...@bootc.net > <mailto:bo...@bootc.net>> wrote: > > Hi all, > > We've got a three-node "hyper-converged" oVirt 4.1.2 + GlusterFS cluster > on brand new hardware. It's not quite in production yet but, as these > things always go, we already have some important VMs on it. > > Last night the servers (which aren't yet on UPS) suffered a brief power > failure. They all booted up cleanly and the hosted engine started up ~10 > minutes afterwards (presumably once the engine GlusterFS volume was > sufficiently healed and the HA stack realised). So far so good. > > As soon at the HostedEngine started up it tried to start all our Highly > Available VMs. Unfortunately our master storage domain was as yet > inactive as GlusterFS was presumably still trying to get it healed. > About 10 minutes later the master domain was activated and > "reconstructed" and an SPM was selected, but oVirt had tried and failed > to start all the HA VMs already and didn't bother trying again. > > All the VMs started just fine this morning when we realised what > happened and logged-in to oVirt to start them. > > Is this known and/or expected behaviour? Can we do anything to delay > starting HA VMs until the storage domains are there? Can we get oVirt to > keep trying to start HA VMs when they fail to start? > > Is there a bug for this already or should I be raising one? > > Thanks, > Chris > > -- > Chris Boot > bo...@bootc.net <mailto:bo...@bootc.net> > _______ > Users mailing list > Users@ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > > -- Chris Boot bo...@bootc.net ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Power failure recovery
Hi all, We've got a three-node "hyper-converged" oVirt 4.1.2 + GlusterFS cluster on brand new hardware. It's not quite in production yet but, as these things always go, we already have some important VMs on it. Last night the servers (which aren't yet on UPS) suffered a brief power failure. They all booted up cleanly and the hosted engine started up ~10 minutes afterwards (presumably once the engine GlusterFS volume was sufficiently healed and the HA stack realised). So far so good. As soon at the HostedEngine started up it tried to start all our Highly Available VMs. Unfortunately our master storage domain was as yet inactive as GlusterFS was presumably still trying to get it healed. About 10 minutes later the master domain was activated and "reconstructed" and an SPM was selected, but oVirt had tried and failed to start all the HA VMs already and didn't bother trying again. All the VMs started just fine this morning when we realised what happened and logged-in to oVirt to start them. Is this known and/or expected behaviour? Can we do anything to delay starting HA VMs until the storage domains are there? Can we get oVirt to keep trying to start HA VMs when they fail to start? Is there a bug for this already or should I be raising one? Thanks, Chris -- Chris Boot bo...@bootc.net ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] VMs imported from libvirt have no cdrom device
Hi, I've imported a number of VMs that I previously was running under a self-hosted libvirt configuration. Most of the VMs at the source did not have a cdrom device (but some did) because I just added one as I needed to. Now that the VMs have been imported into oVirt, none of them have a cdrom device. Even booting with the "Attach CD" option doesn't create a cdrom device. I can't see any way to get oVirt to re-create the missing device. Is there a way for me to add these missing devices to my VMs? I'm running oVirt 4.1 on CentOS 7.3.1611 with a hosted engine setup. VMs were migrated from a Debian Stretch machine running libvirt 3.0.0 with qemu 2.8.0. Thanks, Chris -- Chris Boot bo...@bootc.net ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
