Yeah, I'm using the CentOS 6.3 image you gave me a while back.
Is the DiskDef XML output to agent.log or should I explicitly put in a log
statement for it.
Thanks!
On Fri, Oct 25, 2013 at 11:02 PM, Marcus Sorensen <shadow...@gmail.com>wrote:
> Sounds like your disk definition is not using virtio-block. In this case
> you wouldnt be able to hot attach either though. Can you paste the diskdef
> XML? This would normally only happen if you used a template defined with an
> older OS, like the default centos 5.5 or "other Linux" instead of "other
> Linux PV". In those cases I think it emulates IDE, which can't be
> hotswapped.
> On Oct 25, 2013 10:05 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
> wrote:
>
>> Hey Marcus,
>>
>> I've been running all sorts of tests today and just noticed one issue.
>>
>> When I have a disk attached and reset (not reboot) the VM, the VM comes
>> up just fine.
>>
>> If I then try to detach the disk, I get the following error:
>>
>> com.cloud.utils.exception.CloudRuntimeException: Failed to detach volume:
>> Vol-6 from VM: VM-KVM-1; org.libvirt.LibvirtException: unsupported
>> configuration: This type of disk cannot be hot unplugged
>>
>> Normally I have no problem detaching a disk. Once I get into this state;
>> however, I seem to be stuck with an attached disk.
>>
>> Any thoughts on this?
>>
>> Thanks
>>
>>
>> On Fri, Oct 25, 2013 at 12:58 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Excellent - thanks!
>>>
>>>
>>> On Fri, Oct 25, 2013 at 12:10 AM, Marcus Sorensen
>>> <shadow...@gmail.com>wrote:
>>>
>>>> tests passed with latest commit hash you sent.
>>>>
>>>> On Thu, Oct 24, 2013 at 10:10 PM, Mike Tutkowski
>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> > Just playing around with this on XenServer now.
>>>> >
>>>> > When I stop a VM, XenCenter no longer shows the VM (i.e. it behaves
>>>> like VMM
>>>> > does when a VM is stopped).
>>>> >
>>>> >
>>>> > On Thu, Oct 24, 2013 at 9:53 PM, Marcus Sorensen <shadow...@gmail.com
>>>> >
>>>> > wrote:
>>>> >>
>>>> >>
>>>> >> On Oct 24, 2013 7:39 PM, "Mike Tutkowski" <
>>>> mike.tutkow...@solidfire.com>
>>>> >> wrote:
>>>> >> >
>>>> >> > But what happens when, say, XenServer crashes and knows about VMs
>>>> it had
>>>> >> > running before it crashed?
>>>> >>
>>>> >> Not sure what XenCenter does but I thought it would/could start them
>>>> on
>>>> >> other nodes.
>>>> >> >
>>>> >> > I guess I was thinking you meant that CS purposefully creates VMs
>>>> on KVM
>>>> >> > in such a fashion that KVM will not remember them in the event of
>>>> a crash.
>>>> >>
>>>> >> You're right about that, you get what I mean. Its done since there's
>>>> no
>>>> >> central manager and it causes problems for each host to keep a local
>>>> config.
>>>> >> I meant that CS doesn't necessarily tell the other hypervisors to
>>>> remember,
>>>> >> per se. They just do because its working through a cluster manager
>>>> and
>>>> >> that's what they do.
>>>> >>
>>>> >> >
>>>> >> >
>>>> >> > On Thu, Oct 24, 2013 at 7:25 PM, Marcus Sorensen <
>>>> shadow...@gmail.com>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> I just mean that they're still visible on those platforms because
>>>> >> >> they're being tracked by some central source outside of
>>>> cloudstack.
>>>> >> >> Cloudstack itself I don't think cares, it just manages the
>>>> resources as it
>>>> >> >> sees in ITs database. I don't really see it as cloudstack
>>>> treating KVM
>>>> >> >> differently, rather just KVM lacking a central authority or
>>>> cluster manager.
>>>> >> >>
>>>> >> >> On Oct 24, 2013 7:19 PM, "Mike Tutkowski"
>>>> >> >> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>
>>>> >> >>> So, I guess the moral is CloudStack has KVM treat VMs
>>>> ephemerally, but
>>>> >> >>> we (you and I) don't know how CS has XenServer and VMware treat
>>>> VMs.
>>>> >> >>>
>>>> >> >>> I plan to do some testing with XenServer and VMware in a bit, so
>>>> I can
>>>> >> >>> stop a VM and see if it remains visible in their GUIs.
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> On Thu, Oct 24, 2013 at 7:17 PM, Mike Tutkowski
>>>> >> >>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>
>>>> >> >>>> My guess is XenCenter gets info about stopped VMs from the
>>>> XenServer
>>>> >> >>>> hosts it logs in to. I don't think it maintains a DB like
>>>> vCenter does.
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> On Thu, Oct 24, 2013 at 7:15 PM, Mike Tutkowski
>>>> >> >>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>
>>>> >> >>>>> Actually, I don't know if XenCenter remembers the VMs per se
>>>> or if
>>>> >> >>>>> it gets that information from querying the XenServer hosts it
>>>> has access to.
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> On Thu, Oct 24, 2013 at 7:14 PM, Mike Tutkowski
>>>> >> >>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>
>>>> >> >>>>>> No, it does allow you to do that. I wasn't sure what you
>>>> meant by
>>>> >> >>>>>> your comparison, but XenCenter does remember VMs as far as I
>>>> know.
>>>> >> >>>>>>
>>>> >> >>>>>>
>>>> >> >>>>>> On Thu, Oct 24, 2013 at 7:08 PM, Marcus Sorensen
>>>> >> >>>>>> <shadow...@gmail.com> wrote:
>>>> >> >>>>>>>
>>>> >> >>>>>>> Oh, xencenter doesn't remember VMS and allow you to start
>>>> one if
>>>> >> >>>>>>> the host it was on is down? I haven't played with it in a
>>>> year but I thought
>>>> >> >>>>>>> it synced with each xen server.
>>>> >> >>>>>>>
>>>> >> >>>>>>> On Oct 24, 2013 7:06 PM, "Mike Tutkowski"
>>>> >> >>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>
>>>> >> >>>>>>>> Well...XenCenter is "just" the GUI (like VI Client is for
>>>> >> >>>>>>>> vSphere). As far as I know, XenServer has no equivalent to
>>>> vCenter Server.
>>>> >> >>>>>>>>
>>>> >> >>>>>>>>
>>>> >> >>>>>>>> On Thu, Oct 24, 2013 at 6:52 PM, Marcus Sorensen
>>>> >> >>>>>>>> <shadow...@gmail.com> wrote:
>>>> >> >>>>>>>>>
>>>> >> >>>>>>>>> That is probably true, but there is no xencenter or vsphere
>>>> >> >>>>>>>>> equivalent for KVM, no central authority. Its cloudstack.
>>>> >> >>>>>>>>>
>>>> >> >>>>>>>>> On Oct 24, 2013 6:22 PM, "Mike Tutkowski"
>>>> >> >>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>
>>>> >> >>>>>>>>>> OK, thanks for that info, Marcus...I was not aware that
>>>> >> >>>>>>>>>> CloudStack treated VMs ephemerally with KVM.
>>>> >> >>>>>>>>>>
>>>> >> >>>>>>>>>> I guess I should try to stop a VM on XenServer and ESX
>>>> and see
>>>> >> >>>>>>>>>> what happens. I was under the impression they remained
>>>> accessible using
>>>> >> >>>>>>>>>> XenCenter or VI Client, but perhaps I am wrong about that.
>>>> >> >>>>>>>>>>
>>>> >> >>>>>>>>>> Since my KVM VM's root disk was on local storage, I
>>>> expected it
>>>> >> >>>>>>>>>> to remain accessible in VMM after I had stopped it via CS.
>>>> >> >>>>>>>>>>
>>>> >> >>>>>>>>>>
>>>> >> >>>>>>>>>> On Thu, Oct 24, 2013 at 6:16 PM, Marcus Sorensen
>>>> >> >>>>>>>>>> <shadow...@gmail.com> wrote:
>>>> >> >>>>>>>>>>>
>>>> >> >>>>>>>>>>> Are you talking cloudstack VMS or your own? If a vm is
>>>> >> >>>>>>>>>>> 'created' it is ephemeral, the definition will disappear
>>>> when stopped. This
>>>> >> >>>>>>>>>>> is what cloudstack does so that a KVM host that crashes
>>>> or loses power won't
>>>> >> >>>>>>>>>>> remember and try to start VMS that were previously on it
>>>> (they are likely
>>>> >> >>>>>>>>>>> running elsewhere now). However, for your desktop and
>>>> your own VMS you
>>>> >> >>>>>>>>>>> usually 'define' VMS, which saves the XML to a file and
>>>> leaves them
>>>> >> >>>>>>>>>>> persistent. I use vmm occasionally, but usually virsh,
>>>> the CLI version. Both
>>>> >> >>>>>>>>>>> just talk to libvirt.
>>>> >> >>>>>>>>>>>
>>>> >> >>>>>>>>>>> On Oct 24, 2013 6:08 PM, "Mike Tutkowski"
>>>> >> >>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>
>>>> >> >>>>>>>>>>>> Hey Marcus,
>>>> >> >>>>>>>>>>>>
>>>> >> >>>>>>>>>>>> I assume you use Virtual Machine Manager with KVM?
>>>> >> >>>>>>>>>>>>
>>>> >> >>>>>>>>>>>> I was wondering, is there a way when you stop a VM to
>>>> have it
>>>> >> >>>>>>>>>>>> not disappear from the GUI?
>>>> >> >>>>>>>>>>>>
>>>> >> >>>>>>>>>>>> In XenCenter and VI Client, stopped VMs just show up
>>>> with a
>>>> >> >>>>>>>>>>>> different icon, but are still easy to interact with.
>>>> >> >>>>>>>>>>>>
>>>> >> >>>>>>>>>>>> Thanks!
>>>> >> >>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>
>>>> >> >>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:46 PM, Mike Tutkowski
>>>> >> >>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>> Also, the way I determined if the attach/detach worked
>>>> was
>>>> >> >>>>>>>>>>>>> to use fdisk -l and see if the device was present or
>>>> not in the hypervisor
>>>> >> >>>>>>>>>>>>> and VM instance.
>>>> >> >>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:42 PM, Mike Tutkowski
>>>> >> >>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>> Here are some of the tests I ran on this code:
>>>> >> >>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>> attach/detach/attach volume while VM is running: works
>>>> >> >>>>>>>>>>>>>> volume attached while VM is running, then reboot:
>>>> works
>>>> >> >>>>>>>>>>>>>> volume attached while VM is running, then reset: works
>>>> >> >>>>>>>>>>>>>> volume detached while VM is stopped, then start: works
>>>> >> >>>>>>>>>>>>>> volume attached while VM is stopped, then start: works
>>>> >> >>>>>>>>>>>>>> deleted VM with attached volume: works (volume goes
>>>> into
>>>> >> >>>>>>>>>>>>>> the attachable state after VM is expunged)
>>>> >> >>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:40 PM, Mike Tutkowski
>>>> >> >>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>> By the way, in case you're looking at the diff and
>>>> >> >>>>>>>>>>>>>>> wondering why I took out a StopCommand check and
>>>> call to execute in
>>>> >> >>>>>>>>>>>>>>> LibvirtComputingResource, there were two of them.
>>>> >> >>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>> - } else if (cmd instanceof StopCommand) {
>>>> >> >>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>> - return execute((StopCommand) cmd);
>>>> >> >>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:26 PM, Mike Tutkowski
>>>> >> >>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>> This is a newer link, Marcus:
>>>> >> >>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>
>>>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/e84de7577ad38fea88d1492d4949672d1989889b
>>>> >> >>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>> I just rebased on top of master today.
>>>> >> >>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 3:46 PM, Mike Tutkowski
>>>> >> >>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>> Hey Marcus,
>>>> >> >>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>> If you're interested in running the simulator
>>>> against
>>>> >> >>>>>>>>>>>>>>>>> your code + my code, I have it on GitHub here:
>>>> >> >>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>
>>>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/776f3eb9dda45745f43e6765b026d34fbc6be072
>>>> >> >>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>> Thanks!
>>>> >> >>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 11:06 PM, Mike Tutkowski
>>>> >> >>>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>> I'm trying to attach my diff to
>>>> >> >>>>>>>>>>>>>>>>>> https://reviews.apache.org/r/13865/, but I don't
>>>> see the necessary buttons.
>>>> >> >>>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>> I wonder if I need to get edit access back again?
>>>> We
>>>> >> >>>>>>>>>>>>>>>>>> had trouble with the Wiki. Was this also impacted?
>>>> >> >>>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:47 PM, Mike Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>> Sure, I can create a diff file and attach it to
>>>> Review
>>>> >> >>>>>>>>>>>>>>>>>>> Board.
>>>> >> >>>>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:40 PM, Marcus Sorensen
>>>> >> >>>>>>>>>>>>>>>>>>> <shadow...@gmail.com> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> Sure. The majority of it only affects people
>>>> who are
>>>> >> >>>>>>>>>>>>>>>>>>>> on your storage
>>>> >> >>>>>>>>>>>>>>>>>>>> anyway. Perhaps you can post a patch and I can
>>>> run it
>>>> >> >>>>>>>>>>>>>>>>>>>> through the
>>>> >> >>>>>>>>>>>>>>>>>>>> simulator to verify that the minor change to the
>>>> >> >>>>>>>>>>>>>>>>>>>> existing code hasn't
>>>> >> >>>>>>>>>>>>>>>>>>>> broken the standard storages. I don't think it
>>>> is
>>>> >> >>>>>>>>>>>>>>>>>>>> since I've
>>>> >> >>>>>>>>>>>>>>>>>>>> thoroughly tested the code I posted, but I know
>>>> there
>>>> >> >>>>>>>>>>>>>>>>>>>> were some
>>>> >> >>>>>>>>>>>>>>>>>>>> additional changes.
>>>> >> >>>>>>>>>>>>>>>>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:35 PM, Mike Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> > OK, Marcus, I made the change to detect my
>>>> volumes
>>>> >> >>>>>>>>>>>>>>>>>>>> > and it seems to work just
>>>> >> >>>>>>>>>>>>>>>>>>>> > fine.
>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> > Perhaps another day of testing and we can
>>>> check
>>>> >> >>>>>>>>>>>>>>>>>>>> > this code in. What do you
>>>> >> >>>>>>>>>>>>>>>>>>>> > think?
>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> > On Wed, Oct 23, 2013 at 9:14 PM, Mike
>>>> Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>>>> > <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >> Thanks, Marcus...I hadn't read that note,
>>>> but that
>>>> >> >>>>>>>>>>>>>>>>>>>> >> makes sense.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >> Yes, that must be the root disk for the VM.
>>>> I can
>>>> >> >>>>>>>>>>>>>>>>>>>> >> put in code, as you
>>>> >> >>>>>>>>>>>>>>>>>>>> >> recommend, to handle only my volumes.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >> On Wed, Oct 23, 2013 at 5:37 PM, Marcus
>>>> Sorensen
>>>> >> >>>>>>>>>>>>>>>>>>>> >> <shadow...@gmail.com>
>>>> >> >>>>>>>>>>>>>>>>>>>> >> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> It should be sending the path info for each
>>>> disk
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> per the XML of the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> VM... so it will send all disks regardless
>>>> of
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> whether or not your
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> adaptor manages that disk, and it's up to
>>>> your
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> adaptor to ignore any
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> that aren't managed by it. There should be
>>>> notes
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> to that effect in the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> code near the disconnectPhysicalDisk
>>>> interface in
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> StorageAdaptor:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> // given local path to file/device (per
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> Libvirt XML), 1) check
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> that device is
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> // handled by your adaptor, return
>>>> false if
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> not. 2) clean up
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> device, return true
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> public boolean
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDiskByPath(String
>>>> localPath);
>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> Since we only have XML disk definitions
>>>> when we
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> stop or migrate a VM,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> we have to try all adaptors against all
>>>> defined
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disks. So in your
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDisk you might do
>>>> something
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> like check that the path
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> starts with '/dev/disk/by-path' and contains
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> 'iscs-iqn' (maybe there's
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> some way that's more robust like checking
>>>> the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> full path against a lun
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> listing or something). If it doesn't match,
>>>> then
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> your
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDisk just does nothing.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> I assume this is a root disk or some other
>>>> local
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> storage disk. If it's
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> not, then your VM XML is messed up somehow.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> On Wed, Oct 23, 2013 at 5:01 PM, Mike
>>>> Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > I found the problem.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > disconnectPhysicalDiskByPath is being
>>>> passed in
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > (in my situation) the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > following:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> /var/lib/libvirt/images/9887d511-8dc7-4cb4-96f9-01230fe4bbb6
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > Due to the name of the method, my code was
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > expecting data such as the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > following:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> /dev/disk/by-path/ip-192.168.233.10:3260-iscsi-iqn.2012-03.com.solidfire:volume1-lun-0
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > Was it intentional to send the data into
>>>> this
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > method in the current
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > way?
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > On Wed, Oct 23, 2013 at 1:57 PM, Mike
>>>> Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> You know, I forgot we supposed to be
>>>> doing
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> that! :) Multi-tasking too
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> much
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> today, I guess.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Anyways, it must not be working because I
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> still had a hypervisor
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> connection after I shut down the VM.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Let me investigate.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> On Wed, Oct 23, 2013 at 1:48 PM, Marcus
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Sorensen <shadow...@gmail.com>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> Are we not disconnecting when we stop
>>>> the vm?
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> There's a method for
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> it, we
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> should be.
>>>> disconnectPhysicalDiskViaVmSpec
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> On Oct 23, 2013 1:28 PM, "Mike
>>>> Tutkowski"
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> <mike.tutkow...@solidfire.com>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> I see one problem for us now, Marcus.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You have a running VM that you
>>>> attach a
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> volume to.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You stop the VM.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You detach the volume.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You start up the VM.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> The VM will not be connected to the
>>>> volume
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> (which is good), but the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> hypervisor will still be connected to
>>>> the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> volume.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> It would be great if we actually sent a
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> command to the last host ID
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> of
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> the stopped VM when detaching a volume
>>>> (to
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> have the hypervisor
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> disconnect
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> from the volume).
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> What do you think about that?
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> On Wed, Oct 23, 2013 at 1:15 PM, Mike
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> <mike.tutkow...@solidfire.com> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> OK, whatever way you prefer then,
>>>> Marcus
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> (createVdb first or
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> second).
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> If I leave createVdb first and return
>>>> 0, it
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> does seem to work.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> On Wed, Oct 23, 2013 at 11:13 AM,
>>>> Marcus
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> Sorensen
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> <shadow...@gmail.com>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> I think we could flip-flop these two
>>>> lines
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> if necessary:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> createVbd(conn, vmSpec,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> vmName, vm);
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>> _storagePoolMgr.connectPhysicalDisksViaVmSpec(vmSpec);
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> I haven't actually tried it though.
>>>> But in
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> general I don't see the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> Libvirt DiskDef using size at all,
>>>> which
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> is what createVbd does
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> (creates XML definitions for disks to
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> attach to the VM
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> definition). It
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> just takes the device at it's native
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> advertised size when it
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> actually
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> goes to use it.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> On Wed, Oct 23, 2013 at 10:52 AM,
>>>> Mike
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> <mike.tutkow...@solidfire.com>
>>>> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Little problem that I wanted to
>>>> get your
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > take on, Marcus.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > When a VM is being started, we call
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > createVdb before calling
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > connectPhysicalDisksViaVmSpec.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > The problem is that createVdb calls
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > getPhysicalDisk and my
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > volume
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > has not
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > yet been connected because
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > connectPhysicalDisksViaVmSpec has
>>>> not
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > yet
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > been
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > called.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > When I try to read up the size of
>>>> the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > disk to populate a
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > PhysicalDisk, I get
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > an error, of course, because the
>>>> path
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > does not yet exist.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > I could populate a 0 for the size
>>>> of the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > physical disk and then
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > next
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > time getPhysicalDisk is called, it
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > should be filled in with a
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > proper
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > size.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Do you see a problem with that
>>>> approach?
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > On Tue, Oct 22, 2013 at 6:40 PM,
>>>> Marcus
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Sorensen
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > <shadow...@gmail.com>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> That's right. All should be well.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> On Oct 22, 2013 6:03 PM, "Mike
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> Tutkowski"
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> <mike.tutkow...@solidfire.com>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> Looks like we disconnect physical
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> disks when the VM is
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> stopped.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> I didn't see that before.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> I suppose that means the disks
>>>> are
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> physically disconnected
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> when
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> the VM is
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> stopped, but the CloudStack DB
>>>> still
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> has the VM associated
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> with
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> the disks
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> for the next time the VM may be
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> started up (unless someone
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> does a
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> disconnect
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> while the VM is in the Stopped
>>>> State).
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> On Tue, Oct 22, 2013 at 4:19 PM,
>>>> Mike
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> <mike.tutkow...@solidfire.com>
>>>> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Hey Marcus,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Quick question for you related
>>>> to
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> attaching/detaching volumes
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> when the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM is in the Stopped State.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> If I detach a volume from a VM
>>>> that
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> is in the Stopped State,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> DB
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> seems to get updated, but I
>>>> don't see
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> a command going to the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> KVM
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> hypervisor
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that leads to the removal of the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> iSCSI target.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> It seems the iSCSI target is
>>>> only
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> removed the next time the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM is
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> started.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Do you know if this is true?
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> If it is, I'm concerned that the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume could be attached to
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> another VM
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> before the Stopped VM is
>>>> re-started
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> and when the Stopped VM
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> gets
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> restarted
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that it would disconnect the
>>>> iSCSI
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume from underneath the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that now
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> has the volume attached.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> I still want to perform some
>>>> tests on
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> this, but am first
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> trying
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> to get a
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM to start after I've attached
>>>> a
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume to it when it was in
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Stopped
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> State.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Thanks,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Mike
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> On Mon, Oct 21, 2013 at 10:57
>>>> PM,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Mike Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> <mike.tutkow...@solidfire.com>
>>>> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Thanks for that info, Marcus.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> By the way, I wanted to see if
>>>> I
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> could attach my volume to a
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> VM
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> in the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Stopped State.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> The attach logic didn't
>>>> trigger any
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> exceptions; however,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> when I
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> started
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> the VM, I received an
>>>> Insufficient
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Capacity exception.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> If I detach the volume and then
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> start the VM, the VM starts
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> just
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> fine.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I noticed a problem here (in
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> StoragePoolHostDaoImpl):
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> @Override
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> public StoragePoolHostVO
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> findByPoolHost(long poolId,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> long
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> hostId) {
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> SearchCriteria<StoragePoolHostVO> sc =
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> PoolHostSearch.create();
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> sc.setParameters("pool_id",
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> poolId);
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> sc.setParameters("host_id",
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> hostId);
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> return
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> findOneIncludingRemovedBy(sc);
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> }
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> The findOneIncludingRemovedBy
>>>> method
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> returns null (the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> poolId is
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> my
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage pool's ID and the
>>>> hostId is
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> the expected host ID).
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I'm not sure what this method
>>>> is
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> trying to do.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I looked in the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage_pool_host_ref table
>>>> (is that the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> correct
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> table?) and it only has one
>>>> row,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> which maps the local
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> pool of the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> KVM host to the KVM host (which
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> explains why no match is
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> found
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> for my
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> situation).
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Do you understand what this
>>>> logic is
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> trying to do?
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Thanks!
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> On Mon, Oct 21, 2013 at 8:08
>>>> PM,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Marcus Sorensen
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> <shadow...@gmail.com>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> Do you have the capability to
>>>> clone
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the root disk? Normally
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template is installed to
>>>> primary,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> and then cloned for each
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> root
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> disk.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> In some cases (such as CLVM),
>>>> this
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> isn't efficient and so
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> is copied fresh to populate
>>>> each
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> root disk.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> I'm actually not 100% sure
>>>> how this
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> works in the new code.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> It
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> used to
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be handled by
>>>> copyPhysicalDisk in
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the storage adaptor,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> called
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> by
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> copyTemplateToPrimaryStorage,
>>>> which
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> runs on the agent. It
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> would
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> pass
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template/secondary storage
>>>> info,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> and the destination
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> volume/primary
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> storage info, and
>>>> copyPhysicalDisk
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> would do the work of
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> installing the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> image to the destination.
>>>> Then
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> subsequent root disks would
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> cloned
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in CreateCommand by calling
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> createDiskFromTemplate.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> In master it looks like this
>>>> was
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> moved to
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> KVMStorageProcessor
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> 'cloneVolumeFromBaseTemplate',
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> although I think this just
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> takes
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> over
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> as default, and there's
>>>> something
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in your storage driver
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> that
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> should
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be capable of cloning
>>>> templates on
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the mgmt server side.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> I'm
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> less sure
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> about how the template gets to
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> primary storage in the first
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> place, I
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> assume
>>>> copyTemplateToPrimaryStorage
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in KVMStorageProcessor
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> calling
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> copyPhysicalDisk in your
>>>> adaptor.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> It's a bit tough for me
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> to
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> tell
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> since our earlier storage
>>>> adaptor
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> did everything on the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> host it
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> mostly
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> just worked with the default
>>>> stuff.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> On Mon, Oct 21, 2013 at 4:49
>>>> PM,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> Mike Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> <mike.tutkow...@solidfire.com
>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Hey Marcus,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > So...now that this works
>>>> well for
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > data disks, I was
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > wondering
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > what
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > might be
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > involved in getting this
>>>> process
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > to work for root disks.
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Can you point me in the
>>>> right
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > direction as far as what
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > gets
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > invoked
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > when a
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > VM is being created on KVM
>>>> (so
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > that its root disk can be
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > created and
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > the
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > necessary template laid
>>>> down or
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > ISO installed)?
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Thanks!
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > On Mon, Oct 21, 2013 at
>>>> 1:14 PM,
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Mike Tutkowski
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > <
>>>> mike.tutkow...@solidfire.com>
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > wrote:
>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>
>>> ...
>
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
